Ta en titt på mine prosjekter

Techstep hjelper store virksomheter med å håndtere jobbtelefoner, laptoper og nettbrett gjennom deres levetid i bedriften. For en stor kunde kan det være snakk om flere tusen enheter fordelt på mange ansatte og avdelinger. Lifecycle portal samler håndteringen av disse på ett sted, fra en ansatt bestiller en ny telefon eller laptop, til enheten en dag skal repareres, byttes ut eller leveres tilbake.

Det blir fort komplekst. En ansatt skal kanskje kunne bestille og følge sin egen telefon, mens en avdelingsleder har ansvar for enhetene til flere ansatte. Administratorer trenger oversikt på tvers av virksomheten, og ulike grupper av ansatte kan ha forskjellige regler for hvilke enheter de kan bestille og når de skal byttes ut. Portalen må derfor fungere for mange ulike roller, samtidig som alle forholder seg til de samme enhetene.

Jeg var UX-designer i et tverrfaglig produktteam med rundt 12 utviklere, 2 designere og 2 produkteiere. Jeg jobbet med UX-oppgaver på tvers av portalen, fra å forstå problemer og kartlegge komplekse flyter til å utforme ferdige løsninger.

Mye av arbeidet mitt handlet om nettopp kompleksiteten mellom brukere, roller og regler: Hvem skal kunne gjøre hva, for hvilke enheter og på hvilket tidspunkt? Det krevde at jeg både forsto behovene til den enkelte brukeren og hvordan de ulike delene av systemet hang sammen.

Jeg jobbet tett med produkteiere og utviklere for å forstå brukerbehov, forretningsregler og tekniske avhengigheter før en løsning gikk inn i utvikling. UX-arbeidet lå gjerne et stykke foran utviklingen, slik at jeg kunne kartlegge flyter, utforske alternativer og avklare løsninger med teamet før de skulle bygges.

Arbeidet spente fra overordnet tjenestedesign på tvers av hele kundereisen til konkrete funksjoner og brukerflyter i portalen. Under er to eksempler som viser denne bredden.

1. Service blueprint

I dette tjenestedesignprosjektet kartla jeg hele tjenesten rundt lifecycle portal i en service blueprint: Fra Techstep selger løsningen til en ny kunde, gjennom onboarding og daglig bruk, til kontrakten en dag avsluttes.

Mål. Mange mennesker er involvert i å få lifecycle portal til å fungere hos en kunde. Hos kunden kan det være administratorer, avdelingsledere og ansatte, mens blant annet salg, leveranse og support er involvert fra Techsteps side. Handlingene til én rolle påvirker ofte hva en annen rolle kan eller skal gjøre videre. Målet var derfor å få frem hele løpet på tvers av disse aktørene og synliggjøre hvordan handlingene og berøringspunktene deres henger sammen. Blueprinten ga design, utvikling og leveranse et felles bilde av tjenesten og gjorde det lettere å se den rollebaserte logikken som en helhet.

Prosess. Blueprinten ble laget gjennom flere workshops med en av Techsteps kunder som bruker lifecycle portal. Vi gikk gjennom tjenesten fase for fase, fra salg og onboarding via oppsett og daglig bruk til support og avslutning av kontrakten. For hvert steg kartla vi hvem som var involvert, hva de skulle gjøre, hvilke deler av portalen de møtte og hva som satte neste steg i gang. Vi dokumenterte også praktiske tips og fallgruver underveis.

Jeg, en annen UX-designer og cx-lederen i Techstep fasiliterte workshopene og bygde blueprinten underveis. Mellom sesjonene jobbet vi videre med den til vi hadde et helhetlig bilde som både Techstep og kunden kunne stille seg bak.

Blueprinten ble laget for å leve videre som et arbeidsverktøy:

• Som en gjenbrukbar oppskrift på hvordan nye kunder tas gjennom onboarding og oppsett.
• Som grunnlag for prosessforbedringer, ved å synliggjøre steder der tjenesten kan forenkles, automatiseres eller få en tydeligere ansvarsfordeling.
• Som dokumentasjon og opplæringsmateriell for kunden, leveranse og support.

← → Åpne i full skjerm

− +

dra for å bla

2. Api-nøkler: Selvbetjening for partnere

Problemstilling. Techstep tilbyr også lifecycle portal gjennom partnere, som igjen leverer løsningen til sine egne kunder. Disse partnerne trenger blant annet å kunne hente ut og oppdatere informasjon om kundenes enheter gjennom et api.

Tidligere måtte Techstep opprette api-nøkler manuelt for hver partner. Det gjorde partnerne avhengige av Techstep for å komme i gang eller gjøre endringer, samtidig som Techstep brukte tid på oppgaver som kunne vært selvbetjente. Partnerne trengte derfor en egen flate der de kunne opprette og administrere api-nøklene sine selv.

Prosess. Jeg tok funksjonen gjennom en discovery-fase før jeg begynte å designe. Sammen med produkteiere og utviklere avklarte jeg behovet og de tekniske rammene, kartla hvordan en partneradministrator skulle opprette og administrere en api-nøkkel, og så på hvordan andre digitale tjenester løser tilsvarende behov.

På bakgrunn av dette designet jeg en api keys-side i partnerens back-office. Her kan en administrator opprette nye nøkler, få oversikt over eksisterende nøkler og styre hvilke tilganger hver nøkkel skal ha. Jeg jobbet videre med løsningen sammen med utviklerne gjennom backlog refinement og inn i implementeringen.

Resultat. Løsningen ble bygget og tatt i bruk. Partnerne kan nå opprette og administrere api-nøkler selv og bruke dem til å opprette, oppdatere og hente ut data om kundenes enheter uten å måtte gå via Techstep. Det fjernet den manuelle flaskehalsen og ga partnerne større kontroll over sitt eget oppsett.

Når et elbilbatteri ikke lenger fungerer godt nok til å brukes i en bil, kan det fortsatt ha mye kapasitet igjen. I stedet for å gjenvinne batteriet med en gang, kan det få et nytt liv som for eksempel hjemmebatteri, der det lagrer strøm som kan brukes senere.

Teknologien gjør altså ombruk mulig. Men det betydde ikke nødvendigvis at folk ønsker å ha et tidligere elbilbatteri i hjemmet.

Det var utgangspunktet for masteroppgaven min i industriell design ved ntnu. Oppgaven var koblet til et større forskningsprosjekt om ombruk av litium-ion-batterier, der mye av forskningen handlet om de tekniske sidene. Det var derimot mindre kunnskap om menneskene som en dag skal ta disse produktene i bruk.

Et batteri er heller ikke et helt nøytralt produkt. For noen forbindes batterier med elektrifisering, bærekraft og praktiske produkter. For andre kan de vekke tanker om brannfare, forurensning eller noe man helst ikke vil ha stående inne i huset. Slike oppfatninger kan få betydning for om folk stoler på og ønsker å ta i bruk et hjemmebatteri laget av brukte elbilbatterier.

Målet mitt var derfor å forstå hvilke assosiasjoner, forventninger og bekymringer folk har rundt batterier, og finne ut hvordan denne kunnskapen kan brukes i design og kommunikasjon for å skape tillit til et produkt mange ennå ikke har et forhold til.

Jeg gjennomførte masteroppgaven alene og hadde ansvar for hele prosjektet, fra å definere problemstillingen og planlegge researchen til å analysere funnene og utvikle et designkonsept. Jeg hadde to veiledere og var koblet til det pågående forskningsprosjektet ved ntnu.

Jeg brukte en double diamond-prosess, men la størstedelen av prosjektet i innsiktsfasen. Før jeg kunne designe noe, måtte jeg først forstå hvordan folk faktisk tenker om batterier og hvor skepsisen eller tilliten kommer fra.

Jeg startet med desk research og gikk deretter bredt ut for å samle inn perspektiver gjennom flere metoder. Jeg brukte netnografi for å undersøke hvordan folk snakker om batterier på nett, satte opp en graffitivegg for å samle spontane assosiasjoner, gjennomførte en spørreundersøkelse og intervjuet to personer med særlig interesse for batterier. Senere brukte jeg workshops for å gå dypere inn i temaene som hadde kommet frem.

Metodene bygde på hverandre. Funn fra netnografien påvirket hva jeg undersøkte i spørreundersøkelsen, og resultatene derfra var igjen med på å forme workshopene. På den måten kunne jeg starte bredt og gradvis gå dypere inn i temaene som viste seg å være viktige.

Jeg analyserte materialet underveis og brukte blant annet affinity mapping, personas og empatikart for å samle observasjoner og se mønstre på tvers av metodene.

Til slutt tok jeg innsikten inn i en kortere konseptfase. Målet var ikke å utvikle et ferdig produkt, men å vise hvordan kunnskapen om brukeraksept faktisk kunne påvirke konkrete designvalg.

Researchen viste at aksept av gjenbrukte batterier ikke handler om én enkelt bekymring. Flere ting påvirker hvordan folk vurderer et slikt produkt, blant annet sikkerhet, ytelse, bærekraft, tillit, kostnad og hvor godt de forstår teknologien.

Disse faktorene ga et mer konkret bilde av hva designere, forskere og andre som utvikler slike produkter bør ta hensyn til. I stedet for å behandle «brukeraksept» som en generell holdning, kunne jeg peke på konkrete områder der design og kommunikasjon kan påvirke hvordan produktet blir oppfattet.

For å utforske dette videre utviklet jeg et konsept for en fiktiv aktør som gir brukte elbilbatterier et nytt liv som hjemmebatterier. Researchen hadde vist både hva som skapte skepsis og hvilke egenskaper og avsendere folk allerede forbandt med noe positivt. Det tok jeg med meg inn i designet, der jeg lot konseptet lene seg på noen av de positive assosiasjonene for å veie opp for frykten og skepsisen.

Merkevaren bygget blant annet på tilliten folk allerede har til etablerte ordninger for batteriretur og kvalitetsassosiasjonene til kjente bilmerker. Konseptet bestod av designet på selve batterikabinettet, en merkevareidentitet og mockups av en nettside.

Dette prosjektet ga meg god trening i å sette meg inn i et teknisk fagfelt jeg ikke kunne noe om fra før, og i å drive en research-tung prosess fra start til slutt på egen hånd. Prosjektet lærte meg særlig hvordan man kan ta noe så lite håndfast som holdninger, bekymringer og assosiasjoner og gjøre det om til konkrete hensyn det faktisk går an å designe ut fra.

Når en bolig får en vannskade eller en annen bygningsskade, drar en takstperson ut for å undersøke hva som har skjedd og dokumentere skaden. Under befaringen skal de blant annet gjøre målinger, registrere informasjon og snakke med huseieren, samtidig som de beveger seg rundt i boligen og bruker forskjellige verktøy.

Skaderapporten er en viktig del av denne jobben. Tidligere ble mye av informasjonen skrevet inn som fritekst. Det ga takstpersonen stor frihet, men førte også til at den samme typen skade kunne beskrives på mange forskjellige måter. To takstpersoner kunne i praksis dokumentere lignende skader helt forskjellig.

For Wenn Property var dette et problem fordi informasjonen fra rapportene skulle kunne brukes til mer enn å dokumentere én enkelt skade. Når dataene er inkonsistente og ligger i fritekst, er det vanskelig å sammenligne skadesaker, finne mønstre og lage god statistikk. Det gir også et dårligere grunnlag for KI som skal lære av tidligere skader og på sikt bidra til å forutse nye.

Oppgaven vår var derfor todelt: Rapporten måtte være rask og enkel å fylle ut for en takstperson som står midt i en befaring, samtidig som informasjonen måtte registreres på en strukturert og konsistent måte.

Løsningen skulle også kunne ta imot måledata fra en egen scanner-app og bygges på en sikker infrastruktur.

Dette var et internship-prosjekt hos Olavstoppen, der vi var fem studenter som jobbet sammen for Wenn Property: To designere og tre utviklere.

Jeg jobbet på designsiden sammen med den andre designeren, fra å forstå hvordan takstpersonene jobbet og hvilken informasjon rapportene måtte inneholde, til brukerflyt og ferdig design i figma. Utviklerne bygde selve løsningen og infrastrukturen, og vi jobbet tett sammen om hvordan informasjonen skulle struktureres i grensesnittet og i systemet bak.

Forstå dataene. Vi startet med å forstå hvilken informasjon en skaderapport består av og hvordan den henger sammen. Informasjonen som takstpersonen registrerer, skulle kunne sammenlignes og analyseres på tvers av mange skadesaker.

Det betydde at skjemaet og datastrukturen måtte designes sammen. Vi måtte finne ut hvilken informasjon som burde registreres gjennom faste, strukturerte valg, og hvor det fortsatt var behov for fleksibilitet.

Forstå arbeidssituasjonen. For å se hvordan rapporteringen faktisk foregår, observerte vi en takstperson på befaring. Det gjorde det tydelig at rapporten bare er én av mange ting takstpersonen må forholde seg til, og ga oss et bedre bilde av hvordan løsningen faktisk måtte fungere i bruk.

Fra innsikt til løsning. Med forståelsen av både datastrukturen og arbeidssituasjonen som utgangspunkt kartla vi brukerreisen, brainstormet, skisset og utforsket ulike måter å strukturere rapporten på. Derfra tok vi løsningen videre til ferdig design i figma.