De app deel 2: UI ontwerp bij jodiBooks

Of het nou een app, een website of andere software is, het bestaat altijd uit een voorkant en een achterkant; de front-end en de back-end. Meestal worden alle berekeningen in de back-end gedaan en daar wordt ook alle data opgeslagen. Maar daar ben je als gebruiker helemaal niet in geïnteresseerd. Jij wilt zo simpel mogelijk dingen invoeren en de uitkomst zien. Dat doe je in de front-end, ofwel de UI (de user-interface).

De UI van een website of app moet zoals alles wel ontworpen worden. En dat is makkelijker gezegd dan gedaan. Hoewel er heel veel studies zijn gedaan naar hoe je een UI moet vormgeven, blijft het heel subjectief. Bij een UI bepalen namelijk mensen of iets goed of fout is, niet een computer. En mensen hebben altijd een andere mening.

Sommige mensen willen zoeken, andere door een menu bladeren. Sommige mensen willen swipen, andere willen op een knop drukken. En dan hebben we het nog niet gehad over wat mensen mooi vinden.

Het programmeren van de berekeningen en de database is daarentegen heel objectief. Het moet iets doen en de uitkomst staat vast. Dus als jouw code de juiste uitkomst uitspuugt, is het goed. De computer bepaalt of het goed of fout is en een computer kent alleen maar niet-waar (false) of waar (true). Daar zit niks tussen.

UI discussies

Dat de user-interface heel persoonlijk is, weten we uit eigen ervaring. Wij kunnen met zijn tweeën al ontzettend steggelen over de indeling van de jodiBooks app. Dan vind de een iets heel logisch en de ander totaal verwarrend. En dan zijn wij nog de twee mensen die het met elkaar eens zijn over wat de app moet doen en kunnen.

We zijn natuurlijk maar met zijn tweeën. Dus wie heeft er gelijk als het gaat over de positie van een knop of het gekozen woord bij een invoerveld? Dat weten we niet. De enige manier om erachter te komen wat (de meeste) mensen handig vinden, is het in hun handen geven. Probeer het. Test het. En laat ons weten wat je vindt.

Strikt genomen hebben we het hier al niet meer alleen over de UI. Zodra je praat over hoe de gebruiker de app ervaart, heb je het over UX (user experience). Je kijkt dan niet alleen meer naar de vorm van een knopje en de gebruikte tekst. Je gaat dan meer erbij pakken. Bijvoorbeeld wat zou een gebruiker verwachten dat er gebeurt als hij op deze knop drukt? Of vragen we zijn input in de juiste volgorde?

Hoe doen we het dan?

Voor ons is het heel belangrijk dat onze app heel gebruiksvriendelijk wordt. De gebruiker moet niet hoeven na te denken en niet hoeven twijfelen of ze iets juist heeft ingevoerd. Dat doen wij ten eerste door zoveel mogelijk standaard knoppen, invoervelden en schermen te gebruiken; daar is iedereen namelijk al aan gewend. En waarom zouden wij nadenken over iets waar Apple en Google al over hebben nagedacht.

Daarna gaan we bedenken en naspelen hoe een gebruiker het zou gebruiken. We klimmen in de huid van een schoonheidsspecialiste of kapper en gaan onze eigen app “gebruiken”. Niet echt natuurlijk, want hij bestaat nog niet, maar virtueel. Dat leggen we makkelijker uit met een voorbeeld.

Voorbeeld: het uitgave-invoer-scherm

Wij zijn aan een tafel gaan zitten met een stapel kaartjes 4 typische uitgaven:

  1. Een particuliere bon (bijvoorbeeld van de supermarkt)
  2. Een factuur met btw (bv. van de spullen die jij gebruikt)
  3. Een factuur vrijgesteld van btw (bv. je bank, iZettle of Sumup)
  4. Een factuur met verlegde btw (bv. reclame op Facebook of Google)

Welke gegevens die daar opstaan zijn belangrijk? Welke moet je minimaal invullen om je boekhouder blij te maken?

  1. Leverancier (winkel)
  2. Datum
  3. Een nummer
  4. De btw bedragen
  5. Een totaalbedrag
  6. De betaalwijze

Schermen tekenen

Wat verwachten we zelf op ieder scherm te zien als we bijvoorbeeld een bon gaan invoeren? Wij kwamen uit op 4 schermen: leverancier, omschrijving en datum, bedragen en betaalwijze. Dit hebben we herhaald voor de 3 facturen, waarmee we dus uiteindelijk 4 invoer”flows” hadden. Nu konden we zien dat er 2 knelpunten waren:

  1. Bonnen hebben geen herkenbaar nummer (ons voorbeeld in ieder geval niet)
  2. Btw invoeren is lastig

Vooral die tweede maakt het een uitdagend stappenplan. Wij weten van te voren namelijk niet of een factuur btw heeft of niet. Wij weten dus van tevoren ook niet welke vragen we moeten stellen. En het tonen van dingen die niet nodig zijn maakt het onnodig verwarrend. Het was een hele puzzle, maar we denken dat we een elegante oplossing gevonden hebben.

schetsen van uitgave schermen op een poster

MVP

Om die oplossing te zien, moeten jullie nog even geduld hebben. We werken nu hard om het MVP (minimum viable product) af te krijgen. Deze versie kan nog niet alles wat we graag willen, maar hij is “af genoeg” om gebruikt te worden.

Er zijn nog heel veel puntjes op de i te zetten voor dit MVP, maar de back-end staat nu. Vrijwel alle functionaliteit zit erin, het is nu vooral een kwestie van alle schermen mooi maken en de juiste data tonen (de betaalwijze “CASH true” moet gewoon “Contant” zijn).

Na het MVP gaan we verder met de overige functionaliteit en beginnen we met de agenda! Ook zullen we de UI steeds blijven verbeteren. We hebben nu al een paar dingen waarvan we vinden dat het beter moet, maar eerst maar eens versie 1 afkrijgen.

Nog niet in MVP

  • Boekhouder export
  • Facturen maken
  • Foto van bon uploaden
  • Gegevens wijzigen
  • Instellingen
  • Korting
  • Labels

Leave a Reply