Hjemmeside, webapp eller mobilapp?

1. Når kunden skal lære dig at kende

En hjemmeside er et godt udgangspunkt, når besøgende skal forstå dine ydelser, se dit arbejde og kontakte dig. Den skal fungere på både telefon og computer. Et bookinglink eller en formular gør ikke i sig selv en separat app nødvendig.

Forestil dig en salon med et bookingsystem, der allerede fungerer. Første opgave kan være en hjemmeside med behandlinger, priser og en tydelig vej til booking. Undersøg, hvad det eksisterende system kan, før du betaler for at få bygget et nyt.

2. Når brugeren skal gøre noget

En webapp er et værktøj, man bruger gennem browseren. Det kan være en kundeportal, hvor kunder følger en opgave, eller et internt system til registrering og godkendelse. Grænsen til en hjemmeside er flydende. Arbejdsgangen, data og adgangen er vigtigere end navnet.

Forestil dig et firma, der sender dokumenter frem og tilbage på mail. En portal kan samle dokumenter og godkendelser. Første version kunne nøjes med login, én dokumenttype og et tydeligt svar fra kunden. Kalender, chat og rapporter kan vente, hvis de ikke er nødvendige for den opgave.

Nogle webapps kan også installeres på enheden og bygges med offlinefunktioner eller notifikationer. Det kaldes ofte en PWA. Mulighederne afhænger af funktion, browser og enhed, så de skal undersøges og testes konkret.

3. Når telefonen er et arbejdsredskab

En mobilapp til iPhone eller Android kan være relevant, når den bruges jævnligt på farten, eller når samspillet med telefonen er afgørende. Men kamera, notifikationer eller dårlig dækning er ikke alene nok til at vælge platform. Beskriv præcis, hvad der skal virke og på hvilke enheder.

Forestil dig medarbejdere, der tager billeder og registrerer arbejde ude hos kunder. Skal registreringer gemmes uden forbindelse? Hvad sker der, hvis to personer retter samme opgave? Vi afprøver de afgørende funktioner, før vi anbefaler mobilapp eller webapp.

Ved udgivelse i App Store eller Google Play kommer konti, butiksmateriale og gennemgang oveni udviklingen. Planen skal give plads til butikkernes behandling og eventuelle rettelser. En bestemt godkendelsesdato kan ikke loves.

4. Det er opgaven, der bestemmer prisen

En enkel mobilapp kan være mindre omfattende end en stor webapp. Antallet af skærme fortæller heller ikke hele historien. Det er blandt andet disse valg, vi skal kende for at give et brugbart estimat:

• Brugere og adgang: Hvem må se, ændre og godkende hvad?
• Data og integrationer: Hvilke systemer skal forbindes, og skal gamle data flyttes?
• Særlige funktioner: Betaling, offlinearbejde og synkronisering kræver hver sin afklaring.
• Platforme og test: Hvilke telefoner, browsere og forløb skal understøttes?
• Efter aflevering: Hvem står for hosting, opdateringer og support?

5. Beskriv en lille, brugbar første version

Vælg én vigtig arbejdsgang, som skal kunne gennemføres fra start til slut. Aftal, hvordan I tester den, og hvem der skal prøve den. En klikbar prototype kan afklare skærme og navigation; tekniske usikkerheder kan kræve en særskilt afprøvning.

Du behøver ikke vælge teknologien på forhånd. Skriv i stedet svar på de tre spørgsmål nedenfor. Eksemplerne i guiden er tænkte situationer, ikke kundecases.

• Hvem skal bruge løsningen, og hvor ofte?
• Hvilken opgave skal de kunne løse i første version?
• Hvad bruger I i dag, og hvad fungerer dårligt?