Jeg forsætter udviklingen af min iPhone app til at informere om ændringer på websites.
I sidste uge startede jeg en serie a blogposts hvor man kan følge udviklingen af min nye iPhone app til at overvåge og informere om ændringer på websites. Hvis du ikke var med fra starten kan du læse sidste uges indlæg her: Udvikling af en iPhone app: Idéen.
Siden jeg fik idéen til min nye app har jeg overvejet mange aspekter inkl. brugerinterface, serverarkitektur og forretningsmodel. Da det er min overbevisning at gode produkter starter med - ja produktet, så vil jeg allerede nu skitsere mine idéer til hvordan brugeren skal interagere med app'en. Dvs. lave interaktionsdesign og tegne wireframes.
Der er to centrale objekter i app'ens model: checks og notifikationer. Brugeren opretter et "check" som er en slags regel der f.eks. siger "Led efter ordet 2013 på apple.com/wwdc". Når reglen i et check bliver sand modtager brugeren en notification. Der bør derfor være en liste over checks og en liste over notifikationer i app'en så brugeren kan se og håndtere dem.
Den mest almindelige funktion vil nok være at holde øje med eksisterende checks, men det er også meget vigtigt at det er nemt at oprette nye checks. Det er nemlig en del af "onboarding" processen. Dvs. den process som nye brugere skal igennem før de begynder at få værdi fra app'en og derfor beslutter sig for at beholde den. Hvis en stor del nye brugere ikke kan finde ud af at oprette checks så vil de nok slette app'en og måske efterlade en negativ anmeldelse.
Ovenstående wireframe viser hvordan jeg har planlagt at app'en skal fungere. Hovedskærmen viser en liste over checks, men viser også med et badge på den midterste knap i navigationsbaren hvor mange nye notifikationer der er. Et tilsvarende badge vises på app-ikonet på homescreen. Ved at trykke på notifikationer-knappen vises en popover med en liste over notifikationer. For at oprette et nyt check trykker brugeren på "+" knappen i højre side af navigationsbaren. Dette simple flow opnår alle de ting jeg gerne ville: fokus på eksisterende checks, nem adgang til notifikationer og at lave nye checks. Jeg har bevidst undgået at bruge en såkaldt tabbar da funktionerne i app'en i høj grad er relateret til hinanden og derfor med fordel kan udspringe fra en enkelt hovedskærm.
I skrivende stund er flowet til at oprette nye checks endnu ikke færdigt. Mit mål er at gøre det super let at oprette checks/regler både for rutinerede brugere og får nye brugere som måske endnu ikke helt har forstået hvordan app'en virker. Derfor giver det mening at opdele processen i en række skærmbilleder hvor brugeren kun skal træffe en enkelt beslutning på hvert skærmbillede. På den måde kan der også blive plads til et par forklarende ord de steder hvor det ikke er indlysende hvad man skal gøre.
Når det komplette flow er på plads kan jeg fokusere på at designe arkitekturen for den webservice som skal sørge for at checke de forskellige websites og levere notifikationer til brugerne. Så følg med i næste uge som nok kommer til at handle om backendarkitekturen.
Ingen kommentarer:
Send en kommentar