Seismonaut har flere hjemmesider,
som du er velkommen til at besøge:

Seismonauts øvrige sider

Blog

Et framework til app-udvikling i det offentlige

04.11.2011

Dette ganske enkle framework er udviklet, da vi i forbindelse med et fælleseuropæisk Interreg- og VERDI-projekt lagde grundarbejdet for en app for nationalparker i Norden. Projektet indeholdte mange af de typiske udfordringer, som offentlige app-projekter står over for. Mange partnere, komplekse setups og problemstillinger, samt mange krav om funktioner.

Frameworket kan med fordel bruges som en behovsafklaringsmodel, når man vil i gang med udvikling af sin egen app - inden man tager fat i udviklerne.

Research på forhånd

Et godt sted at starte ethvert udviklingsprojekt er med at se på eksisterende tilbud i samme sfære. Hvad er gjort tidligere? Hvad kan man lære af, og hvad kan man gøre bedre? Man skal så at sige have jord under neglene. Download løs. Prøv af. Find så mange relevante applikationer som muligt, og prøv at opleve dem, som borgeren ville. Hvis ikke du synes, det virker, så gør borgeren sandsynligvis heller ikke!

Det er også i denne fase, at man skal være hudløst ærlig med sig selv og vurdere, om app'ens præmis holder. Man skal opstille nogle mål:

  • Hvad vil vi?
  • Hvorfor vil vi det?
  • Og endelig, hvordan vil vi opnå det?

Det lyder simpelt, men at besvare ovenstående spørgsmål kan faktisk være en lang proces.

Mål

Brugsscenarier er en særdeles god ide

Siden brugssituationerne varierer noget mere for mobilbrug, end de gør ved fx computerbrug, så er det en fremragende idé at udvikle brugsscenarier. Det gøres med henblik på at forestille sig, hvordan app'en vil blive brugt af borgeren. Udover naturligvis at hjælpe med at finde funktioner, som man skal have med, så kan det også hjælpe i forhold til at undgå funktionalitetsdøden. For mange funktioner og muligheder kvæler de gode. "Less is more" gælder i høj grad stadig som læresætning.

Scenarier

Derudover kan brugsscenarierne være gode til at udstille evt. problemstillinger, som man ikke før har spekuleret over. Skal en app bruges i en nationalpark er mobildækning fx et vigtigt punkt. Hvis man ønsker kort og ruter indbygget, så bør man kraftigt overveje om standardløsningen i form af Google Maps er den rigtige - den virker nemlig ikke uden netforbindelse. Hvis borgeren står midt i en skov, så er det langt fra sikkert, at der er forbindelse til mobilnettet, og dermed vil kortfunktionen være ubrugelig. Derfor skal man i stedet benytte indlejrede kort, fx sammen med GIS-data.

Research + scenarier = funktionalitetskatalog

Når man har været gennem de to indledende faser, så har man forhåbentlig opbygget en viden om app'ens eksistensberettigelse, dens funktioner og dens intenderede brug. Man kan derfor nu udpensle hvilke funktioner, man faktisk vil have med. De kan med fordele være begrænset ud fra den forventede brug, sådan at brugeren af app'en ikke drukner i muligheder.

Forankring i organisationen

På nuværende tidspunkt kan man med fordel sørge for at inddrage de forskellige aktører i projektet via eksempelvis workshops. Det er vigtigt, at man sørger for at skabe forankring blandt medarbejderne i den givne offentlige instans. Præsentationen af funktioner og foreløbige resultater har desuden den fordel, at man fra disse ofte vil modtage yderligere værdifuldt input, som stadig kan inddrages i projektet. Hvis input kommer meget senere i processen, vil det være svært at få det med i den endelige kravspecifikation.

Den endelige kravspecifikation

Efter at have gennemført ovenstående punkter står man stærkt i forhold til at udvikle en egentlig kravspecifikation. Man har et overblik over krav til funktioner, og disse skal naturligvis pakkes ind i et fornuftigt og brugbart design. Har man kompetencerne kan man overveje at medsende en mockup eller foreslået menustruktur til udviklerne, men det er ikke en nødvendighed.

Det ønskede resultat

Ved at gøre sit hjemmearbejde ender man forhåbentligt med en applikation, som står stærkt i forhold til borgeren. Den indeholder funktioner, som slutbrugeren finder nyttige, den er lavet med brugssituationerne in mente, og den gør ikke mere, end den behøver.

Ved at følge ovenstående simple regler, mener vi, at man vil kunne undgå mange mere eller mindre fejlslagne app-tiltag - og det vil i sidste ende være til glæde for både brugeren af app'en og afsenderen af den.

Del denne side på: email + facebook + twitter