Een van de grootste fouten die productteams maken, is verwarrende ontwerpen die er geweldig uitzien maar die niet goed werken. Het is een simpele fout, maar het kan ernstige consequenties hebben: als uw product niet goed werkt, maakt niemand er tenslotte nog om hoe het eruit ziet.

De beste manier om deze verwarring te omzeilen, is een techniek die verhaal gecentreerd ontwerp wordt genoemd. Het idee is om een ​​reeks verhalende use-cases voor uw product te maken die elke stap in de reis van de gebruiker doorheen illustreren. Ik heb deze techniek met tientallen startups gebruikt en het helpt altijd teams voorbij de visuele details van het oppervlak te gaan om betere beslissingen te nemen over wat er echt toe doet: hoe hun product eindelijk werkt. 

Ontwerpen zouden geen blauwdrukken moeten zijn

Ik heb opgemerkt dat teams vaak graag door UI-ontwerpen lopen zoals ze een blauwdruk zouden hebben – ze laten zien waar elk element bij hoort. Elk scherm laat zien hoe het product er in een andere situatie uit zou kunnen zien, maar de schermen zijn op geen enkele manier verbonden. Het probleem is dat wanneer ontwerpen op deze manier worden gepresenteerd, je alleen een beter begrip opbouwt van hoe het product eruitziet. U concentreert zich niet op hoe het product werkt, en u simuleert niet hoe klanten ermee omgaan. Dus wanneer teams ontwerpen kritiseren als blauwdrukken, beperkt dit hun vermogen om te redeneren door de interactiviteit van het product ernstig.

De beste productontwerpers oefenen een op verhalen gericht ontwerp. Ze beginnen met het maken van verhalen die laten zien hoe klanten omgaan met een product, en pas nadat ze dat hebben gedaan ontwerpen ze schermen als een manier om dat interactieverhaal te vertellen. 

Het proces van ontwerpen op verhaal

In story-centered design werken teams kritisch door te kijken naar tientallen sequentiële mockups die functioneren als frames in een filmstrip (zie de foto hieronder). Ontwerpers presenteren elke zin die de klant leest, elke actie die ze ondernemen en elk scherm dat door het systeem wordt gegenereerd als reactie. De ontwerpen volgen een klant vanaf een eerste trigger tot en met het voltooien van een doel en ze laten zien hoe het ontwerp elke stap in die stroom ondersteunt. Ik heb veel startups gecoached door middel van op het verhaal gerichte ontwerpoefeningen en deze technieken werkten voor mobiele apps, marketingwebsites, analytische dashboards, enterprise IT en nog veel meer.

Voor ingenieurs zou dit bekend moeten klinken. De kern van verhaalgecentreerd ontwerp is hetzelfde als proefgestuurde ontwikkeling. Alleen in plaats van tests te schrijven om onze code uit te oefenen, creëren we verhalen om onze ontwerpen uit te oefenen. Net als door tests aangestuurde ontwikkeling, kan een op een verhaal gericht ontwerp een ongelooflijke invloed hebben op de snelheid en kwaliteit van een product. 

Waarom story-centered design zo goed werkt

Het simuleert de gebruikerservaring Het op verhalen gerichte ontwerp dwingt ons om samen met klanten door elke stap te rijden. Dat geeft het hele team (ontwerpers, ingenieurs, CEO) een systeem om ontwerpbeslissingen te nemen op basis van hoe mensen het product daadwerkelijk zullen ervaren.

Teams spot problemen eerder Omdat verhalen een tijdsdimensie toevoegen, markeren ze allerlei ontwerpfouten die teams vaak missen bij het bekijken van hun product als slechts een stel schermen. Verhalen maken het gemakkelijker om op te merken wanneer prompts niet de juiste verwachtingen bepalen. UI-flows met onnodige stappen en dead-ends worden sneller opgemerkt en gerepareerd. Al deze kleine details zorgen voor een betere bruikbaarheid en betrokkenheid van de gebruiker.

Het verduidelijkt ontwerpdoelen vooraf Wanneer teams beginnen met het ontwerpen van verhalen, dwingt dit iedereen tot overeenstemming over de ontwerpdoelen voordat de details worden uitgewerkt. Dat is handig, want nadat ontwerpers uren hebben besteed aan gedetailleerde UI-mockups, zal de kritiek eng worden gericht op de vraag of de ontwerpen vooraf gedefinieerde en begrepen doelen bereiken.

Het is wetenschap! Ja soort van. Doordenken hoe een klant van initiële trigger gaat (zoals een e-mail of push-melding) helemaal tot en met het afronden van een doelkaart, redelijk goed naar BJ Fogg’s Gedragsmodel van Triggers, Motivaties en Bekwaamheid. Verhalen maken het gemakkelijker om te controleren of al deze elementen aanwezig zijn om het gedrag van gebruikers te stimuleren.

Het versnelt al het andere. Verhalen kunnen vaak worden hergebruikt door andere delen van het team. Mockups die zijn gemaakt voor het weergeven van een verhaal, kunnen worden omgevormd tot een snel klikbaar prototype voor gebruikersstudies. Hetzelfde verhaal kan worden gebruikt om een ​​trechteranalyse te maken, waarmee we kunnen achterhalen of gebruikers het verhaal in het live-product doormaken. En het QA-team kan belangrijke verhalen doornemen om elke nieuwe release te valideren.

Share This