← Tilbake til oversikt
OPPGAVESIDE 2.0 REDESIGN
“En helt ny hverdag” for drift & vedlikehold av eiendommer i Propely.
Min rolle
Produkt designer – UX, UI, prototyping, designsystem, testing og research.
Platform
Webapp for drift og vedlikehold (FDV) i næringseiendom.
Team
Produkt – Meg + 3 utviklere og CEO
Tidslinje
Mar 2024 – Apr 2025
Første iterasjon → Beta
Om prosjektet.
Da jeg startet i Propely var selskapet i kraftig vekst i ARR (årlig inntekt), brukerbase og kundeønsker. Plattformen hadde flere års utvikling bak seg, men fundamentet begynte å vise sprekker. Feil og ustabilitet gjorde at utviklerne måtte bruke tid på brannslukking og midlertidige løsninger, mens Customer Success-teamet brukte mye tid på manuelle tilpasninger og workarounds for å dekke brukernes behov.
Jeg ble derfor ansatt sammen med tre utviklere for å etablere Propelys første dedikerte produktteam. Oppgavesiden ble valgt som første kandidat for et top-til-bunn-redesign, et slags pilotprosjekt for arbeidet videre.
Nesten ett år senere etter en heroisk innsats fra alle involverte, lanserte vi betaversjonen av Oppgaver 2.0 på Propelys kundedag. Det ble selskapets største lansering til da og ble godt tatt i mot, selv av våre mest kravstore kunder.
Demonstrasjon av en av mine største kvaliteter, ydmykhet.
BAKGRUNN
Hva er er egentlig Propely?
Propely er en digital plattform for forvaltning av næringseiendom: eiendom som leies av bedrifter, ikke privatpersoner. Platformen består av tre ulike løsninger som retter seg mot ulike aspekter av eiendomsforvaltningen:
- Portefølje: For økonomi og statistikk.
- Leietakerløsning: For alt det praktiske rettet mot leietakere.
- Drift og vedlikehold: Alt rettet mot det fysiske vedlikeholdet av bygg.
Oppgavesiden hører til «Drift og vedlikehold» og er den mest brukte og sentrale delen av Propely. Her samarbeider leietakere, teknikere, vaktmestere og leverandører om alt fra hull i vegger og tette toaletter til rutinesjekk av takrenner og overlevering av nøkler.
Målet for prosjektet.
Prosjektet var første steg i å rigge Propely for skalering ved å heve både designkvalitet og teknisk kvalitet. Oppgavesiden ble pilot og ledestjerne: løsningen måtte bli rask, stabil og intuitiv slik at Customer Success kunne bruke mer tid på onnboarding, og mindre tid på tilpasning.
Konkrete mål for Oppgavesiden 2.0:
- Redusere tid og ressurser Customer Success bruker på oppgavesiden
- Gjøre løsningen mer intuitiv og lettere å lære
- Avdekke og løse flest mulig brukbarhetsproblemer
- Etablere effektivt samspill og arbeidsform i det nye produktteamet
RESEARCH
Initiell oversikt over oppgaver.
For å få en oversikt over oppgavesiden, var det to spørsmål jeg ville ha innsikt i:
- Hvordan er systemet faktisk bygget?
- Hvordan brukes systemet ute hos kundene?
- Hvordan fungerer systemet?
Jeg startet med en heuristisk gjennomgang for et førsteinntrykk av systemet, men øvelsen ga begrenset verdi: oppgavesiden lente tungt på objekter og relasjoner jeg ikke kjente til (sjekklister, rutiner, koblinger m.m.).
I starten ble det mer spørsmål enn tilbakemeldinger på designet.
Derfor laget jeg et OOUX-kart for å få et «røntgenbilde» av strukturen. Det hjalp meg sette til sides initielle ideer om hvordan siden “burde” virke, og hjalp teamet kunne diskutere strukturen uten å henge seg opp i grensesnittet.
OOUX kart av selve oppgaven i systemet.
Noen observasjoner:
- En oppgave refererer til 9+ andre objekter i ulike deler av systemet.
- Noen relasjoner har skjult funksjonalitet. For eksempel ville det å legge til leverandør utløse en e-post/«bestilling», uten at det finnes en formell bestillingsflyt i systemet.
- Noen begrensninger var ikke synlige, som “sjekklister” som bare kunne brukes når oppgaven er knyttet til en rutine (opprettes et annet sted).
Oppgavesiden virket innledningsvis som en isolert del av systemet, men det viste seg at ting var mer sammenhengende enn jeg hadde trodd.
- Hvordan blir systemet brukt
Jeg intervjuet seks brukere for å samle konkret brukskontekst og tilbakemeldinger. Webappen brukes primært av dem som ikke er fysisk på byggene, og brukerene var derfor en blanding av:
- Driftsledere – delegerer oppgaver og følger opp vaktmestere og teknikere i felt.
- Forvaltere – har overordnet ansvar for eiendommen, inkludert kommunikasjon med leietakere.
Innsikt brukte jeg for å fylle ut en initiel oversikt (UX questionaire), og empathy map for konkrete utsagn.
Flere av brukerene opplevde at grunnleggende funksjoner var vanskelig å oppdage/sette opp, og at de derfor måtte lene seg på vårt CS team. Brukerene opplevde også siden som rotete og lite oversiktelig. Det var likevel ingenting funksjonelt som manglet, og kundene som hadde fått god oppfølging var generelt fornøyde. Som en av driftsteknikerne sa (litt paradoksalt):
“Jeg synes det var intuitivt, etter jeg hadde forstått det” – Driftstekniker
Men når et problem først oppsto, var det vanskelig for brukerene å forstå hva som hadde gått galt. Så selv når brukerene var godt kjent med løsningen, føltes siden ustabil og upålitelig. Da var veien kort til frustrasjon.
“Dette er fullstendig kaos” – Forvalter
“Rutiner må skrotes” – Driftstekniker
UX workshop
For å samle alle de ulike trådene inviterte jeg Salg, CS og tech til en UX workshop. Der kombinerte vi min og teamets erfaringer for å finne en rekke temaer vi kunne forbedre, og fikk innspill på hva de ulike teamene mente var viktig å prioritere.
Obligatorisk workshop post-it bilde.
KEY TAKEAWAYS
Resultatet fra research-fasen delte vi inn i 5 konkrete forbedringsområder.
1
Finne relevante oppgaver raskt.
Brukerene ble møtt med alt i en visning, og de slet med å finne oppgaver som var relevante for dem. Det resulterte i mye manuell leting og filtrering, og mange henvendelser til CS for å sette opp relevante visninger.
2
Bedre oversikt over mange oppgaver.
Brukerene av web-appen jobbet ofte i administrative roller, og måtte derfor få oversikt over mange oppgaver samtidig. Den nåværende sidenavigasjonen ga for lite relevant informasjon ved første øyeblikk, og gjorde det var begrenset med muligheter for bulk-redigering.
3
Gjør det lettere å jobbe med oppgaver over tid.
For brukerene var tid ofte viktig i arbeidet med oppgaver, spesielt skillet mellom oppgaver som er meldt inn vs rutineoppgaver som settes opp i fremtiden. Men mangelfull dato-filtrering, rutiner og blanding av start/opprettet datoer gjorde det vanskelig å få en oversikt over tid.
4
Gi brukerene mulighet til å fange opp oppgaver uten ansvarlige.
Enkelte av brukerene opplevde det de kalte for “spøkelsesavvik”. Oppgaver som rett og slett virket til å forsvinne i systemet, uten at noen kunne spore dem opp. Dette var oppgaver som ikke hadde noen ansvarlige knyttet til seg, men det føltes for brukeren som om systemet var ustabilt og at oppgaver kunne forsvinne når som helst.
5
Lag et tydelig skille mellom aktivitet på oppgaver, og kommunikasjon fra brukere.
Når man kommuniserer inne på en oppgave var det vanskelig å skille enkelt mellom hva som var en status oppdatering, hva som var kommunikasjon, og hva som var synlig for leietaker. Det gjorde at brukerene hadde vanskelig for å lett finne frem til kommentarer når de skulle lese seg opp på en oppgave.
LØSNING 1
Forbedret oversikt over oppgaver.
Drifterne opplevde oversikten som for enkel til å håndtere store mengder oppgaver, men samtidig uoversiktlig når de skulle finne egne eller andres ansvar. Særlig ble “spøkelsesavvik” oppfattet som problematiske, fordi de ikke lot seg finne igjen.
Konkrete problemer:
- Sidemenyen var for bregrensende for mengden oppgaver en forvalter eller driftsleder måtte navigere.
- I tillegg var det mye informasjon knyttet til oppgaven som ikke kunne vises i dette formatet.
- Arkiveringsfunksjonalitet måtte gjøres gjennom å sette et “standardfilter” som alltid filtrerte ut arkiverte filer.
- “Mine ansvarlige” var desidert den viktigste visningen hos kundene, men den kunne ikke enkelt kombineres med andre visninger te trengte.
Gammel oppgavesiden der arkiverte og løste oppgaver er filtrert ut som standard.
I tidlig fase skisserte jeg opp en rekke ideer å vise til teamet.
Hovedideen var å dele opp oppgavesiden i dedikerte sider. Da ville man få et nivå over visninger hvor man kunne sette opp visninger og funksjonalitet mer tilpasset de ulike bruksområdene.
Thumbnail skisser av utkast til ulik funksjonalitet jeg presenterte for teamet.
Oppdelingen ville da bli:
- Alle oppgaver: Siden ment for dem som sitter med overordnet ansvar, driftere og forvaltere med fokus på å oversikt og administrasjon.
- Mine oppgaver: Mine oppgaver skulle være mer fokusert på gjennomførelsen av oppgaver, og var derfor mer fokusert rundt frister og oppdateringer.
- Ubehandlede oppgaver: Fokus på å fange opp oppgaver med mangler, og synliggjøre “spøkelses-avvikene” som ikke hadde utførende eller ansvarlig.
- Arkiv: For å fjerne standardfiltrering og få arkiverte filer en egen plass hvor det føles trygt.
Initielt design av de ulike visningene.
Vi valgte også å gå fra en sidemeny, til tabellvisning. Dette var en endring som allerede var høyt etterspurt og delvis implementert, men lå nå sammen med sidemenyen i oversikten.
Den nye tabellen kom med en rekke forbedringer.
- Mer kompakt design med pinnet tittel, siden det var det viktigste for brukerene når de visuelt letet etter en oppgave.
- Notifikasjoner for nye oppdateringer, istedenfor at man må lese “sist oppdatert” dato.
- Egen tilpassing av rekkefølge på kollonnen.
Gammel vs ny oppgavetabell.
Jeg tok med designet ut til kundene for å få tilbakemeldinger på det nye oppsettet. Tilbakemeldingene var nesten utelukkende positive.
- Alle var veldig positive for det nye layoutet og ideen bak indelingen. Det ble beskrevet som “mye ryddigere”, og det føltes tryggere når egne oppgaver og arkiverte oppgaver var isolert på egne sider.
- Ideen bak “mangler deligering” ble godt tatt i mot, spesielt av de som hadde slitt med spøkelsesavvik. Men kunden presiserte at ideelt sett så skulle man ikke ha avvik som ikke tilhørte en person fra starten av.
- Mine oppgaver fokuset for gjennomføring og datoer, ga ikke så mye mening for webappen. Det ble markert som en veldig god ide for de som utfører oppgaver, men at man på web burde ha et likt oppsett som “alle oppgaver”.
Generelt virket det som det var selve inndelingen av egne områder, og ikke tilpasningen på hver side som hadde mest verdi for kunden. Derfor fokuserte vi mindre på spesialtilpasning, og mer mot å få standard-funksjonaliteten så robust som mulig mot lansering.
LØSNING 2
Gjøre det lettere å filtrere seg frem til oppgaver.
Brukerne opplevde eksisterende filter som både forvirrende og lite nyttige. Mange “lagrede visninger” ble nesten aldri brukt, mens viktige behov som å filtrere på tid eller skille oppgaver fra rutiner, var dårlig støttet.
Gammel filter var en dobbel nøstet dropdown og hadde en lei tendens å droppe av siden.
Vi testet tre retninger for filtrering:
- Redesign av nåværende filter. Fordelen var at det var kjent for brukeren, men ulempen var at filteret ikke ble noe mer synlig.
- En filter modal. Uendelig med vertikal plass i menyen, men også i en undermeny,
- Pinnede filter. Mer synlig og lettere tilgjenglig, men går fort tomt for plass.
Initielle konsepter for redesign av filtere.
Vi landet på pinnede filter, fordi det var det var mest synlig for brukerene. Da var ikke bare inngangen til filteret mer synlig, men også hvilken filter som var tilgjengelig.
I tillegg la vi til filtrering på dato, og toggle mellom oppgaver og rutiner. Både for å gjøre det lettere for brukeren å orinetere seg over tid, men også for å isolere rutineoppgavene, fordi det ikke var innenfor scopet å lage en ordentlig løsning på rutinegenereringen.
I starten trodde vi at vi måtte beholde “lagrede visninger” og støtte alle gamle filter, men testing og tilbakemeldinger viste at kombinasjonen av pinnede filter og ny toppnavigasjon dekket behovene. Enkelte kunder var så fornøyde at de etterlyste disse filtrene kontinuerlig gjennom utviklingen.
Mot slutten dukket det like vell opp 2 problemer:
- Noen få, nøkkelkunder som ønsket lagrede visninger tilbake.
- Ytelsesproblemer fordi tusenvis av oppgaver ble lastet inn uten standardfilter.
Vi løste derfor dette i mot slutten av utviklingen med å introdusere tilbake egne visninger, med nye visninger for “Uløst/løst” som betydelig reduserte innlastingstiden.
Nåværende filter med egne visninger i platformen.
LØSNING 3
Forbedret skille mellom oppdatering og kommunikasjon
Selve oppgavevisningen var i utgangspunktet en relativt velfungerende del av løsningen, men vi oppdaget noen viktige svakheter. Det var uklart hvor oppgaven stammet fra (leietaker, rutine eller internt), og aktivitetsloggen skapte forvirring rundt hvem som kunne se hva.
I tillegg lå sjekklistene, som ofte var avgjørende for å gjennomføre oppgave, gjemt i en egen tab, noe som gjorde dem lite tilgjengelige.
Gammel oversikt inne på en oppgave.
Vi utforsket først en løsning der kommunikasjonen ble delt opp i tre separate faner for intern dialog, leietaker-kommunikasjon og systemaktiviteter. Enkelte syntes det var litt “skummelt” å skrive i aktivitetsloggen, så vi forsøkte oss på et design som lignet mer på meldingsdeling-apper.
Testingen viste imidlertid at brukerne savnet helheten og oversikten man fikk av å ha alt i hele visningen. Vi endte derfor med en kombinert aktivitetslogg med tydelige visuelle markører som skilte intern kommunikasjon, eksterne meldinger og systemaktiviteter.
3 itterasjoner av aktivitetslogg.
Vi tok lærdommen fra aktivitetsloggen, og endret også headeren på oppgaven til å visuelt refletkere hvor oppgaven kommer fra. Ofte hoppet brukerene mellom mange ulike oppgaver, og da var det viktig at man med første øyekast får en god oversikt over oppgaven.
Header på oppgave endrer seg basert på hvordan oppgaven er generert.
UTFORDRINGER MOT LANSERING
Den store refaktureringen.
Første itterasjon av designet tok omtrent 3 måneder. Etter det startet jeg på nye prosjekter mens teamet jobbet på oppgavesiden. 3 måneder senere, var jeg ferdig med redesign av eiendomssiden, og oppgavesiden var fortsatt ikke lansert. Det var flere grunner til dette:
- Teknisk gjeld: Vi undervurderte hvor mye gammel kode som måtte ryddes opp. Innen refaktoreringen var ferdig, var mye av designet allerede utdatert.
- Scope og prioriteringer: Hele oppgavesiden ble sett på som ett redesign. Det gjorde at små, verdifulle forbedringer ikke kunne slippes uten at alt annet var ferdig.
- Teamstørrelse: Vi var bare tre utviklere og én designer, alle nye i selskapet. Ambisjonsnivået var rett og slett for høyt.
Resultatet var et prosjekt som aldri føltes ferdig, mens bugs, kundeønsker og skisser hopet seg opp.
Fra UX/Tech, til produkteam.
Jeg innså fort at det var lite nytte i å ligge måneder foran utviklerne.
Jeg satte videre redesign på pause og begynte å støtte utviklerne tettere...bokstavelig talt. Vi flyttet diskusjonene fra møterom til pultene, kjørte kortere tester på kontoret, og jeg fikk slippe inn i kodebasen i et kort stint som frontendtuvikler (paddings, margins og flex-layout).
Resultatet var en mye bedre flyt i teamet der vi gjorde hardere prioriteringer, fikset UX problemer fortløpende med lavere terskel for sammarbeid. Det var ingen snarvei rundt den tekniske gjelden, men motivasjonen var høyere når vi var samlet som ett team.
Alle mann til pumpene, min første PR i Propely.
RESULTAT
Propely kundedag
Etter måneder med design, utvikling, refakturering og QA-testing, satte vi en hard deadline: betalansering på Propelys andre kundedag. Over 120 deltakere fra kundene våre var samlet for å se foredrag, nettverke, og ikke minst for å se de nye produktlanseringene.
CEO viser frem 3 nye redesign, oppgave web, oppgaver mobil og eiendomsside.
For produktteamet var dette en milepæl, og for meg personlig et høydepunkt. Av fire nye lanseringer denne dagen hadde jeg hatt ansvaret for tre av dem. Det markerte slutten på et langt og utfordrendre utviklingsløp, og lanseringen ble første gang hele kundebasen skulle se vår visjon for fremtiden til systemet.
Det var vanskelig å ikke la forventningene løpe løpsk. Heldigvis var mottakelsen alt annet enn skuffende.
“1000 ganger bedre enn gammel side” – Tilbakemelding i intercom
“Dette har vi ventet på lenge” – Fra kundedagen
“Endelig kan vi slutte å bruke den gamle siden” – I kundemøte med CS
Hva vi oppnådde
Selv om vi ikke hadde kvantitive analyseverktøy på plass, så vi en tydelig effekt av lanseringen av oppgavesiden:
For brukeropplevelsen
- Det var en høy innteresse for betalanseringen i etterkant av kundedagen, og initielle tilbakemeldinger via skjema har vært veldig positive.
- Alle henvendelser av “spøkelsesavvik” hos betabrukerene forsvant.
- Vi opplevde også at brukerene nesten ikke etterspør egne visninger lenger, takket være den nye indelingen og filtere.
- En av våre største kunder “nektet” å bruke gammel løsning før de fikk tilgang til den nye siden på grunn av de nye filterene.
For bedriften
- Salg rapporterer at brukeropplevelse er et av det største salgspunktene for både nye og gamle kunder, og at oppgaveredesignet gir trygghet i dette.
- CS har redusert tiden de bruker på oppgavesiden, de fleste henvendelser kommer nå fra brukere av gammel oppgaveside. Disse problemene løses ofte med å få kunden over på ny løsning.
- Vi fikk en mye smidigere utvikling med tettere sammarbeid mellom tech og design. Det gjorde at vi over det neste året fikk lansert 2 redesign og 1 helt ny på samme tid som oppgavesiden tok.
REFLEKSJONER
Realiteten av å være et “UX team-of-one”.
Jeg er utrolig takknemlig for tilliten og ansvaret jeg ble gitt under prosjektet. Mitt arbeid la grunnlaget for et helt år med utvikling og det var første gang en UX designer har vært involvert i bedriften. Det var både givende og lærerikt...men også ganske nærvepirrende.
For å kompensere prøvde jeg automatisere og systematisere meg ut av begrensninger, så jeg kunne være et “one-man-team” med alle av fordelene, og ingen av nedsidene. Notion, slack kanaler, prosedyrer og team-diagrammer. Jeg falt i samme fellen som jeg selv hadde utfordret teamet på:
“Husk at oppgaver løses i virkeligheten, ikke i systemet.”
Det var først da jeg begynte å stille meg selv spørsmålet: “Hva er én ting jeg kan gjøre, akkurat nå, for å støtte teamet?” at ting løsnet. Idealet om en perfekt UX-prosess ble lagt til side til fordel for å løse problemer med de ressursene jeg faktisk hadde.
Det betydde færre brukerinvolveringer, mindre tid på skisser og større vekt på teknisk gjennomførbarhet fremfor de mest ideelle løsningene.
Det var ingen sølvkule, men det bidro på smått og stort at vi fikk lansert.
← Tilbake til oversikt
Ny side
OPPGAVESIDE 2.0 REDESIGN
“En helt ny hverdag” for drift & vedlikehold av eiendommer i Propely.
Min rolle
Produkt designer – UX, UI, prototyping, designsystem, testing og research.
Platform
Webapp for drift og vedlikehold (FDV) i næringseiendom.
Team
Produkt – Meg + 3 utviklere og CEO
Tidslinje
Mar 2024 – Apr 2025
Første iterasjon → Beta
Om prosjektet.
Da jeg startet i Propely var selskapet i kraftig vekst i ARR (årlig inntekt), brukerbase og kundeønsker. Plattformen hadde flere års utvikling bak seg, men fundamentet begynte å vise sprekker. Feil og ustabilitet gjorde at utviklerne måtte bruke tid på brannslukking og midlertidige løsninger, mens Customer Success-teamet brukte mye tid på manuelle tilpasninger og workarounds for å dekke brukernes behov.
Jeg ble derfor ansatt sammen med tre utviklere for å etablere Propelys første dedikerte produktteam. Oppgavesiden ble valgt som første kandidat for et top-til-bunn-redesign, et slags pilotprosjekt for arbeidet videre.
Nesten ett år senere etter en heroisk innsats fra alle involverte, lanserte vi betaversjonen av Oppgaver 2.0 på Propelys kundedag. Det ble selskapets største lansering til da og ble godt tatt i mot, selv av våre mest kravstore kunder.
Demonstrasjon av en av mine største kvaliteter, ydmykhet.
BAKGRUNN
Hva er er egentlig Propely?
Propely er en digital plattform for forvaltning av næringseiendom: eiendom som leies av bedrifter, ikke privatpersoner. Platformen består av tre ulike løsninger som retter seg mot ulike aspekter av eiendomsforvaltningen:
- Portefølje: For økonomi og statistikk.
- Leietakerløsning: For alt det praktiske rettet mot leietakere.
- Drift og vedlikehold: Alt rettet mot det fysiske vedlikeholdet av bygg.
Oppgavesiden hører til «Drift og vedlikehold» og er den mest brukte og sentrale delen av Propely. Her samarbeider leietakere, teknikere, vaktmestere og leverandører om alt fra hull i vegger og tette toaletter til rutinesjekk av takrenner og overlevering av nøkler.
Målet for prosjektet.
Prosjektet var første steg i å rigge Propely for skalering ved å heve både designkvalitet og teknisk kvalitet. Oppgavesiden ble pilot og ledestjerne: løsningen måtte bli rask, stabil og intuitiv slik at Customer Success kunne bruke mer tid på onnboarding, og mindre tid på tilpasning.
Konkrete mål for Oppgavesiden 2.0:
- Redusere tid og ressurser Customer Success bruker på oppgavesiden
- Gjøre løsningen mer intuitiv og lettere å lære
- Avdekke og løse flest mulig brukbarhetsproblemer
- Etablere effektivt samspill og arbeidsform i det nye produktteamet
RESEARCH
Initiell oversikt over oppgaver.
For å få en oversikt over oppgavesiden, var det to spørsmål jeg ville ha innsikt i:
- Hvordan er systemet faktisk bygget?
- Hvordan brukes systemet ute hos kundene?
- Hvordan fungerer systemet?
Jeg startet med en heuristisk gjennomgang for et førsteinntrykk av systemet, men øvelsen ga begrenset verdi: oppgavesiden lente tungt på objekter og relasjoner jeg ikke kjente til (sjekklister, rutiner, koblinger m.m.).
I starten ble det mer spørsmål enn tilbakemeldinger på designet.
Derfor laget jeg et OOUX-kart for å få et «røntgenbilde» av strukturen. Det hjalp meg sette til sides initielle ideer om hvordan siden “burde” virke, og hjalp teamet kunne diskutere strukturen uten å henge seg opp i grensesnittet.
OOUX kart av selve oppgaven i systemet.
Noen observasjoner:
- En oppgave refererer til 9+ andre objekter i ulike deler av systemet.
- Noen relasjoner har skjult funksjonalitet. For eksempel ville det å legge til leverandør utløse en e-post/«bestilling», uten at det finnes en formell bestillingsflyt i systemet.
- Noen begrensninger var ikke synlige, som “sjekklister” som bare kunne brukes når oppgaven er knyttet til en rutine (opprettes et annet sted).
Oppgavesiden virket innledningsvis som en isolert del av systemet, men det viste seg at ting var mer sammenhengende enn jeg hadde trodd.
- Hvordan blir systemet brukt
Jeg intervjuet seks brukere for å samle konkret brukskontekst og tilbakemeldinger. Webappen brukes primært av dem som ikke er fysisk på byggene, og brukerene var derfor en blanding av:
- Driftsledere – delegerer oppgaver og følger opp vaktmestere og teknikere i felt.
- Forvaltere – har overordnet ansvar for eiendommen, inkludert kommunikasjon med leietakere.
Innsikt brukte jeg for å fylle ut en initiel oversikt (UX questionaire), og empathy map for konkrete utsagn.
Flere av brukerene opplevde at grunnleggende funksjoner var vanskelig å oppdage/sette opp, og at de derfor måtte lene seg på vårt CS team. Brukerene opplevde også siden som rotete og lite oversiktelig. Det var likevel ingenting funksjonelt som manglet, og kundene som hadde fått god oppfølging var generelt fornøyde. Som en av driftsteknikerne sa (litt paradoksalt):
“Jeg synes det var intuitivt, etter jeg hadde forstått det” – Driftstekniker
Men når et problem først oppsto, var det vanskelig for brukerene å forstå hva som hadde gått galt. Så selv når brukerene var godt kjent med løsningen, føltes siden ustabil og upålitelig. Da var veien kort til frustrasjon.
“Dette er fullstendig kaos” – Forvalter
“Rutiner må skrotes” – Driftstekniker
UX workshop
For å samle alle de ulike trådene inviterte jeg Salg, CS og tech til en UX workshop. Der kombinerte vi min og teamets erfaringer for å finne en rekke temaer vi kunne forbedre, og fikk innspill på hva de ulike teamene mente var viktig å prioritere.
Obligatorisk workshop post-it bilde.
KEY TAKEAWAYS
Resultatet fra research-fasen delte vi inn i 5 konkrete forbedringsområder.
1
Finne relevante oppgaver raskt.
Brukerene ble møtt med alt i en visning, og de slet med å finne oppgaver som var relevante for dem. Det resulterte i mye manuell leting og filtrering, og mange henvendelser til CS for å sette opp relevante visninger.
2
Bedre oversikt over mange oppgaver.
Brukerene av web-appen jobbet ofte i administrative roller, og måtte derfor få oversikt over mange oppgaver samtidig. Den nåværende sidenavigasjonen ga for lite relevant informasjon ved første øyeblikk, og gjorde det var begrenset med muligheter for bulk-redigering.
3
Gjør det lettere å jobbe med oppgaver over tid.
For brukerene var tid ofte viktig i arbeidet med oppgaver, spesielt skillet mellom oppgaver som er meldt inn vs rutineoppgaver som settes opp i fremtiden. Men mangelfull dato-filtrering, rutiner og blanding av start/opprettet datoer gjorde det vanskelig å få en oversikt over tid.
4
Gi brukerene mulighet til å fange opp oppgaver uten ansvarlige.
Enkelte av brukerene opplevde det de kalte for “spøkelsesavvik”. Oppgaver som rett og slett virket til å forsvinne i systemet, uten at noen kunne spore dem opp. Dette var oppgaver som ikke hadde noen ansvarlige knyttet til seg, men det føltes for brukeren som om systemet var ustabilt og at oppgaver kunne forsvinne når som helst.
5
Lag et tydelig skille mellom aktivitet på oppgaver, og kommunikasjon fra brukere.
Når man kommuniserer inne på en oppgave var det vanskelig å skille enkelt mellom hva som var en status oppdatering, hva som var kommunikasjon, og hva som var synlig for leietaker. Det gjorde at brukerene hadde vanskelig for å lett finne frem til kommentarer når de skulle lese seg opp på en oppgave.
LØSNING 1
Forbedret oversikt over oppgaver.
Drifterne opplevde oversikten som for enkel til å håndtere store mengder oppgaver, men samtidig uoversiktlig når de skulle finne egne eller andres ansvar. Særlig ble “spøkelsesavvik” oppfattet som problematiske, fordi de ikke lot seg finne igjen.
Konkrete problemer:
- Sidemenyen var for bregrensende for mengden oppgaver en forvalter eller driftsleder måtte navigere.
- I tillegg var det mye informasjon knyttet til oppgaven som ikke kunne vises i dette formatet.
- Arkiveringsfunksjonalitet måtte gjøres gjennom å sette et “standardfilter” som alltid filtrerte ut arkiverte filer.
- “Mine ansvarlige” var desidert den viktigste visningen hos kundene, men den kunne ikke enkelt kombineres med andre visninger te trengte.
Gammel oppgavesiden der arkiverte og løste oppgaver er filtrert ut som standard.
I tidlig fase skisserte jeg opp en rekke ideer å vise til teamet.
Hovedideen var å dele opp oppgavesiden i dedikerte sider. Da ville man få et nivå over visninger hvor man kunne sette opp visninger og funksjonalitet mer tilpasset de ulike bruksområdene.
Thumbnail skisser av utkast til ulik funksjonalitet jeg presenterte for teamet.
Oppdelingen ville da bli:
- Alle oppgaver: Siden ment for dem som sitter med overordnet ansvar, driftere og forvaltere med fokus på å oversikt og administrasjon.
- Mine oppgaver: Mine oppgaver skulle være mer fokusert på gjennomførelsen av oppgaver, og var derfor mer fokusert rundt frister og oppdateringer.
- Ubehandlede oppgaver: Fokus på å fange opp oppgaver med mangler, og synliggjøre “spøkelses-avvikene” som ikke hadde utførende eller ansvarlig.
- Arkiv: For å fjerne standardfiltrering og få arkiverte filer en egen plass hvor det føles trygt.
Initielt design av de ulike visningene.
Vi valgte også å gå fra en sidemeny, til tabellvisning. Dette var en endring som allerede var høyt etterspurt og delvis implementert, men lå nå sammen med sidemenyen i oversikten.
Den nye tabellen kom med en rekke forbedringer.
- Mer kompakt design med pinnet tittel, siden det var det viktigste for brukerene når de visuelt letet etter en oppgave.
- Notifikasjoner for nye oppdateringer, istedenfor at man må lese “sist oppdatert” dato.
- Egen tilpassing av rekkefølge på kollonnen.
Gammel vs ny oppgavetabell.
Jeg tok med designet ut til kundene for å få tilbakemeldinger på det nye oppsettet. Tilbakemeldingene var nesten utelukkende positive.
- Alle var veldig positive for det nye layoutet og ideen bak indelingen. Det ble beskrevet som “mye ryddigere”, og det føltes tryggere når egne oppgaver og arkiverte oppgaver var isolert på egne sider.
- Ideen bak “mangler deligering” ble godt tatt i mot, spesielt av de som hadde slitt med spøkelsesavvik. Men kunden presiserte at ideelt sett så skulle man ikke ha avvik som ikke tilhørte en person fra starten av.
- Mine oppgaver fokuset for gjennomføring og datoer, ga ikke så mye mening for webappen. Det ble markert som en veldig god ide for de som utfører oppgaver, men at man på web burde ha et likt oppsett som “alle oppgaver”.
Generelt virket det som det var selve inndelingen av egne områder, og ikke tilpasningen på hver side som hadde mest verdi for kunden. Derfor fokuserte vi mindre på spesialtilpasning, og mer mot å få standard-funksjonaliteten så robust som mulig mot lansering.
LØSNING 2
Gjøre det lettere å filtrere seg frem til oppgaver.
Brukerne opplevde eksisterende filter som både forvirrende og lite nyttige. Mange “lagrede visninger” ble nesten aldri brukt, mens viktige behov som å filtrere på tid eller skille oppgaver fra rutiner, var dårlig støttet.
Gammel filter var en dobbel nøstet dropdown og hadde en lei tendens å droppe av siden.
Vi testet tre retninger for filtrering:
- Redesign av nåværende filter. Fordelen var at det var kjent for brukeren, men ulempen var at filteret ikke ble noe mer synlig.
- En filter modal. Uendelig med vertikal plass i menyen, men også i en undermeny,
- Pinnede filter. Mer synlig og lettere tilgjenglig, men går fort tomt for plass.
Initielle konsepter for redesign av filtere.
Vi landet på pinnede filter, fordi det var det var mest synlig for brukerene. Da var ikke bare inngangen til filteret mer synlig, men også hvilken filter som var tilgjengelig.
I tillegg la vi til filtrering på dato, og toggle mellom oppgaver og rutiner. Både for å gjøre det lettere for brukeren å orinetere seg over tid, men også for å isolere rutineoppgavene, fordi det ikke var innenfor scopet å lage en ordentlig løsning på rutinegenereringen.
I starten trodde vi at vi måtte beholde “lagrede visninger” og støtte alle gamle filter, men testing og tilbakemeldinger viste at kombinasjonen av pinnede filter og ny toppnavigasjon dekket behovene. Enkelte kunder var så fornøyde at de etterlyste disse filtrene kontinuerlig gjennom utviklingen.
Mot slutten dukket det like vell opp 2 problemer:
- Noen få, nøkkelkunder som ønsket lagrede visninger tilbake.
- Ytelsesproblemer fordi tusenvis av oppgaver ble lastet inn uten standardfilter.
Vi løste derfor dette i mot slutten av utviklingen med å introdusere tilbake egne visninger, med nye visninger for “Uløst/løst” som betydelig reduserte innlastingstiden.
Nåværende filter med egne visninger i platformen.
LØSNING 3
Forbedret skille mellom oppdatering og kommunikasjon
Selve oppgavevisningen var i utgangspunktet en relativt velfungerende del av løsningen, men vi oppdaget noen viktige svakheter. Det var uklart hvor oppgaven stammet fra (leietaker, rutine eller internt), og aktivitetsloggen skapte forvirring rundt hvem som kunne se hva.
I tillegg lå sjekklistene, som ofte var avgjørende for å gjennomføre oppgave, gjemt i en egen tab, noe som gjorde dem lite tilgjengelige.
Gammel oversikt inne på en oppgave.
Vi utforsket først en løsning der kommunikasjonen ble delt opp i tre separate faner for intern dialog, leietaker-kommunikasjon og systemaktiviteter. Enkelte syntes det var litt “skummelt” å skrive i aktivitetsloggen, så vi forsøkte oss på et design som lignet mer på meldingsdeling-apper.
Testingen viste imidlertid at brukerne savnet helheten og oversikten man fikk av å ha alt i hele visningen. Vi endte derfor med en kombinert aktivitetslogg med tydelige visuelle markører som skilte intern kommunikasjon, eksterne meldinger og systemaktiviteter.
3 itterasjoner av aktivitetslogg.
Vi tok lærdommen fra aktivitetsloggen, og endret også headeren på oppgaven til å visuelt refletkere hvor oppgaven kommer fra. Ofte hoppet brukerene mellom mange ulike oppgaver, og da var det viktig at man med første øyekast får en god oversikt over oppgaven.
Header på oppgave endrer seg basert på hvordan oppgaven er generert.
UTFORDRINGER MOT LANSERING
Den store refaktureringen.
Første itterasjon av designet tok omtrent 3 måneder. Etter det startet jeg på nye prosjekter mens teamet jobbet på oppgavesiden. 3 måneder senere, var jeg ferdig med redesign av eiendomssiden, og oppgavesiden var fortsatt ikke lansert. Det var flere grunner til dette:
- Teknisk gjeld: Vi undervurderte hvor mye gammel kode som måtte ryddes opp. Innen refaktoreringen var ferdig, var mye av designet allerede utdatert.
- Scope og prioriteringer: Hele oppgavesiden ble sett på som ett redesign. Det gjorde at små, verdifulle forbedringer ikke kunne slippes uten at alt annet var ferdig.
- Teamstørrelse: Vi var bare tre utviklere og én designer, alle nye i selskapet. Ambisjonsnivået var rett og slett for høyt.
Resultatet var et prosjekt som aldri føltes ferdig, mens bugs, kundeønsker og skisser hopet seg opp.
Fra UX/Tech, til produkteam.
Jeg innså fort at det var lite nytte i å ligge måneder foran utviklerne.
Jeg satte videre redesign på pause og begynte å støtte utviklerne tettere...bokstavelig talt. Vi flyttet diskusjonene fra møterom til pultene, kjørte kortere tester på kontoret, og jeg fikk slippe inn i kodebasen i et kort stint som frontendtuvikler (paddings, margins og flex-layout).
Resultatet var en mye bedre flyt i teamet der vi gjorde hardere prioriteringer, fikset UX problemer fortløpende med lavere terskel for sammarbeid. Det var ingen snarvei rundt den tekniske gjelden, men motivasjonen var høyere når vi var samlet som ett team.
Alle mann til pumpene, min første PR i Propely.
RESULTAT
Propely kundedag
Etter måneder med design, utvikling, refakturering og QA-testing, satte vi en hard deadline: betalansering på Propelys andre kundedag. Over 120 deltakere fra kundene våre var samlet for å se foredrag, nettverke, og ikke minst for å se de nye produktlanseringene.
CEO viser frem 3 nye redesign, oppgave web, oppgaver mobil og eiendomsside.
For produktteamet var dette en milepæl, og for meg personlig et høydepunkt. Av fire nye lanseringer denne dagen hadde jeg hatt ansvaret for tre av dem. Det markerte slutten på et langt og utfordrendre utviklingsløp, og lanseringen ble første gang hele kundebasen skulle se vår visjon for fremtiden til systemet.
Det var vanskelig å ikke la forventningene løpe løpsk. Heldigvis var mottakelsen alt annet enn skuffende.
“1000 ganger bedre enn gammel side” – Tilbakemelding i intercom
“Dette har vi ventet på lenge” – Fra kundedagen
“Endelig kan vi slutte å bruke den gamle siden” – I kundemøte med CS
Hva vi oppnådde
Selv om vi ikke hadde kvantitive analyseverktøy på plass, så vi en tydelig effekt av lanseringen av oppgavesiden:
For brukeropplevelsen
- Det var en høy innteresse for betalanseringen i etterkant av kundedagen, og initielle tilbakemeldinger via skjema har vært veldig positive.
- Alle henvendelser av “spøkelsesavvik” hos betabrukerene forsvant.
- Vi opplevde også at brukerene nesten ikke etterspør egne visninger lenger, takket være den nye indelingen og filtere.
- En av våre største kunder “nektet” å bruke gammel løsning før de fikk tilgang til den nye siden på grunn av de nye filterene.
For bedriften
- Salg rapporterer at brukeropplevelse er et av det største salgspunktene for både nye og gamle kunder, og at oppgaveredesignet gir trygghet i dette.
- CS har redusert tiden de bruker på oppgavesiden, de fleste henvendelser kommer nå fra brukere av gammel oppgaveside. Disse problemene løses ofte med å få kunden over på ny løsning.
- Vi fikk en mye smidigere utvikling med tettere sammarbeid mellom tech og design. Det gjorde at vi over det neste året fikk lansert 2 redesign og 1 helt ny på samme tid som oppgavesiden tok.
REFLEKSJONER
Realiteten av å være et “UX team-of-one”.
Jeg er utrolig takknemlig for tilliten og ansvaret jeg ble gitt under prosjektet. Mitt arbeid la grunnlaget for et helt år med utvikling og det var første gang en UX designer har vært involvert i bedriften. Det var både givende og lærerikt...men også ganske nærvepirrende.
For å kompensere prøvde jeg automatisere og systematisere meg ut av begrensninger, så jeg kunne være et “one-man-team” med alle av fordelene, og ingen av nedsidene. Notion, slack kanaler, prosedyrer og team-diagrammer. Jeg falt i samme fellen som jeg selv hadde utfordret teamet på:
“Husk at oppgaver løses i virkeligheten, ikke i systemet.”
Det var først da jeg begynte å stille meg selv spørsmålet: “Hva er én ting jeg kan gjøre, akkurat nå, for å støtte teamet?” at ting løsnet. Idealet om en perfekt UX-prosess ble lagt til side til fordel for å løse problemer med de ressursene jeg faktisk hadde.
Det betydde færre brukerinvolveringer, mindre tid på skisser og større vekt på teknisk gjennomførbarhet fremfor de mest ideelle løsningene.
Det var ingen sølvkule, men det bidro på smått og stort at vi fikk lansert.
← Tilbake til oversikt
Ny side
OPPGAVESIDE 2.0 REDESIGN
“En helt ny hverdag” for drift & vedlikehold av eiendommer i Propely.
Min rolle
Produkt designer – UX, UI, prototyping, designsystem, testing og research.
Platform
Webapp for drift og vedlikehold (FDV) i næringseiendom.
Team
Produkt → Meg + 3 utviklere og CEO
Tidslinje
Mar 2024 – Apr 2025
Første iterasjon → Beta
Om prosjektet.
Da jeg startet i Propely var selskapet i kraftig vekst i ARR (årlig inntekt), brukerbase og kundeønsker. Plattformen hadde flere års utvikling bak seg, men fundamentet begynte å vise sprekker. Feil og ustabilitet gjorde at utviklerne måtte bruke tid på brannslukking og midlertidige løsninger, mens Customer Success-teamet brukte mye tid på manuelle tilpasninger og workarounds for å dekke brukernes behov.
Jeg ble derfor ansatt sammen med tre utviklere for å etablere Propelys første dedikerte produktteam. Oppgavesiden ble valgt som første kandidat for et top-til-bunn-redesign, et slags pilotprosjekt for arbeidet videre.
Nesten ett år senere etter en heroisk innsats fra alle involverte, lanserte vi betaversjonen av Oppgaver 2.0 på Propelys kundedag. Det ble selskapets største lansering til da og ble godt tatt i mot, selv av våre mest kravstore kunder.
Demonstrasjon av en av mine største kvaliteter, ydmykhet.
BAKGRUNN
Hva er er egentlig Propely?
Propely er en digital plattform for forvaltning av næringseiendom: eiendom som leies av bedrifter, ikke privatpersoner. Platformen består av tre ulike løsninger som retter seg mot ulike aspekter av eiendomsforvaltningen:
- Portefølje: For økonomi og statistikk.
- Leietakerløsning: For alt det praktiske rettet mot leietakere.
- Drift og vedlikehold: Alt rettet mot det fysiske vedlikeholdet av bygg.
Oppgavesiden hører til «Drift og vedlikehold» og er den mest brukte og sentrale delen av Propely. Her samarbeider leietakere, teknikere, vaktmestere og leverandører om alt fra hull i vegger og tette toaletter til rutinesjekk av takrenner og overlevering av nøkler.
Målet for prosjektet.
Prosjektet var første steg i å rigge Propely for skalering ved å heve både designkvalitet og teknisk kvalitet. Oppgavesiden ble pilot og ledestjerne: løsningen måtte bli rask, stabil og intuitiv slik at Customer Success kunne bruke mer tid på onnboarding, og mindre tid på tilpasning.
Konkrete mål for Oppgavesiden 2.0:
- Redusere tid og ressurser Customer Success bruker på oppgavesiden
- Gjøre løsningen mer intuitiv og lettere å lære
- Avdekke og løse flest mulig brukbarhetsproblemer
- Etablere effektivt samspill og arbeidsform i det nye produktteamet
RESEARCH
Initiell oversikt over oppgaver.
For å få en oversikt over oppgavesiden, var det to spørsmål jeg ville ha innsikt i:
- Hvordan er systemet faktisk bygget?
- Hvordan brukes systemet ute hos kundene?
- Hvordan fungerer systemet?
Jeg startet med en heuristisk gjennomgang for et førsteinntrykk av systemet, men øvelsen ga begrenset verdi: oppgavesiden lente tungt på objekter og relasjoner jeg ikke kjente til (sjekklister, rutiner, koblinger m.m.).
I starten ble det mer spørsmål enn tilbakemeldinger på designet.
Derfor laget jeg et OOUX-kart for å få et «røntgenbilde» av strukturen. Det hjalp meg sette til sides initielle ideer om hvordan siden “burde” virke, og hjalp teamet kunne diskutere strukturen uten å henge seg opp i grensesnittet.
OOUX kart av selve oppgaven i systemet.
Noen observasjoner:
- En oppgave refererer til 9+ andre objekter i ulike deler av systemet.
- Noen relasjoner har skjult funksjonalitet. For eksempel ville det å legge til leverandør utløse en e-post/«bestilling», uten at det finnes en formell bestillingsflyt i systemet.
- Noen begrensninger var ikke synlige, som “sjekklister” som bare kunne brukes når oppgaven er knyttet til en rutine (opprettes et annet sted).
Oppgavesiden virket innledningsvis som en isolert del av systemet, men det viste seg at ting var mer sammenhengende enn jeg hadde trodd.
- Hvordan blir systemet brukt
Jeg intervjuet seks brukere for å samle konkret brukskontekst og tilbakemeldinger. Webappen brukes primært av dem som ikke er fysisk på byggene, og brukerene var derfor en blanding av:
- Driftsledere – delegerer oppgaver og følger opp vaktmestere og teknikere i felt.
- Forvaltere – har overordnet ansvar for eiendommen, inkludert kommunikasjon med leietakere.
Innsikt brukte jeg for å fylle ut en initiel oversikt (UX questionaire), og empathy map for konkrete utsagn.
Flere av brukerene opplevde at grunnleggende funksjoner var vanskelig å oppdage/sette opp, og at de derfor måtte lene seg på vårt CS team. Brukerene opplevde også siden som rotete og lite oversiktelig. Det var likevel ingenting funksjonelt som manglet, og kundene som hadde fått god oppfølging var generelt fornøyde. Som en av driftsteknikerne sa (litt paradoksalt):
“Jeg synes det var intuitivt, etter jeg hadde forstått det” – Driftstekniker
Men når et problem først oppsto, var det vanskelig for brukerene å forstå hva som hadde gått galt. Så selv når brukerene var godt kjent med løsningen, føltes siden ustabil og upålitelig. Da var veien kort til frustrasjon.
“Dette er fullstendig kaos” – Forvalter
“Rutiner må skrotes” – Driftstekniker
UX workshop
For å samle alle de ulike trådene inviterte jeg Salg, CS og tech til en UX workshop. Der kombinerte vi min og teamets erfaringer for å finne en rekke temaer vi kunne forbedre, og fikk innspill på hva de ulike teamene mente var viktig å prioritere.
Obligatorisk workshop post-it bilde.
KEY TAKEAWAYS
Resultatet fra research-fasen delte vi inn i 5 konkrete forbedringsområder.
1
Finne relevante oppgaver raskt.
Brukerene ble møtt med alt i en visning, og de slet med å finne oppgaver som var relevante for dem. Det resulterte i mye manuell leting og filtrering, og mange henvendelser til CS for å sette opp relevante visninger.
2
Bedre oversikt over mange oppgaver.
Brukerene av web-appen jobbet ofte i administrative roller, og måtte derfor få oversikt over mange oppgaver samtidig. Den nåværende sidenavigasjonen ga for lite relevant informasjon ved første øyeblikk, og gjorde det var begrenset med muligheter for bulk-redigering.
3
Gjør det lettere å jobbe med oppgaver over tid.
For brukerene var tid ofte viktig i arbeidet med oppgaver, spesielt skillet mellom oppgaver som er meldt inn vs rutineoppgaver som settes opp i fremtiden. Men mangelfull dato-filtrering, rutiner og blanding av start/opprettet datoer gjorde det vanskelig å få en oversikt over tid.
4
Gi brukerene mulighet til å fange opp oppgaver uten ansvarlige.
Enkelte av brukerene opplevde det de kalte for “spøkelsesavvik”. Oppgaver som rett og slett virket til å forsvinne i systemet, uten at noen kunne spore dem opp. Dette var oppgaver som ikke hadde noen ansvarlige knyttet til seg, men det føltes for brukeren som om systemet var ustabilt og at oppgaver kunne forsvinne når som helst.
5
Lag et tydelig skille mellom aktivitet på oppgaver, og kommunikasjon fra brukere.
Når man kommuniserer inne på en oppgave var det vanskelig å skille enkelt mellom hva som var en status oppdatering, hva som var kommunikasjon, og hva som var synlig for leietaker. Det gjorde at brukerene hadde vanskelig for å lett finne frem til kommentarer når de skulle lese seg opp på en oppgave.
LØSNING 1
Forbedret oversikt over oppgaver.
Drifterne opplevde oversikten som for enkel til å håndtere store mengder oppgaver, men samtidig uoversiktlig når de skulle finne egne eller andres ansvar. Særlig ble “spøkelsesavvik” oppfattet som problematiske, fordi de ikke lot seg finne igjen.
Konkrete problemer:
- Sidemenyen var for bregrensende for mengden oppgaver en forvalter eller driftsleder måtte navigere.
- I tillegg var det mye informasjon knyttet til oppgaven som ikke kunne vises i dette formatet.
- Arkiveringsfunksjonalitet måtte gjøres gjennom å sette et “standardfilter” som alltid filtrerte ut arkiverte filer.
- “Mine ansvarlige” var desidert den viktigste visningen hos kundene, men den kunne ikke enkelt kombineres med andre visninger te trengte.
Gammel oppgavesiden der arkiverte og løste oppgaver er filtrert ut som standard.
I tidlig fase skisserte jeg opp en rekke ideer å vise til teamet.
Hovedideen var å dele opp oppgavesiden i dedikerte sider. Da ville man få et nivå over visninger hvor man kunne sette opp visninger og funksjonalitet mer tilpasset de ulike bruksområdene.
Thumbnail skisser av utkast til ulik funksjonalitet jeg presenterte for teamet.
Oppdelingen ville da bli:
- Alle oppgaver: Siden ment for dem som sitter med overordnet ansvar, driftere og forvaltere med fokus på å oversikt og administrasjon.
- Mine oppgaver: Mine oppgaver skulle være mer fokusert på gjennomførelsen av oppgaver, og var derfor mer fokusert rundt frister og oppdateringer.
- Ubehandlede oppgaver: Fokus på å fange opp oppgaver med mangler, og synliggjøre “spøkelses-avvikene” som ikke hadde utførende eller ansvarlig.
- Arkiv: For å fjerne standardfiltrering og få arkiverte filer en egen plass hvor det føles trygt.
Initielt design av de ulike visningene.
Vi valgte også å gå fra en sidemeny, til tabellvisning. Dette var en endring som allerede var høyt etterspurt og delvis implementert, men lå nå sammen med sidemenyen i oversikten.
Den nye tabellen kom med en rekke forbedringer.
- Mer kompakt design med pinnet tittel, siden det var det viktigste for brukerene når de visuelt letet etter en oppgave.
- Notifikasjoner for nye oppdateringer, istedenfor at man må lese “sist oppdatert” dato.
- Egen tilpassing av rekkefølge på kollonnen.
Gammel vs ny oppgavetabell.
Jeg tok med designet ut til kundene for å få tilbakemeldinger på det nye oppsettet. Tilbakemeldingene var nesten utelukkende positive.
- Alle var veldig positive for det nye layoutet og ideen bak indelingen. Det ble beskrevet som “mye ryddigere”, og det føltes tryggere når egne oppgaver og arkiverte oppgaver var isolert på egne sider.
- Ideen bak “mangler deligering” ble godt tatt i mot, spesielt av de som hadde slitt med spøkelsesavvik. Men kunden presiserte at ideelt sett så skulle man ikke ha avvik som ikke tilhørte en person fra starten av.
- Mine oppgaver fokuset for gjennomføring og datoer, ga ikke så mye mening for webappen. Det ble markert som en veldig god ide for de som utfører oppgaver, men at man på web burde ha et likt oppsett som “alle oppgaver”.
Generelt virket det som det var selve inndelingen av egne områder, og ikke tilpasningen på hver side som hadde mest verdi for kunden. Derfor fokuserte vi mindre på spesialtilpasning, og mer mot å få standard-funksjonaliteten så robust som mulig mot lansering.
LØSNING 2
Gjøre det lettere å filtrere seg frem til oppgaver.
Brukerne opplevde eksisterende filter som både forvirrende og lite nyttige. Mange “lagrede visninger” ble nesten aldri brukt, mens viktige behov som å filtrere på tid eller skille oppgaver fra rutiner, var dårlig støttet.
Gammel filter var en dobbel nøstet dropdown og hadde en lei tendens å droppe av siden.
Vi testet tre retninger for filtrering:
- Redesign av nåværende filter. Fordelen var at det var kjent for brukeren, men ulempen var at filteret ikke ble noe mer synlig.
- En filter modal. Uendelig med vertikal plass i menyen, men også i en undermeny,
- Pinnede filter. Mer synlig og lettere tilgjenglig, men går fort tomt for plass.
Initielle konsepter for redesign av filtere.
Vi landet på pinnede filter, fordi det var det var mest synlig for brukerene. Da var ikke bare inngangen til filteret mer synlig, men også hvilken filter som var tilgjengelig.
I tillegg la vi til filtrering på dato, og toggle mellom oppgaver og rutiner. Både for å gjøre det lettere for brukeren å orinetere seg over tid, men også for å isolere rutineoppgavene, fordi det ikke var innenfor scopet å lage en ordentlig løsning på rutinegenereringen.
I starten trodde vi at vi måtte beholde “lagrede visninger” og støtte alle gamle filter, men testing og tilbakemeldinger viste at kombinasjonen av pinnede filter og ny toppnavigasjon dekket behovene. Enkelte kunder var så fornøyde at de etterlyste disse filtrene kontinuerlig gjennom utviklingen.
Mot slutten dukket det like vell opp 2 problemer:
- Noen få, nøkkelkunder som ønsket lagrede visninger tilbake.
- Ytelsesproblemer fordi tusenvis av oppgaver ble lastet inn uten standardfilter.
Vi løste derfor dette i mot slutten av utviklingen med å introdusere tilbake egne visninger, med nye visninger for “Uløst/løst” som betydelig reduserte innlastingstiden.
Nåværende filter med egne visninger i platformen.
LØSNING 3
Forbedret skille mellom oppdatering og kommunikasjon
Selve oppgavevisningen var i utgangspunktet en relativt velfungerende del av løsningen, men vi oppdaget noen viktige svakheter. Det var uklart hvor oppgaven stammet fra (leietaker, rutine eller internt), og aktivitetsloggen skapte forvirring rundt hvem som kunne se hva.
I tillegg lå sjekklistene, som ofte var avgjørende for å gjennomføre oppgave, gjemt i en egen tab, noe som gjorde dem lite tilgjengelige.
Gammel oversikt inne på en oppgave.
Vi utforsket først en løsning der kommunikasjonen ble delt opp i tre separate faner for intern dialog, leietaker-kommunikasjon og systemaktiviteter. Enkelte syntes det var litt “skummelt” å skrive i aktivitetsloggen, så vi forsøkte oss på et design som lignet mer på meldingsdeling-apper.
Testingen viste imidlertid at brukerne savnet helheten og oversikten man fikk av å ha alt i hele visningen. Vi endte derfor med en kombinert aktivitetslogg med tydelige visuelle markører som skilte intern kommunikasjon, eksterne meldinger og systemaktiviteter.
3 itterasjoner av aktivitetslogg.
Vi tok lærdommen fra aktivitetsloggen, og endret også headeren på oppgaven til å visuelt refletkere hvor oppgaven kommer fra. Ofte hoppet brukerene mellom mange ulike oppgaver, og da var det viktig at man med første øyekast får en god oversikt over oppgaven.
Header på oppgave endrer seg basert på hvordan oppgaven er generert.
UTFORDRINGER MOT LANSERING
Den store refaktureringen.
Første itterasjon av designet tok omtrent 3 måneder. Etter det startet jeg på nye prosjekter mens teamet jobbet på oppgavesiden. 3 måneder senere, var jeg ferdig med redesign av eiendomssiden, og oppgavesiden var fortsatt ikke lansert. Det var flere grunner til dette:
- Teknisk gjeld: Vi undervurderte hvor mye gammel kode som måtte ryddes opp. Innen refaktoreringen var ferdig, var mye av designet allerede utdatert.
- Scope og prioriteringer: Hele oppgavesiden ble sett på som ett redesign. Det gjorde at små, verdifulle forbedringer ikke kunne slippes uten at alt annet var ferdig.
- Teamstørrelse: Vi var bare tre utviklere og én designer, alle nye i selskapet. Ambisjonsnivået var rett og slett for høyt.
Resultatet var et prosjekt som aldri føltes ferdig, mens bugs, kundeønsker og skisser hopet seg opp.
Fra UX/Tech, til produkteam.
Jeg innså fort at det var lite nytte i å ligge måneder foran utviklerne.
Jeg satte videre redesign på pause og begynte å støtte utviklerne tettere...bokstavelig talt. Vi flyttet diskusjonene fra møterom til pultene, kjørte kortere tester på kontoret, og jeg fikk slippe inn i kodebasen i et kort stint som frontendtuvikler (paddings, margins og flex-layout).
Resultatet var en mye bedre flyt i teamet der vi gjorde hardere prioriteringer, fikset UX problemer fortløpende med lavere terskel for sammarbeid. Det var ingen snarvei rundt den tekniske gjelden, men motivasjonen var høyere når vi var samlet som ett team.
Alle mann til pumpene, min første PR i Propely.
RESULTAT
Propely kundedag
Etter måneder med design, utvikling, refakturering og QA-testing, satte vi en hard deadline: betalansering på Propelys andre kundedag. Over 120 deltakere fra kundene våre var samlet for å se foredrag, nettverke, og ikke minst for å se de nye produktlanseringene.
CEO viser frem 3 nye redesign, oppgave web, oppgaver mobil og eiendomsside.
For produktteamet var dette en milepæl, og for meg personlig et høydepunkt. Av fire nye lanseringer denne dagen hadde jeg hatt ansvaret for tre av dem. Det markerte slutten på et langt og utfordrendre utviklingsløp, og lanseringen ble første gang hele kundebasen skulle se vår visjon for fremtiden til systemet.
Det var vanskelig å ikke la forventningene løpe løpsk. Heldigvis var mottakelsen alt annet enn skuffende.
“1000 ganger bedre enn gammel side” – Tilbakemelding i intercom
“Dette har vi ventet på lenge” – Fra kundedagen
“Endelig kan vi slutte å bruke den gamle siden” – I kundemøte med CS
Hva vi oppnådde
Selv om vi ikke hadde kvantitive analyseverktøy på plass, så vi en tydelig effekt av lanseringen av oppgavesiden:
For brukeropplevelsen
- Det var en høy innteresse for betalanseringen i etterkant av kundedagen, og initielle tilbakemeldinger via skjema har vært veldig positive.
- Alle henvendelser av “spøkelsesavvik” hos betabrukerene forsvant.
- Vi opplevde også at brukerene nesten ikke etterspør egne visninger lenger, takket være den nye indelingen og filtere.
- En av våre største kunder “nektet” å bruke gammel løsning før de fikk tilgang til den nye siden på grunn av de nye filterene.
For bedriften
- Salg rapporterer at brukeropplevelse er et av det største salgspunktene for både nye og gamle kunder, og at oppgaveredesignet gir trygghet i dette.
- CS har redusert tiden de bruker på oppgavesiden, de fleste henvendelser kommer nå fra brukere av gammel oppgaveside. Disse problemene løses ofte med å få kunden over på ny løsning.
- Vi fikk en mye smidigere utvikling med tettere sammarbeid mellom tech og design. Det gjorde at vi over det neste året fikk lansert 2 redesign og 1 helt ny på samme tid som oppgavesiden tok.
REFLEKSJONER
Realiteten av å være et “UX team-of-one”.
Jeg er utrolig takknemlig for tilliten og ansvaret jeg ble gitt under prosjektet. Mitt arbeid la grunnlaget for et helt år med utvikling og det var første gang en UX designer har vært involvert i bedriften. Det var både givende og lærerikt...men også ganske nærvepirrende.
For å kompensere prøvde jeg automatisere og systematisere meg ut av begrensninger, så jeg kunne være et “one-man-team” med alle av fordelene, og ingen av nedsidene. Notion, slack kanaler, prosedyrer og team-diagrammer. Jeg falt i samme fellen som jeg selv hadde utfordret teamet på:
“Husk at oppgaver løses i virkeligheten, ikke i systemet.”
Det var først da jeg begynte å stille meg selv spørsmålet: “Hva er én ting jeg kan gjøre, akkurat nå, for å støtte teamet?” at ting løsnet. Idealet om en perfekt UX-prosess ble lagt til side til fordel for å løse problemer med de ressursene jeg faktisk hadde.
Det betydde færre brukerinvolveringer, mindre tid på skisser og større vekt på teknisk gjennomførbarhet fremfor de mest ideelle løsningene.
Det var ingen sølvkule, men det bidro på smått og stort at vi fikk lansert.