At designe apps til store organisationer, handler grundlæggende om to ting: de svære fravalg, og hvordan man arbejder som et lille team i en stor organisation.

At lave tekniske udviklingsprojekter i store organisationer er svært
De fleste, der selv er en del af en stor organisation, kender udfordringerne, da de er de samme i alle prestigeprojekter. Og apps er fortsat et prestigeprojekt i langt de fleste organisationer.

Problemerne drejer sig ofte om tre temaer:

1. App-projekterne har mange stakeholdere og ofte flere ejere, hvilket gør projektledelsen til noget, der skal køres af en erfaren person, og ønskelisten til funktionalitet lidt for lang
2. Appen skal ofte løse adskillige forretningsmæssige problemer samtidig med, at man ønsker at det hele skal samles i en app og kan har svært ved at skære noget fra
3. Der er lange beslutnings- og godkendelsesprocesser, hvilket ofte kombineres med konsensuskultur. Det betyder, at de svære beslutninger, der skal tages, ofte bliver taget for sent

Det betyder ikke, at man ikke skal binde an med at bygge en app til en stor organisation. Det er dem, der har ambitionerne og ressourcerne til at få skabt de brugeroplevelser, der rykker deres marked. Det er dem, der har adgang til data og integrerbare systemer. Og det er i de store organisationer, der sidder eksperter på andre tekniske områder, som kan hjælpe med at løfte appen til et andet niveau. Det er blandt andet derfor, at vi synes det er nogen af de sjoveste projekter, selvom den organisatoriske kompleksitet er mindst lige så høj som den tekniske.

Vi har tre ting vi går efter, når vi laver apps til store organisationer og virksomheder:

1.Vi starter med at lave et MVP (Minimal Viable Product)
Vi mener at det bedste man kan gøre for sin kommende app, er at starte med at skære til benet og finde den grundfunktionalitet og oplevelse, som brugeren skal have (læs hvordan man f.eks. kan lave et brief på én sætning). Og det er den app, vi skal starte med at bygge – ikke en app, der er sat sammen af ønskelister, der er akkumuleret ved at blive sendt rundt i organisationen, og derefter ikke sorteret i. Når man starter store, prestigefyldte projekter, tror jeg man tit tænker, at man skal have så meget ud af det som muligt, som organisation – deraf de lange kravslister. Og det er synd, for så glemmer man den bruger, man designer til, som bliver en gladere bruger af en enklere app.

2. Vi løser ét forretningsproblem ad gangen – gerne i én app ad gangen
I familie med MVP’en er at tage de svære fravalg, ikke kun på krav til funktionalitet, men på, hvilke forretningsmæssige problemer en app kan og skal løse. Man hører af og til briefs på apps, der både skal øge salg og kundeloyalitet, samt effektivisere kundesupport og købsprocessen. Af og til løser en skarpt designet app mere end det den er designet til – men det er fordi den er skåret skarpt. Ja, MobilePay var den bedste branding Danske Bank kunne lave, den bedste rekrutteringskampagne, den bedste måde at lade kunder overføre penge uden at de skulle igennem en filial eller netbankens login osv osv. Men det skyldes, at MobilePay startede med at løse ét problem og løse det godt: at overføre penge uden NemID, mens man er på farten.

3. Vi kører skunkwork-processer
Vi har lært, at de bedste apps bliver lavet i små teams, der flyver under radaren. Et lille undergrundsteam, med mandat til at løse et problem (IKKE med mandat til at tjekke krav af en liste), kan træffe hurtige beslutninger, godkende delleverancer og kan overskue projektet.

Vi synes det er ærgerligt, hvis for stor en del af projektets ressourcer bliver brugt på at holde en stor gruppe mennesker orienteret hver uge. De mandetimer og de penge, kan bruges bedre på at udvikle og markedsføre
apps.