Building Block: Interactie Ontwerpen
2021-11-23
Herkansing: 2022-06-15
Lucas van der Vegt
Een interactieontwerp wordt gebruikt om de beoogde interactie tussen de gebruiker en een systeem weer te geven. De basis van een interactieontwerp bestaat uit user stories, een sitemap, wireframes en een styleguide. Het interactieontwerp dient als input voor de developer, zodat functionaliteiten, navigatie, lay-out, interactie en vormgeving voor hem/haar inzichtelijk worden gemaakt voor doorontwikkeling.
Link naar blogpost: lucasvdvegt/portfolio/buildingblocks/bb-interactie
Index
Algemene Inleiding
Voor deze opdracht heb ik de casus van CLE2 uit voorig jaar genomen. Het maken van een digitaal online reservatie systeem. Hiervan heb ik de resultaten uit de ontwerpsprint genomen en een paar dingen aan verbeterd zodat deze voldoen aan de eisen van dit buildingblock.
**FEEDBACK ASSESSMENT NIEK**
Voldoende:
User Stories
Style Guide
Te herkansen:
Sitemap
Wireframes
- Probeer beter in te leiden wat je laat zien en de relevantie tot het bewijs wat van je gevraagd word. Inspiratie, huidige staat etc neem je bijvoorbeeld mee in een styleguide, je huidige format zorgt voor onduidelijkheid en verwarring.
- Je userstories zijn niet erg goed inzichtelijk gemaakt, maar kloppen in grote lijnen.
- Omdat je cardsorting niet duidelijk word uitegelegt word het hele stuk over low en high-fidelity sitemapping onleesbaar (overdaad aan redundante informatie).
- Het is onduidelijke wat wireframes zijn en waar je onderzoek ophoud, ook hier geld: laat zien wat van je gevraagd word. Er is wederom een overdaad aan informatie waardoor het onleesbaar word.
- Let beter op de manier van presenteren, is dit de optimale manier om informatie weer te geven?
- Anotaties moeten over interacties gaan, dat is nu nog onduidelijke.
- Styleguide zou op 1 pagina (of hooguit 2) moeten passen. Ook hier is er een overdaad aan informatie die je tegenwerkt.
**Samengevat:**
Algemeen:
Beter inleiden
Relevantie tot bewijs
Huidige format verbeteren
Sitemap:
Betere uitleg cardsort
High & Low fidelity sitemap verbeteren (minder redundante info)
Wireframe:
Onduidelijk wat wireframes zijn
Waar houd het onderzoek op
Laat enkel zien wat er gevraagd word (minder redundante info)
Betere manier van presenteren
Annotaties moeten over interactie gaan
Styleguide:
Styleguide op 1 pagina
**Todo:**
Algemeen:
- [x] beter inleiden
- [x] relevantie tot bewijs groter maken
- [x] meer context geven
- [o] presentatie > geen breindump
- [x] meer gefocusste info
- [x] informatiedichtheid vergroten
Userstories:
- [x] algemene feedback toepassen
Sitemap:
- [x] algemene feedback toepassen
- [x] meer context
- [x] betere uitleg cardsort
- [x] focus op eindresultaat
Wireframe:
- [x] algemene feedback toepassen
- [x] meer context
- [x] focus op eindresultaat
- [x] annotaties > vanuit perspectief van ontwerper naar programmeur
Styleguide:
- [x] algemene feedback toepassen
- [x] alle plaatjes in een collage zetten
- [x] focus op eindresultaat
- [x] styleguide op een gedeelte
Inleveren:
- [o] maak er een onepager van
- [ ] check requirements
- [ ] last check opmaak
- [ ] inleveren
1. User Stories
Op basis van het gesprek met je opdrachtgever stel je minimaal 5 user stories (inclusief acceptatie criteria en definition of done) op. De stories zijn geformuleerd volgens het format [als …, wil ik …, zodat …]. Je checkt de stories aan de hand van de INVEST checklist en prioriteert deze middels MoSCoW.
Dit zijn de userstories die ik heb weten te verkrijgen vanuit de vele gesprekken met opdrachtgever en gebruikers (zie andere buildingblocks). Dit is gelijk al ingedeeld in de MOSCOW methode om aan te geven waar de meeste focus op licht, zo zijn bepaalde stakeholders bijv meer of minder belangrijk en staan deze hoger of lager op de prioriteitenlijst. Elke userstory heeft een acceptatiecreteria zodat je later kan checken of het product zich voldoet aan de verwachting van de opdrachtgever en gebruikers.
Must Haves (MVP)
Als repetitie organisatie
wil ik kunnen zien of iemand zich aangemeld heeft
zodat het duidelijk is of die persoon aanwezig is
Acceptatiecriteria:
- [ ] koorleden moeten zich kunnen inschrijven
- [ ] pagina / card in agenda item om in te schrijven
- [ ] overzicht inschrijvingen
Als koorlid
wil ik in zo weinig mogelijk clicks kunnen inschrijven
zodat de drempel voor het inschrijven zo laag mogelijk is
Acceptatiecriteria:
- [ ] inschrijven in zo weinig mogelijk clicks
Als koorlid
wil ik alle komende repetities en optredens kunnen zien
zodat ik mijn eigen planning daarop kan aanpassen.
Acceptatiecriteria:
- [ ] overzicht van agendaitems
- [ ] pagination van agendaview
Als bestuur
& commissies
wil ik persoonlijke gegevens van mensen kunnen bekijken en aanpassen
zodat de administratie via de normale omgeving gedaan kan worden
Acceptatiecriteria:
- [ ] overzicht van users & gegevens
- [ ] aanpassingen in overzicht
Should Haves
Als koorlid
wil ik een notificatie wanneer de inschrijvingen voor de repetitie open gaan
zodat ik de inschrijving niet mis.
Acceptatiecriteria:
- [ ] notificatie systeem
- [ ] notificatie bij opening van inschrijving
- [ ] link naar betreffende inschrijving
Als koorlid
wil ik dat mijn gegevens goed aantoonbaar beveiligd zijn
zodat ik weet dat de app te vertrouwen is.
Acceptatiecriteria:
- [ ] duidelijke visuele queue van beveiliging bij alle belangrijke plekken
Could Haves
Als riser groep
wil ik weten bij welke repetitie ik risers moet opzetten
zodat ik mijn riserdienst goed kan uitvoeren.
Acceptatiecriteria:
- [ ] indicatie van welke groep er aan de beurt is in de agendaitems
- [ ] indicatie wanneer de desbetreffende persoon aan de beurt is in het overzicht
- [ ] mod moet risergroepen kunnen aanpassen
- [ ] mod moet risergroepen aan agendaitem toe kunnen kennen
Would Haves
Als songcoach
wil ik aangeven wanneer ik niet aanwezig ben
zodat de vervanging op de hoogte is.
Acceptatiecriteria:
- [ ] songcoach moet aanwezigheid kunnen aangeven
- [ ] indicatie in agendaitem wie de songcoach voor dat moment is
- [ ] vervanging moet notificatie krijgen wanneer relevant
Definition of Done
De DofD is een herhaaldelijke checklist die je bij elke userstory langsgaat om zeker te weten dat een feauture goed word geimplementeerd.
- Geen errors.
- Getest & voldoet aan acceptatie criteria.
- Veilige implementatie.
- Gepusht naar git.
- Besproken met directe team.
- Gedocumenteerd. (Waar nodig)
2. Sitemap
Je schetst een low-fidelity sitemap. Je stelt een card sorting test op en voert deze uit. Je verwerkt de inzichten in een digitaal opgestelde high-fidelity sitemap, hierbij let je op de notatie (uitlijning, nummering, pijlen, etc.) om zodoende de leesbaarheid te vergroten.
2.1 Low Fidelity Sitemap
Dit is de low fidelity sitemap, hier heb ik vanuit mijn eigen ideeën en visie een interactieflow gemaakt van de applicatie. Met deze lofi versie kan ik usertests gaan uitvoeren om het vervolgens naar een verbeterde hifi versie te maken. Tussendoor kunnen er ook meerdere low fi iteraties zijn, waarop je nog meer usertests doet.
2.2 Cardsorting Test
De cardsorting test gebruik je om te kijken of de gebruiker de beoogde interactie flow begrijpt en of dit intuïtief is. Het gross van jouw doelgroep moet zonder al te veel na te denken een verwachting kunnen hebben van wat waar staat in de navigatie. Dit kan per doelgroep een beetje anders zijn aan de hand van gebruikerspatronen bij hun dagelijks gebruik. Mijn doelgroep zijn volwassen mensen die vooral werken op kantoor baantjes of veel met hun computer moeten werken. Dus deze mensen zijn gewend om professionele planning tools te gebruiken.
Vanuit de testuitkomsten trek ik conclusies en vanuit daar pas ik de sitemap aan.
2.2.1 Cardsorting Test Instructions
Hallo! Welkom bij de cardsorting test voor mijn schoolopdracht. (Building Block Interactie Ontwerpen)
De casus is een calender app met informatie over en interactie met de events.
Het is een korte test en zal niet veel tijd kosten.
Hier is hoe het werkt:
Links zie je een lijst van items. Deze items moeten gesorteerd worden in groepen die logisch zijn voor jou.
Gebruik de groupen die er al staan of maak je eigen. Drag en drop de items van links naar een groep.
Er zijn geen juiste of verkeerde antwoorden. Doe wat je zelf het meest logisch lijkt. Wanneer je klaar bent klik je op "Finished" rechtbovenin.
Alvast Bedankt! :)
2.2.2 Cardsorting Test Uitkomst
Deze cardsorting test is uitgevoerd op een kleine groep, dus de gegevens zijn niet statistisch significant. Maar het is wel een indicatie van een aantal algemene dingen.
De login categorie word veel gebruik voor dingen waar je eigenlijk ingelogd voor moet zijn, dit is best wel vreemd. Mijn theorie is dat mensen zonder de context van de navigatie niet doorhebben wat een inlogpagina inhoud (ook omdat je vaak maar een paar keer de login pagina ziet bij gebruik). Volgende keer zou ik de login pagina weglaten uit de cardsorting test.
De settings categorie word gebruikt voor wanneer mensen dingen niet kunnen vinden, een soort overige sectie. Dus wanneer je iets toevoegt wat niet ergens thuishoort kan je dit het best in de settings doen (met een search zodat de grote hoeveelheid content gefilterd kan worden). Ook staat het moderator panel in deze test niet als losse categorie, daardoor wekt het de illusie dat je apart moet inloggen om bij de mod sectie te kunnen komen. Toch is de locatie van het modpanel goed gekozen omdat mensen voor overige dingen bij de settings gaan kijken.
De inbox categorie word niet goed begrepen, dit kan ik oplossen door visuele elementen zoals een icoontje en een notificatie indicatie.
Het concept van broadcasts word vanuit de cardsorting test niet helemaal begrepen. Het word bij de events geplaatst. Met de visuele context erbij zal wel duidelijk worden waar dit thuishoort. De broadcast geeft een notificatie naar je device of email en linkt vanaf hier naar het bericht, zo word je van buitenaf gestuurd ernaar.
Het aanmelden voor een agendaitem word verward met aanmelden voor de app. Dit komt omdat er verschillende talen door elkaar worden gebruikt en omdat je de context mist. (Inloggen, Aanmelden, Signup, Inschrijven) Belangrijk is het om consistent taalgebruik te gebruiken en icoontjes toe te passen voor context.
Er zijn ook genoeg onderdelen die de goede richting op gaan, zoals de agenda items en het aanmaken ervan. Dit is de belangrijkste feature dus dat is positief. Ook staan de notificaties goed en de meeste instellingen.
De algemene conclusie is: let op met consistent taal gebruik en de overlap / betekenis van bepaalde worden. Om verwarring te voorkomen moet je bij alle belangrijke onderdelen tekst met een icoontjes plaatsen. Dit maakt het intuïtiever en zorgt ervoor dat de muscle memory de onderdelen gaat herkennen.
2.3 High Fidelity Sitemap
Op basis van de de getrokken conclusies heb ik de sitemap geupdate en is het met mooie visuals gemaakt.
De high fidelity sitemap heeft vooral een flow van boven naar beneden. Maar dit kan ook andersom, daarom heb ik gekozen om geen pijlen met richtingen toe te voegen.
Wanneer je ingelogd ben kom je op de eerste reguliere pagina terecht. (2.) Tussen de hoofdpaginas kan je switchen tussen de tabjes door gebruik te maken van de navbar onderaan (vanaf bijna elk scherm is dit zichtbaar).
3. Wireframes
Op basis van de user stories, schets je low-fidelity wireframes voor minimaal 2 schermen. Je gebruikt aanbevelingen om de low-fidelity wireframes iteratief te detailleren en verbeteren in de vorm van minimaal 2 digitaal opgestelde high-fidelity wireframes. De high-fidelity wireframes bevatten annotaties die de beoogde interactie beschrijven.
Dit zijn 3 wireframes van de belangrijkste interactie binnen het concept. Het bekijken van agenda items en het aangeven van presentie.
Hierbij worden annotaties gegeven met informatie over de soort interactie die verschillende onderdelen hebben. Ook word de flow aangegeven door middel van pijlen. Elke wireframe is opgedeeld in verschillende components en die worden aangegeven met de labels aan de linkerkant.
Deze versie van de wireframes komen voort uit low fidelity wireframes, die weer uit sitemap (met user research) voortkomen.
![](images/bb-interactie/hifiwireframes_annotaties_choirapp_v3.png)
4. Style Guide
Je bepaalt (in overleg met je opdrachtgever) welke uitstraling, content en tone-of-voice het ontwerp moet krijgen. Je stelt een style guide op, de style guide bevat voldoende informatie (fonts, kleuren, on-hover states, afbeeldingen, etc.) om als basis te dienen voor de CSS van je product. Je zorgt dat de style guide er verzorgd en consistent uitziet.
De Styleguide bestaat uit 2 onderdelen, research / moodboards en de uiteindelijke styleguide. Dit is om later aan de ontwerpers en programmeurs te laten zien met welke gedachte de onderdelen zijn bedacht.
4.1 Branding
Het eerste gedeelte dient om te laten zien vanuit welke visie en ideeën de styleguide is gemaakt. Hier worden in 3 hoofdonderdelen de look & feel in duidelijk gemaakt. Ook heeft elk onderdeel acceptatiecriteria die later bij het maken van wireframes, frontend & content nodig zijn.
4.1.1 Uitstraling
De app moet er simplistisch uitzien, dit houd in dat er geen onnodig ingewikkelde of drukke schermen mogen zijn. Elk scherm moet een bepaald specifiekhebben doel hebben of een verzameling van mogelijkheden die ergens anders naar leiden. Het is balangrijk dat per pagina duidelijk is wat de belangrijkste functies zijn, deze onderdelen moeten een prominente positie en of kleurgebruik hebben. Ook moeten acties die aandacht nodig hebben duidelijk de aandacht trekken, dit zorgt voor een betere workflow binnen het koor. Maar de koorleden moeten niet de heletijd gespammed worden met notificaties omdat ze in hun vrije tijd bezig zijn met reflax. Als er schermen nodig zijn met veel informatie moet dit niet in het begin getoont worden en zal dit altijd een van de laatste paginas zijn in een flow.
Acceptcriteria: Simplistisch, Snel, Duidelijk.
De app moet een gezellige en persoonlijke uitraling hebben, dit houd in dat je moet kunnen zien wie de mensen zijn waar je mee werk. Het gezicht moet gekoppeld worden aan de berichten en acties. Zo moet je bijvoorbeeld de mogelijkheid kunnen hebben om vanuit een bepaalde commissie berichten te plaatsen of vanuit persoonlijke titel (of beide). Ook moet het kleurenpallet niet afschrikwekkend zijn en rust geven. Je moet gemotiveerd worden om dingen te doen op de app, het moet je prikkelen en uitnodigen om acties uit te voeren of informatie te bekijken. Bijvoorbeeld in de vorm van een vriendelijke notificatie (Met de naam van wie of welke commissie het bericht komt)
Acceptcreteria: Persoonlijk, Gezellig, Uitnodigend
De app moet er huiselijk uit zien, dit houd in dat het een rustige colorpallete nodig heeft wat je doet denken aan het theater of muziek. De app moet herkenbare punten en benamingen hebben, neem hierbij inspiratie van features uit de bestaande apps die vanuit de doelgroep veel gebruikt worden (uit doelgroep onderzoek). Ook moeten er visuele onderdelen die in de theater em muziek industrie voorkomen, in de app terugkomen. Dit zorg voor een herkenbaar en vertrouwde look.
Acceptcriteria: Huiselijk/Theater, Herkenbaar, Vertrouwd
![](images/bb-interactie/reflax_logo1.png)
![](images/bb-interactie/reflax_logo2.jpg)
Reflax heeft een Keycolor: oranje (#f87b34), deze kleur zal terug moeten komen in een opvallende vorm. Dit is een herkenningspunt voor koorleden en maakt het consistent met het bestaande forum. Daarnaast gebruiken ze neutrale witte en zwarte kleuren (#040404, #fcfcfc). Ook hebben ze ooit een kerstlogo gehad met rood (#). Qua kleurpallet mag er gespeeld met donker/licht en het toevoegen van secundaire kleur(en). Het is handig als er een darkmode in de app zit aangezien het ook in het theater gebruikt word en omdat mensen vaak na hun werk in de avond er gebruik van maken.
Acceptcriteria: gebruik van keycolor(#f87b34) & neutrale witte en zwarte kleuren (#040404, #fcfcfc)
Websites nu
![](images/bb-interactie/reflax_site1.png)
![](images/bb-interactie/reflax_site2.png)
Algemene Inspiratie
![](images/bb-interactie/inspiration_branding_uitstraling_algemeen.png)
Kleurpallet Inspiratie
![](images/bb-interactie/inspiration_branding_uitstraling_kleurpallet.png)
4.1.2 Content
Ze willen graag een app en desktop variant. Re-flax wil met de aanmeldingsapp ervoor zorgen dat het alsnog makkelijk en leuk is om naar de repetitie te komen in deze tijden. Normaalgesproken zou de boodschap meer een simpele aanwezigheidsfunctie zijn.
De app moet op mobiel, desktop en tablet gebruikt kunnen worden. Deze doelgroep heeft voor sommige mensen een niet of slecht werkende telefoon, wel vinden een hele boel mensen het gemakkelijker tussendoor te gebruiken op mobiel. Bepaalde features hebben meer voordelen om op bepaalde devices te worden gebruikt. De verschillende versies moeten daadwerkelijk in de kwaliteiten uitblinken, denk bijvoorbeeld aan: het makkelijk kunnen managen van calender item door dingen side-by-side te kunnen plaatsen op desktop en het offline beluisteren van muziek of lezen van informatie op mobiel.
Acceptcriteria: Er is een mobiele, desktop en tablet versie. Verschillende features per device.
Het aanmelden voor een repetitie of optreden moet satisfying worden, er moet drive zijn waarom je graag de actie wilt voldoen. Bijvoorbeeld door middel van instant gratification toe te passen en van te voren een leeg vakje te maken die er duidelijk leeg uit ziet en je graag wilt invullen. Ook moet dit in zo weinig mogelijk kliks gedaan kunnen worden, zodat de gebruiker niet afdwaalt.
Acceptcriteria: Het aanmelden moet satisfying zijn, Er word een vorm van gamification toegepast, Maximaal 4 kliks om je aan te kunnen melden.
Qua informatie moet je duidelijk alle relevante details zien voor een relevante aantal tijd. Dus je moet bijv voor de komende maand zien wie de riserdiensten hebben en voor de komende 6 maanden wanneer er optredens zijn.
Acceptcriteria: Consumeerbaar aantal informatie per pagina, Scanbare Informatie.
Content Momenteel
![](images/bb-interactie/current_branding_content2_collage.png)
Content Toekomst / Inspiratie
![](images/bb-interactie/inspiration_branding_content_collage.png)
Spotify, Youtube Music, Apple Music/ Itunes, Google Calendar, Microsoft Teams
4.1.3 Tone-of-Voice
Er moet een duidelijke toon zijn met een consistent gebruik van werkwoorden / bijvoeglijk naamwoorden om aan te duiden wat er gedaan moet worden gedaan of waar je naar moet zoeken. Ook moet het op een vriendelijk niet al te serieuze manier overkomen, daarom word er met je/jij/jouw aangesproken. Zo af en toe moet er een beetje humor in zitten om het lezen en gebruik een stuk leuker te maken. Er moet duidelijke informatie gegeven worden met een knipoog ;).
Acceptcriteria: duidelijk, consistent, vriendelijk, je/jij/jouw, met een knipoog (humor)
Om er voor te zorgen dat het een ervaring word alsof je thuis bent moeten de bepaalde benamingen/termen binnen de theater en muziek industrie terug komen in de app. Ook moeten bepaalde termen die binnen reflax gebruikt worden erin terug te komen. Denk aan een "de hatseflats" (kooropstelling) of "de mikmak" (bepaalde koffer met kabels).
Acceptcriteria: Gebruik muziek/theater termen. Gebruik reflax termen.
Daarnaast moet alle tekst scanbaar zijn en moeten alle belangrijke onderdelen ook in de schrijfstyle duidelijk naar voren komen. Dit kan je bereiken door belangrijke informatie vooraan de zin of tekst te zetten en het gebruik maken van bold of italic tekst.
Acceptcriteria: Scanbaar in schrijfstyle, Scanbaar in opmaak.
Tone-of-voice Momenteel
![](images/bb-interactie/current_branding_tone_collage.png)
Tone-of-voice Toekomst / Inspiratie
![](images/bb-interactie/inspiration_branding_tone_collage.png)
Discord, Reddit
4.2 Styleguide
In de styleguide word vooral de kleur en vorm van de app in duidelijk gemaakt. Met daarmee het font & kleur als belangrijkste onderdelen. Deze styleguide moet gebruikt worden bij het programmeren van de CSS en moet ook geupdate worden zodra er dingen veranderen aan de style. In dit geval is het een darkmode app met een oranje accent.