Fra et vagt funksjonsønske til en tydelig leveranseplan
Følg et eksempel på brukerintroduksjon fra et åpent spørsmål til en liten, testbar forbedring, med et tankekart som vokser etter hvert som beslutningene blir tydeligere.
Noen sier: «Vi må gjøre det enklere å komme i gang.»
Alle er enige. Så kommer forslagene: legg til en sjekkliste, kort ned oppsettet, skriv bedre veiledninger, send en velkomst-e-post.
Snart er det nok ideer til å fylle en sprint. Det som er mindre tydelig, er hvilket problem teamet prøver å løse.
Dette er et godt tidspunkt å lage et tankekart på. Det gir teamet et sted å utforske ønsket, knytte ideer sammen og holde ubesvarte spørsmål synlige før dere bestemmer hva som skal bygges.
I denne veiledningen følger vi et fiktivt team som jobber med et produkt for delte arbeidsområder. Nye kunder oppretter en konto, setter opp et arbeidsområde og inviterer kollegene sine. Teamet har blitt bedt om å forbedre denne opplevelsen.
Vi tar ønsket fra en åpen diskusjon til en liten, tydelig beskrevet arbeidsoppgave i Jira. Dere kan følge samme prosess med et hvilket som helst tankekartverktøy.
1. Start med ønsket, uten å behandle det som svaret
«Gjør det enklere å komme i gang» uttrykker en hensikt. Det forteller oss ennå ikke hvor folk strever, eller hva som bør endres.
Teamet setter Forbedre brukerintroduksjonen i midten av kartet og legger til fire grener:
- Opprett en konto
- Sett opp et arbeidsområde
- Inviter kolleger
- Gjør noe nyttig sammen for første gang
Dette gir samtalen en form. I stedet for å diskutere «brukerintroduksjon» som ett stort problem kan deltakerne peke på en bestemt del av opplevelsen.
Teamet legger til det de vet i dag, ved de relevante grenene. I vårt fiktive eksempel har brukerstøtten fått spørsmål om hvor man inviterer kolleger. Under en gjennomgang leter en ny eier av et arbeidsområde etter en invitasjonsfunksjon på arbeidsområdets startside. Funksjonen finnes, men ligger i innstillingene for arbeidsområdet.
Disse observasjonene peker på noe som bør undersøkes. De beviser ikke at hele introduksjonsflyten må bygges om.
Teamet lar de andre grenene stå på kartet og retter oppmerksomheten mot Inviter kolleger.
2. Skill det dere vet, fra det dere tror
En forklaring kan lett begynne å høres ut som et faktum når noen sier den med overbevisning.
«Folk inviterer ikke kollegene sine fordi invitasjonsprosessen er for komplisert.»
Kanskje. Men strever de med å finne skjemaet, fylle det ut eller forstå hvorfor de skal invitere noen allerede nå? Dette er ulike problemer.
Under invitasjonsgrenen lager teamet tre grupper.
Observert
- Brukerstøtten har fått spørsmål om hvor man inviterer kolleger.
- En eier av et arbeidsområde lette etter invitasjoner på startsiden.
- Den nåværende invitasjonsfunksjonen ligger i innstillingene for arbeidsområdet.
Antatt
- En mer synlig inngang ville hjelpe folk å finne funksjonen.
- Noen eiere er kanskje ikke klar over at det å invitere kolleger er et nyttig neste steg.
Fortsatt uklart
- Kan eierne fylle ut det eksisterende skjemaet når de først finner det?
- Forstår de som mottar en invitasjon, hva de skal gjøre videre?
Etikettene er viktigere enn den visuelle utformingen. Alle som ser på kartet, bør kunne skille en observasjon fra en mulig forklaring.
Før teamet velger en løsning, ber det noen nye eiere av arbeidsområder vise hvordan de inviterer en kollega. Teamet ser hvor de leter, og spør hva de forventer skal skje, uten å vise dem invitasjonsfunksjonen først.
I dette eksemplet tyder gjennomgangene på at den umiddelbare hindringen er å finne skjemaet. Når eierne får se inngangen, klarer de å fylle det ut. Mottakerens opplevelse må fortsatt undersøkes separat.
Teamet kan nå beskrive et mer avgrenset problem:
“Nye eiere av arbeidsområder finner ikke enkelt frem til hvor de kan invitere kollegene sine.”
Dette er konkret nok til å lede den neste diskusjonen. Det er også noe teamet kan vende tilbake til etter å ha gjort en endring.
3. Utforsk noen tiltak for det samme problemet
Med et tydeligere problem vender teamet tilbake til mulige forbedringer. Det legger til tre alternativer på kartet:
- Legg funksjonen Inviter kolleger på arbeidsområdets startside.
- Legg til et invitasjonstrinn i det første oppsettet.
- Send en oppfølgings-e-post som forklarer hvordan man inviterer kolleger.
Alle alternativene kan hjelpe, men de når eieren på ulike tidspunkter.
Funksjonen på startsiden vil være tilgjengelig når noen vender tilbake til arbeidsområdet. Et oppsettstrinn kan introdusere invitasjoner tidlig, men noen eiere er kanskje ikke klare til å invitere andre ennå. En e-post kan være en påminnelse, selv om eieren fortsatt må gå tilbake til produktet.
Teamet skriver en kort merknad ved hvert alternativ om hva det er ment å hjelpe med. Slik holder diskusjonen seg knyttet til problemet, i stedet for å bli en avstemning om alles favorittfunksjoner.
Det er ikke nødvendig å kartlegge alle tenkelige løsninger. Start med noen rimelige tiltak, og spør:
- Tar dette tak i vanskeligheten vi observerte?
- Vil det hjelpe når eieren trenger det?
- Hva må vi lære eller endre for at det skal fungere?
Et nyttig kart gjør disse valgene enklere å diskutere. Flere grener er ikke automatisk bedre.
4. Velg ett nyttig første steg
Teamet velger å teste en synlig invitasjonsfunksjon på arbeidsområdets startside.
Hvorfor dette alternativet? Det svarer direkte på hvor eierne lette, og teamet kan bruke det eksisterende invitasjonsskjemaet. Funksjonen vil også være tilgjengelig for eiere som bestemmer seg for å invitere kolleger senere.
Dette er et utgangspunkt, ikke en påstand om at alle problemer med brukerintroduksjonen er løst.
Teamet utvider den valgte grenen med omfanget de er enige om, og noterer utsatte ideer og gjenstående undersøkelser ved siden av planen:
Med i denne forbedringen
- Legg til en tydelig merket invitasjonsfunksjon på arbeidsområdets startside.
- Åpne det eksisterende invitasjonsskjemaet fra funksjonen.
- Behold de eksisterende invitasjonstillatelsene og måten invitasjoner sendes på.
Senere
- Vurder om et invitasjonstrinn hører hjemme i det første oppsettet.
- Vurder om en oppfølgende påminnelse vil være nyttig.
Må undersøkes
- Sjekk opplevelsen av å motta og godta en invitasjon.
Når disse gruppene holdes synlige, blir det lettere å unngå at de samme beslutningene tas opp på nytt gang på gang. E-postideen har ikke forsvunnet. Mottakerens opplevelse er ikke glemt. De er bare ikke en del av denne første forbedringen.
På dette tidspunktet sjekker teamet også med dem som skal implementere endringen. Å gjenbruke et eksisterende skjema høres enkelt ut, men det kan finnes begrensninger som påvirker fremgangsmåten. Det er bedre å oppdage dem før omfanget regnes som fastsatt.
5. Beskriv hva en person skal kunne gjøre
«Legg til en invitasjonsknapp» beskriver en endring i grensesnittet. Det sier mindre om opplevelsen teamet ønsker å skape.
Et mer nyttig spørsmål er:
“Hva skal en eier av et arbeidsområde kunne gjøre når denne forbedringen er ferdig?”
Teamet blir enige om et kort sett med kontrollpunkter:
- En eier med tillatelse til å invitere kolleger kan finne funksjonen Inviter kolleger på arbeidsområdets startside.
- Når funksjonen velges, åpnes det eksisterende invitasjonsskjemaet for det gjeldende arbeidsområdet.
- Eieren kan fullføre invitasjonen med den eksisterende flyten.
- En person uten invitasjonstillatelse får ikke tilgang gjennom den nye funksjonen.
- Funksjonen kan brukes på skjermstørrelsene produktet støtter, og kan nås med tastatur.
Dette er akseptansekriterier: observerbare vilkår teamet kan bruke til å kontrollere arbeidet sitt. De trenger ikke være skrevet som en teknisk spesifikasjon.
Det er også to ulike spørsmål som må holdes atskilt. Leverte vi den avtalte endringen? besvares ved å kontrollere disse vilkårene. Gjorde endringen invitasjoner enklere å finne? krever at dere observerer hvordan folk bruker den.
En knapp kan fungere nøyaktig som spesifisert og likevel bli oversett.
6. Flytt det avtalte arbeidet til Jira
Kartet har hjulpet teamet med å utforske ønsket og ta en beslutning. Nå er den valgte forbedringen klar til å bli en oppgave noen kan ta fatt på.
Teamet oppretter én Jira-sak for det avtalte resultatet. Det oppretter ikke en sak for hver gren på kartet.
Dette kan saken inneholde:
Tittel: Gjør det mulig å invitere kolleger fra arbeidsområdets startside
Hvorfor dette er viktig: Nye eiere av arbeidsområder har hatt problemer med å finne invitasjonsfunksjonen i innstillingene. Vi ønsker at eiere skal kunne starte en invitasjon fra startsiden, der de allerede leter etter den.
Omfang: Legg til funksjonen Inviter kolleger som åpner det eksisterende invitasjonsskjemaet for det gjeldende arbeidsområdet. Behold de eksisterende tilgangsreglene og invitasjonsatferden.
Ikke inkludert: En ny oppsettsflyt, påminnelser på e-post eller endringer i opplevelsen av å godta en invitasjon.
Akseptansekriterier: Ta med kontrollpunktene dere ble enige om i forrige avsnitt.
Planleggingsbakgrunn: Legg inn en lenke til kartet, slik at alle som jobber med saken, kan se observasjonene, alternativene og beslutningen om omfang.
Avhengig av hvordan teamet jobber, kan design og implementering bli egne oppgaver. Del opp arbeidet når det gjør ansvar eller leveranse tydeligere, fremfor å kopiere kartets struktur automatisk til Jira.
En gren organiserer tanker. En sak beskriver arbeid. De trenger ikke å samsvare én til én.
Hvis tankekartverktøyet deres kan kobles til Jira, kan dere kanskje opprette saken fra den valgte noden og holde koblingen synlig på kartet. Hvis ikke, kan dere opprette saken separat og legge til en lenke. Uansett bør dere gjennomgå saken før dere overleverer den: en kort nodeetikett inneholder sjelden all bakgrunnen noen trenger.
Når gjennomføringen starter, holder dere status og ansvar i Jira. Bruk kartet til det større problemet, begrunnelsen for beslutningen og spørsmålene som fortsatt er åpne. Det gir hvert sted et tydelig formål og reduserer fristelsen til å vedlikeholde to separate oppgavelister.
7. Sjekk om det opprinnelige problemet har blitt lettere å håndtere
Etter at endringen er lansert, vender teamet tilbake til setningen det skrev tidligere:
“Nye eiere av arbeidsområder finner ikke enkelt frem til hvor de kan invitere kollegene sine.”
Kan nye eiere nå finne invitasjonsfunksjonen uten å bli vist hvor den er? Kan de fortsette gjennom det eksisterende skjemaet? Tyder samtaler med brukerstøtten på at den samme forvirringen fortsatt oppstår?
Hvis teamet har egnede produktmålinger, kan det også se på hvor mange nye eiere av arbeidsområder som starter og fullfører en invitasjon. Tallene trenger kontekst: Noen eiere kan bevisst jobbe alene, og andre endringer kan påvirke resultatene.
I denne fiktive historien trenger vi ikke å finne på et vellykket resultat. Det nyttige neste steget er å observere hva som skjer, og legge lærdommen til på kartet.
Hvis eierne finner funksjonen, men står fast senere, har teamet et mer konkret problem å utforske. Hvis endringen hjelper, kan det avgjøre om det er verdt å jobbe videre med en annen forbedring.
Det opprinnelige ønsket var bredt. Planen som kom ut av det, er fokusert: et tydelig problem, et valgt tiltak, et håndterbart omfang og en måte å sjekke om tiltaket hjalp på.
Det er dette som gjør kartet nyttig. Det fører samtalen fra «vi bør forbedre dette» til et avtalt neste steg, samtidig som begrunnelsen og de ubesvarte spørsmålene forblir synlige.
Relaterte artikler
Ta Kontakt
Har du spørsmål om artikkelen? La oss diskutere de tekniske målene deres.