Tilblivelsen af en app starter for os på mange forskellige måder. Nogen af vores kunder og partnere har en grundig beskrivelse, en mockup og måske ligefrem et design klart allerede når de ringer til os. Andre har en skarp idé, som vi hjælper med at få gjort konkret.
Vi har lavet en formel for et rigtigt godt udgangspunkt for et brief:
Appen gør det muligt for Y at X, i situation Z
Et eksempel på et brief kunne være: “Netbank-appen gør det muligt for de unge kunder at tjekke deres saldo i bussen”.
Eller: “Børn i byens app gør det muligt for mødre og fædre til mindre børn at finde ud af hvad de skal lave i weekenden over morgenmaden lørdag morgen”.
I mange tilfælde vil appen kunne mere end én ting, men det er vigtigt at finde kernen. Det vi leder efter, er det 80% scenarie, som vil dække den mest almindelige brug af en fremtidig app. At man så i en netbank-app også vil kunne overføre penge og skrive til ens rådgiver, kan man altid tilføje. En god app – og en god brief – har konkrete handlinger, for konkrete brugere, i specifikke situationer.
Den anvendelige brugeroplevelse
Når man arbejder strategisk med det digitale område, og udvikler brugeroplevelser for sine kunder, så er man tilbøjelig til at udvikle hele universer. F.eks. at ens netbank skal være det sted man går hen, for alt hvad der handler om penge og privatøkonomi. Men i forhold til at udvikle en app – en helt konkret og anvendelig brugeroplevelse – er det scope alt for stort.
Det som vores formel er god til, er, at sikre at I finder den minimums brugeroplevelse, som alle jeres kunder kan anvende. Og de kan gøre det nemt og hurtigt, første gang de åbner appen. Hvis de skal orientere sig i et komplekst univers inden de får noget ud af det, så risikerer man at de fravælger appen.
I behøver ikke skrive en komplet projektbeskrivelse
I mange digitale organisationer er man blevet meget dygtig til at skrive specifikationer og løsningsbeskrivelser. Men det er slet ikke nødvendigt. Hvis I har specificeret alt, så sætter vi sådan set “bare” strøm til jeres prototype, og I får ikke samme gavn af den erfaring vi har fra lignende projekter.
Når I briefer os, er det godt, hvis I er bevidste om, hvilke kompetencer I selv har og hvor I har brug for at vi supplerer. Er I gode til UX, men mindre stærke på den reelle UI? Har I stor kvalitativ viden om jeres kunder, men lav datakvalitet?
Sidst men ikke mindst, så indeholder en god brief en budgetindikation. Eller et budgetønske. Når man begynder at arbejde med et produkt eller en service, som en app er, så har man ofte en idé om hvilke værdi den har for organisationen. Og dermed har man også et budget i hovedet.
Så kort og godt, når I briefer jeres app-bureau, så husk at:
- Et detaljeret brief er ikke nødvendigvis godt
- Enkle prototyper og visualiseringer er gode til at afstemme forventninger
- Tænke i mål, ikke midler – “Appen gør det muligt for Y at X, i situation Z”
- Vide, hvad I ved og kan – og hvor I har brug for ekstra kompetencer