Hva er neste? 3 steg for prioritering av Backlog for eksperimentering

I tillegg til å hjelpe med å organisere en mengde idéer til konkrete handlingsplaner, så gjør prioritering hele virksomheten smartere ved å tvinge team som tester til å tenke nøye på faktorene som gjør eksperiment vellykket.

Her er de 3 stegene for hvordan man går frem:

Steg 1: Bygg et bibliotek av hypoteser

Før eksperiment kan prioriteres for gjennomføring, så må det finnes en hypotese . Hypoteser er antagelsene som gjøres om effekter før eksperimenter kjøres. Forslag fra ansatte og kunder, brainstorming, og denne listen er gode utgangspunkt for å lage relevante hypoteser.

Idéene som samles vil man ønske å se på ett sted for å kunne prioritere. Kall det et bibliotek, eller en backlog – uansett er dette stedet hvor eksperimentene utvikles og foredles.

Verktøy mine kunder har benyttet til backlog håndtering er blant annet:

• Trello
• Pros : Enkelt, lett tilgjengelig, visuell måte å administrere tester i forskjellige faser av utvikling.
• Cons : Fra det jeg har sett så er ikke løsningen så robust for helhetlig program administrasjon hvor mange enkle tester skal sammenstilles i større planer.
• JIRA
• Pros : Robust, konfigurerbart system som direkte kobler til utviklingsteamet. Bra for å styre kø av nye idéer, og har noe rapportering og visualisering.
• Cons : Ikke direkte brukervennlig. Kan gi friksjon med ikke-utviklere, og om kø for utvikling, eksperimentering og annet blandes så kan prioritering blir vanskeligere når mange hensyn må tas.
• Asana
• Pros : Bra for prosjektoppgaver og detaljerte lister for handlinger, sosial interaksjon og kommunikasjon.
• Cons : Kanskje best som organiseringsverktøy av sosiale enheter oppå underliggende verktøy for milepæler (lignende Basecamp og Trello), ikke sofistikert nok til å håndtere formler, integrasjoner og visuelle planer for fremdrift og ressurser.
• Dokumenter (Google Docs, Word, etc)
• Pros : Super enkelt, fleksibelt. Lett å lage og endre.
• Cons : Ingen dynamisk funksjonalitet, ikke spesielt bra for oppgavehåndtering, kanskje best for personlig planlegging og oversikt.
• Regneark (Google Sheet, Excel)
• Pros: ; Ekstremt fleksibelt, dynamisk funksjonalitet, grafer og visualisering innebygget; de-facto standard i virksomheter.
• Cons : Kan behøver mer tanker og innsats for å få til en god struktur for oppsett og oversikt, og vil behøve vedlikehold og kontroll for deling; desktop versjoner gjør deling mer komplisert.
• Basecamp
• Pros : Enkelt, sosialt. Tavler gir bra oversikt selv med mange lapper hengt opp. Elsker at det er lett å bruke.
• Cons : Som Trello så er Basecamp bra for individuelle tester, men mangler dybden i funksjonalitet og beregninger for mer avanserte utviklingsprogram.
• ...og sikkert mange andre bra prosjekt-systemer. Bruk noe som virker for dere!

Når backlog nå er fylt opp med gode idéer for eksperimentering, så er det neste spørsmålet: hvordan prioritere hvilke som skal gjennomføres, og hvilke som må vente? Her behøver vi kriterier for å velge.

Steg 2: Beslutte kriterier for prioritering

Dette er kjernen i prioriteringsprosesser. Her stakes kursen basert på faktorene vi anser som viktigst for vårt formål og reisen vi er på.

Grunnleggende teori om prioritering sier at viktighet av kriterier bør reflekteres i antatt verdi - på godt engelsk; Return on Investment (ROI).

ROI er, helt grunnleggende, forholdet mellom kostnaden ved å gjøre noe (investeringen) mot antagelsene om inntektene / konverteringene / leads / nedlastinger / views / delinger (verdiene) av innsatsen.

ROI for tester kan beregnes ved å tenke gjennom disse spørsmålene:

1. Lag estimat for innsatsen (kostnaden) av å teste. Når teamet er forbi introduksjon og opplæring i basis bruk og hvordan tester implementeres, så kan det lages ganske enkle oppsett for innsatsen som er nødvendig for hver test. Dette kan da vurderes inn i regnestykket:
• Antall timer for å designe og utvikle testene. Forskjellige medlemmer på teamet har forskjellige oppgaver og estimater for nødvendig tid.
• Antallet tester produksjonsteamet kan (bør) håndtere.. Gitt normal hverdag, hvordan kan tester designes slik at vi kan kjøre så mange tester som mulig? Høyere antall tester gir normalt høyere grad av suksess.
• Balanse mellom et bredt utvalg av enklere lavthengende frukter, og tester med høyere kompleksitet som kanskje har mer fundamental effekt på opplevelsen. Begge er viktige. Optimal mix er nok normalt en middelvei med noen flere enklere tester, og normalt litt lavere volum av kompliserte tester.
2. Lag estimat for effektene (verdien) hypotesene i testene skal søke å verifisere. Dette er normalt mye vanskeligere å avklare, spesielt fordi tester ofte søker å finne innsikt i ukjente effekter. Her er noen kriterier som kan påvirke:
• Er testen basert på et velkjent U/X konsept for optimalisering, som for eksempel å ta bort en distraksjon i en prosess for utsjekking? Det er bra og verdifullt, og det finnes ofte velkjente erfaringstall å støtte seg på for velkjente tester.
• Er testens formål fundamentert i en KPI? Velg å prioritere tester som er designet for direkte effekter som kan vises på bunnlinjen.
• Går testen inn i en kritisk arbeidsflyt? Omfattende optimalisering av brukeropplevelser vil se på mange aspekt av kundens adferd, men likevel er ikke alle alle funksjoner, sider og visninger av like stor verdi. Konverteringer på hovedsider og i viktigste prosesser vil naturligvis gi høyest effekt.
• Kundehistorie fra ehandel virksomhet som økte omsetning per besøkende ("RPV") med 38% ved å teste stegene i utsjekking (checkout).
• Skal eksperimentet teste strategi for budskap? Tester med tekster og meldinger har høy verdi da verifiserte gode tekster kan ha stor betydning for salg og markedsføring også utenfor digitale løsninger.
• Endrer eksperimentet mer enn ett element på en side? Eller er den presist fokusert på et enkelt element, som en overskrift eller en knapp? Mindre endringer på mindre elementer vil naturlig ha lavere effekt og behøve mer trafikk. Slike tester skal naturligvis også gjøres, de må bare vektes riktig i forhold til viktighet.
• Hvor dramatisk er endringene i variasjonene i forskjell fra originalen? Om det skal testes farge på knapper mot en kontroll som er blå, skal vi teste flere nyanser av blått eller skal vi teste alternative neonfarger? Graden av forskjeller vil ofte speile effekten som kan måles.

Ha i bakhodet... det alltid vil være elementer i en test som det ikke går an å vite med sikkerhet – det er tross alt derfor vi eksperimenterer! Mye innsikt vil ikke bli åpenbart før teamet kommer i gang med eksperimentering og virksomheten begynner å bygge felles erfaringer og erfaringstall på tvers av tester (for øvrig et godt argument for felles løsning for å samle tester og resultater!) Start et sted, og søk forbedringer i egen intern prosess med hvert resultat og hver iterasjon.

Om du eller teamet er ny til testing, så anbefaler jeg å prioritere lav innsats over høy verdi eksperimenter. Enklere eksperimenter – som å bytte et bilde , endre et "call to action" (CTA) – vil hjelpe på innføring og læring i prosessene for å bedre vurdere effekter og verdier av tester senere.

Og til slutt, det vil nok også alltid være andre hensyn som for eksempel:

• Deadlines . Enkelte tester skal støtte media kampanjer, web redesign prosjekt eller andre viktige initativ. Vær oppmerksom på andres utvidede behov og eksperimentenes rolle i å støtte den større virksomhetens tjenester og applikasjoner.
• Det sjefen sier du skal gjøre. Sjefer skal i utgangspunktet være bærere av virksomhetens overordnede strategi. Hvis sjefen din sier at du må prioritere web mobil tester, og du allerede hadde tenkt å gjøre dette, så vil du uansett tenke at det er en god idé å få det gjort og dytte det litt frem i køen. (Når det er sagt, når du først har utviklet og kommunisert et regime for prioriteringer, så er det enklere å skape forståelse hos ledelsen for prioriteringen av alles behov – med din smarte arbeidsmetode godt synlig for alle!)

Steg 3: Planlegg, bekreft, og gå i gang

Når du har rangert alle dine tester etter beste antagelser av ROI, så er alt som gjenstår å legge det inn i planer, bygge og levere. Du må danne fundamentet, lage dokumentasjon, og planer for vurdering av resultater for hvert eksperiment, og sette av tid til å formidle læring og innsikt. Dette behøver ofte GANTT prosjektoversikter eller andre gode verktøy for å omsette prioriteringene i forståelige planer som kan følges av deltagere og interessenter.

Sørg for at du er tro mot kriteriene du satt i forkant. Referer tilbake til opprinnelig logikk når du analyserer og rapporterer resultater. Ved å bygge et solid rammeverk for prioritering inn i strategien for eksperimentering, så lærer du også mer om de faktiske verdier av testene som kjøres. Du bli smartere med hver iterasjon. Og flinkere til å si "nei" til testene som ikke er verd innsatsen.