LCP LCP LCP

Gebruikersbehoeften omzetten in meetbare waarden

Gebruikersbehoeften omzetten in meetbare waarden
share-article-arrow-image

Er is een reden waarom kiezen voor Google Maps en niet Apple Maps als ze een iPhone hebben. Er is een reden waarom ze kiezen voor Spotify in plaats van Youtube Premium. En er is een reden waarom sommige producten überhaupt worden gebruikt. Daarom is het voor het succes van elk digitaal product van cruciaal belang om die "reden waarom" te bereiken. Die "waarom" is wat het product waardevol maakt voor gebruikers.

Om het "waarom" goed te krijgen in de onderzoeksfase van uw product moet u eerst de behoeften van uw gebruikers begrijpen en deze objectiveren in gebruikerswaarden. Value driven design geeft u handvatten om eisen en behoeften niet alleen te objectiveren, maar ook te kwantificeren. Deze kunnen dan gemakkelijk worden beoordeeld, zonder al te veel interpretatie. Hier is hoe.

Naar het "waarom"

De meeste producenten van digitale producten hebben een goed begrip van hun zakelijke en development stakeholders en weten wanneer iets goed genoeg is voor hen. Gebruikers zijn echter iets heel anders. Hoe weet je dan wanneer je product goed genoeg is voor je gebruikers?

Het is niet voldoende voor de succes van een product functies te objectiveren, d.w.z. de "wat". Een product kan alleen succesvol zijn als het voldoet aan de "waarom"; Waarom gebruiken mijn gebruikers mijn product? En waarom gebruiken ze mijn product en niet de producten van concurrenten?

Waarde

Waarde is een vreemd iets. Mensen denken vaak dat ze weten waarom een product waardevol is. Maar als je vraagt naar de reden, zijn de antwoorden van producenten, kopers en gebruikers meestal vaag. En dat is vreemd, want heel wat beslissingen zijn gebaseerd op de waarde die dat product heeft.

Producenten mikken misschien op "meer verkoop", maar wat voor soort verkoop wordt precies bedoeld?

Kopers streven wellicht naar meer efficiëntie voor hun werknemers. Maar hoe moet het product de efficiëntie precies verbeteren?

Gebruikers hebben soms geen keuze, omdat ze van hun werkgever het product moeten gebruiken. Gebruikers worden echter in toenemende mate betrokken bij het koopproces. En als een product er uiteindelijk niet in slaagt om zijn doel te vervullen, verliest het product zijn waarde. Hierdoor wordt het product niet langer gebruikt of er ontstaat veel frustratie tijdens het gebruik.

Objectieve gebruikerswaarden

Het probleem is dat gebruikers een eigen perceptie hebben van meetbare zaken. Dus als een product "snel moet laden", kun je "snel" concreet maken met een tijdsmeting, bijvoorbeeld in seconden. En dat is verstandig, want het is een sterke indicator. 2 seconden is echter langzaam voor de ene gebruiker en snel voor de andere. (Als 1 seconde niet haalbaar is, kun je natuurlijk effecten als skeleton screens gebruiken om het tijdsbesef van een gebruiker te manipuleren).

Objectieve gebruikerswaarden kunnen zeer nuttig zijn als instrumenten om design en ontwikkeling te sturen. Laadtijd is een goed voorbeeld, een ander voorbeeld is de objectieve nauwkeurigheid van zoekresultaten in een product.

Subjectieve gebruikerswaarden

De meeste gebruikerswaarden zijn subjectief, maar dat wil niet zeggen dat je ze niet kunt meten. De eerste stap is om de gebruikerswaarde zo duidelijk mogelijk te maken, bijvoorbeeld door hem uit te splitsen in meer concrete onderdelen.

Kijk voor een minder praktisch, maar wel inzichtelijk voorbeeld eens op Tom Gilb decompose Love.

Onderdelen kunnen objectief, maar ook subjectief zijn. De beste manier om subjectieve aspecten te kwantificeren is door te werken met "gebruikersbeoordelingen". De enige personen die je kunnen vertellen of voldaan wordt aan de subjectieve gebruikerswaarde zijn namelijk de gebruikers zelf.

header-image-blog-psd2-2-1

 

Voorbeeld

Voordat ik in het voorbeeld duik, wil ik duidelijk maken dat het hier gaat om een fictieve casus. De Nederlandse nationale politie is een klant van ons, maar ik was op geen enkele manier betrokken bij een project. Ook heb ik geen kennis van een dergelijk project, of als een project als deze überhaupt bestaat.

Hoe dan ook, als voorbeeld zal ik een fictieve mobiele app voor politieagenten gebruiken. Zij gebruiken deze app om misdaad te melden. Ik zal alle veiligheidskwesties overslaan door aan te nemen dat de app wordt gebruikt op een apparaat dat speciaal voor de politie is gemaakt en dat de veiligheid is gegarandeerd.

Deze app zal dus worden gebruikt door een politieagent wanneer een winkelier een diefstal meldt; hij wordt gebruikt wanneer een politieagent een verkeersovertreding meldt, enzovoort. De gebruiker is de politieagent, niet het slachtoffer van een misdrijf.

In de onderzoeksfase van dit project, komen jij en je team erachter dat een belangrijke gebruikersbehoefte voor deze app is dat het betrouwbaar moet zijn.

Betrouwbaar kan een zeer breed begrip zijn, dus laten we het opsplitsen in enkele waardevolle onderdelen:

  • Te allen tijde operationeel (objectief)
  • Nauwkeurige output (objectief)
  • Volledige output (objectief)
  • Output is veilig opgeslagen (objectief)
  • Gebruiksvriendelijk (subjectief)

In dit specifieke geval heeft "gebruiksvriendelijk" betrekking op het vertrouwen in het gebruik van de app. Je concurreert niet met een ander product, maar je wil gewoon niet met onzekerheden blijven zitten na het indienen van de melding. "Heb ik dit wel goed gedaan?" Je wil "insturen en kunnen vergeten".

De onderdelen die betrekking hebben op de output kunnen gemakkelijk worden geobjectiveerd en gekwantificeerd als je kijkt naar waarom ze in de eerste plaats nodig zijn: de rapporten worden gebruikt in het vervolgproces. Als de rapporten niet nauwkeurig of volledig zijn, zal degene die betrokken is bij het vervolgproces contact op moeten nemen met de agent om te vragen om aanvullende informatie.

Mogelijke gebruikerswaarde

Gebruikerswaarde: Maandelijkse verzoeken om aanvullende informatie
IST: 10
SOLL: 2

Natuurlijk keek je in het design al naar de informatie die de volgende persoon in het proces nodig heeft. Maar deze waarde kan je er misschien toe aanzetten om grondiger te kijken naar wat zulke verzoeken in het verleden veroorzaakten. En natuurlijk biedt het iedereen in het project een beeld van waarnaar gestreefd moeten worden.

Laten we eens kijken naar de subjectieve gebruikerswaarde "Gebruiksvriendelijk". Dit zal in elke context anders zijn en in dit voorbeeld hebben we een duidelijke "waarom" die we kunnen controleren met gebruikersbeoordelingen.

"Hoe zeker ben je er van dat je de rapporten juist invult?"

Functie vs. gebruiksgemak

Ik begon dit blog met Google Maps vs. Apple Maps en Spotify vs. YouTube Premium. En toen gebruikte ik een voorbeeld wat gericht was op functies. Uiteraard kunnen consumentenproducten ook heel functioneel zijn, maar gebruikers kunnen ook plezier halen uit het gebruik en er bestaat ook een esthetische factor.

Dit zijn echter zeer subjectieve waarden waarvoor je gebruikersbeoordelingen nodig hebt.

En als volgende

Ik hoop dat ik je een aantal voordelen heb kunnen laten zien van het omzetten van gebruikersbehoeften in kwantificeerbare gebruikerswaarden. Was het nuttig? Kijk maar eens naar een gebruikersbehoefte die je in je project hebt geïdentificeerd. Kun je die objectiveren en kwantificeren? Kan dat helpen bij het vinden van ontwerpoplossingen? En bij de gesprekken met je stakeholders?

Als het bekijken van design vanuit het perspectief van waarde je aanspreekt, kun je altijd Een introductie voor Value Driven Design bekijken.

Headshot of Julie Pontier Sales New Business
Ben je geïnteresseerd in onze expertise?

Laten we samen een oplossing vinden!

Julie Pontier

Sales