Wat is een use case? Hoe schrijf je er een, voorbeelden en sjabloon

Voor het ontwerpen van een product is meer nodig dan een opsomming van functies en doelen alleen. Hoe zou je, voordat de eerste smartphone uitkwam, de manieren beschrijven waarop gebruikers ermee omgingen? Het een mobiele telefoon waarmee je op het internet kunt surfen noemen is een goed begin, maar daarmee doe je geen recht aan de complexiteit van de betreffende systemen. Om in kaart te brengen hoe gebruikers met een systeem, tool of product omgaan, heb je een use case nodig.

Use cases zijn beschrijvingen van hoe gebruikers met systemen interacteren om taken uit te voeren of doelen te bereiken. Het in kaart brengen van deze interacties kan de vroege planning verbeteren en zorgen voor een soepele ontwikkelingscyclus. Om je te helpen ze in de projectplanning te verwerken, zullen we een use case definiëren, uitleggen hoe je er een schrijft en voorbeelden delen.

Wat is een use case?

Een use case legt uit hoe gebruikers met een product of systeem omgaan. Het geeft de stroom van gebruikersinputs weer, waarbij succesvolle en mislukte paden naar het behalen van doelen worden vastgesteld. Hierdoor kunnen productteams beter begrijpen wat een systeem doet, hoe het presteert en waarom er fouten optreden. Je kunt er een uitschrijven of een use case-model schetsen voor visuele denkers.

Use cases variëren in complexiteit, afhankelijk van je publiek of systeem. Maar over het algemeen moet je use case enkele belangrijke component identificeren. De belangrijkste zijn:

• Actor: alles dat gedrag vertoont dat interactie heeft met een systeem, zoals een enkele gebruiker, een team of een ander softwareprogramma
• Systeem: het product of de dienst met gedefinieerde functionaliteit
• Doel: het doel of de doelstelling die gebruikers bereiken met de functies van een systeem

Actoren, systemen en doelen vormen de basis voor een use case. Wanneer je systeeminteracties gaat bijhouden, komen er enkele nieuwe elementen bij kijken:

• Belanghebbende(n): iemand met een belang of interesse in de prestaties van een systeem
• Primaire actor: de actor die een systeemfunctie initieert om een doel te bereiken
• Randvoorwaarden: onderliggende factoren die nodig zijn om de use case te laten plaatsvinden
• Triggers: gebeurtenissen die een use case activeren
• Basisstromen: use cases waarbij systemen werken zoals bedoeld om een doel te bereiken
• Alternatieve stromen: verschillende uitkomsten afhankelijk van wanneer en hoe een systeem van koers afwijkt

Soorten use cases

Use cases zijn er in twee vormen: zakelijk en systeem. Een systeem-use case is een gedetailleerd overzicht van hoe gebruikers met elk onderdeel van een systeem omgaan. Het benadrukt hoe unieke inputs en contexten ervoor zorgen dat het systeem verschillende uitkomsten geeft. Dit detailniveau benadrukt hoe de individuele functies van een systeem in elk scenario werken.

Zakelijke use cases schetsen een algemener beeld van hoe een gebruiker met je bedrijf kan communiceren om zijn of haar doelen te bereiken. In plaats van te focussen op technische details, is het een oorzaak-en-gevolgbeschrijving van verschillende inputs. Als je bijvoorbeeld een code debugging-platform hebt, legt je zakelijk gebruiksscenario uit hoe gebruikers hun code invoeren en foutmeldingen ontvangen.

Sommige teams schrijven graag een zakelijke use case om de processen van een systeem te schetsen voordat de ontwikkeling begint. Als de ontwikkelaars beginnen met hun werk, zal een manager technischere systeem-use cases schetsen die gevolgd moeten worden.

Gebruiksscenario versus use case

Use cases tonen alle manieren waarop een systeem functioneert bij het bereiken van doelen, maar een scenario beeldt slechts één voorbeeld uit. In een scenario kan het systeem slagen of falen in het bereiken van de doelen van de gebruiker. Eenvoudig gezegd, meerdere gebruiksscenario's vormen een use case.

Use case versus gebruikersverhaal

Use cases tonen hoe gebruikers met een systeem omgaan, en gebruikersverhalen beschrijven functies vanuit het perspectief van de gebruiker. Als gevolg hiervan zijn gebruikersverhalen veel korter dan use cases, en bestaan ze meestal uit korte beschrijvingen die teams gebruiken als startpunt in de ontwikkeling. Bovendien kunnen use cases meerdere teams binnen een organisatie helpen, terwijl gebruikersverhalen productteams helpen bij het bouwen van hun tool.

Use case versus testcase

Een use case beschrijft hoe gebruikers en systeemfuncties werken om doelen te bereiken; testcases verifiëren of een bepaalde functie correct werkt. In tegenstelling tot use cases wordt in testcases de functionaliteit afzonderlijk bekeken.

Een testcase kan bijvoorbeeld betrekking hebben op het valideren van de inlogfunctionaliteit op een e-mailplatform, om ervoor te zorgen dat gebruikers op elk moment na het aanmaken van hun account met elke browser kunnen inloggen.

Hoe schrijf je een use case?

Het schrijven van een use case klinkt ingewikkeld, maar vereist alleen inzicht in je systeem en de gebruikers ervan. Je kunt een use case schrijven door deze zes stappen te volgen:

1. Beschrijf je systeem

Begin met het beschrijven van je systeem, of het product of de dienst die jij en je team gaan bouwen. Concentreer je beschrijving op wat je systeem doet voor gebruikers. In een zakelijke use case kun je deze achtergrond algemeen houden en uitleggen wat je ermee bereikt. Geef voor een systeem-use case een beschrijving van hoe je product onder de motorkap functioneert.

Definieer je systeem door te vragen:

• Welke vorm neemt het aan: product, dienst of software?
• Welke functies biedt het aan?
• Welke doelen kun je ermee bereiken?
• Hoe worden die doelen bereikt?
• Wat kun je leren over het systeem uit andere documenten zoals projecthandvesten?

2. Identificeer de actoren

Actoren verwijzen over het algemeen naar gebruikers en klanten, maar kunnen van toepassing zijn op elke externe kracht die met je systeem interacteert. Je actor heeft goed gedefinieerde gedragingen nodig die uitleggen hoe en waarom actoren je systeem gebruiken.

Identificeer actoren door te vragen:

• Zijn het individuen, teams, hardware of een ander systeem?
• Zullen primaire en secundaire actoren hetzelfde gedrag delen?
• Zullen belanghebbenden in jouw use case de rol van actoren op zich nemen?

3. Definieer de doelen van je actoren

Use cases benadrukken de uitkomst die actoren van een systeem willen. Vergeet niet de wensen van je gebruikers centraal te stellen in plaats van de mogelijkheden van het systeem, zodat je begrijpt waarom ze jouw systeem gebruiken. In sommige gevallen willen klanten systemen voor meer dan één doel gebruiken. Door elk van deze doelen te vermelden, ontstaat een robuustere use case.

4. Maak een scenario

In een use case zijn scenario’s de opeenvolging van acties die klanten ondernemen wanneer ze een systeem gebruiken en de stroom van effecten van die interactie. Je basisstromen dekken scenario's waarin een systeem werkt zoals bedoeld. Een gebruiker benadert het systeem, voert de juiste gegevens in en je systeem helpt ze hun doelen te bereiken.

Begin met deze succesvolle basisstromen om een baseline te maken. Je kunt technieken voor het in kaart brengen van processen gebruiken om mogelijke problemen in de volgende stromen te identificeren.

5. Overweeg alternatieve stromen

Na het schrijven van een succesvol scenario, schrijf je alternatieve stromen uit die tot andere uitkomsten leiden. Meestal omvatten alternatieve stromen verkeerd bruik van een systeem waardoor actoren hun doelen niet kunnen bereiken. Je kunt echter ook interne fouten opmerken die ervoor zorgen dat een systeem niet werkt of onbedoelde manieren waarop systemen doelen kunnen bereiken.

Alternatieve stromen laten zien hoe verschillende actoren een systeem gebruiken en slagen of falen. Ze geven een genuanceerdere weergave van alles wat je systeem kan doen om je te helpen bij het oplossen van problemen.

6. Herhaal stap 2-5 om je use case samen te stellen

Met genoeg variatie in actoren, doelen en scenario's kun je laten zien hoe je systeem functioneert. Door deze stromen samen te voegen krijg je een use case, die de ontwikkeling kan verbeteren en andere documenten zoals projectstatusrapporten kan informeren.

Met eenvoudige systemen kun je een paar elementen veranderen om elke mogelijke uitkomst te zien. Complexe systemen kunnen echter te veel elementen bevatten om elke uitkomst te kunnen zien. In dit soort gevallen kun je je richten op het testen van de meest voorkomende interacties. Je kunt ook systemen ontwerpen om niet-geteste com

Probeer Figma’s sjabloon voor use cases

Klaar om te brainstormen over use cases? Probeer de Figma use case-sjabloon om je systemen te ontleden en nieuwe oplossingen te vinden.

Voorbeeld van een use case

Stel je bent een productbeheerder die een app voor mobiel bankieren ontwikkelt voor je bedrijf. Je platform moet de registratie van gebruikers en het instellen van accounts stroomlijnen. Hier is een voorbeeld van een use case, gebaseerd op deze app:d

Achtergrondinformatie:

• Systeem: een app voor mobiel bankieren
• Primaire actor: klanten die een account willen openen
• Secundaire actor: kredietbeoordelaars en geautomatiseerde tools die rentepercentages en maximale hoofdsommen berekenen.
• Doelen: tijd besparen bij accountregistratie en onboarding
• Belanghebbenden: de CEO en product VP van jouw bedrijf
• Randvoorwaarden: gebruikers downloaden de app en voldoen aan de accountvereisten
• Triggers: de gebruiker kiest ervoor om een nieuwe rekening aan te maken vanuit de app

Scenario's:

• Basisstroom: Gebruikers downloaden je app en kiezen ervoor om een nieuwe rekening aan te maken. De applicatie verzamelt informatie over de andere rekeningen en kredietscores van de gebruiker. Van daaruit deelt het automatisch de rekeningen waarvoor de gebruiker in aanmerking komt en de betreffende rentetarieven. De gebruiker vindt een rekening die aan zijn behoeften voldoet en registreert zich.
• Alternatieve stroom 1: Gebruikers voeren hun financiële informatie in en de app genereert snel rekeningopties. Voor elke rekening wordt echter standaard de hoogste rente gehanteerd die de financiële achtergrond van de gebruiker toelaat. Gebruikers verlaten de app dus om een lagere rente te vinden.
• Alternatieve stroom 2: Het onboardingproces werkt zoals bedoeld, maar de app heeft te maken met nalevingsproblemen zoals Know Your Customer (KYC)-vereisten. Hoewel de app rekeningopties kan bieden, vertragen extra nalevingstappen het proces.
• Alternatieve stroom 3: Omdat de app alleen naar andere rekeningen en kredietscores kijkt, kunnen niet alle rekeningopties worden aangeboden. Er kunnen bijvoorbeeld alleen creditcards en kredietlijnen worden aageboden. Klanten die op zoek zijn naar een hypotheek moeten dus ergens anders heen.

Voordelen van use cases

In de planningsfase bepalen use cases de omvang, vereisten en het stappenplan van je project. Teams kunnen ook de beste gebruikersresultaten bespreken en een pad daar naartoe ontwerpen. Met alternatieve stromen kun je ook anticiperen op risico’s voordat ze de gebruikerservaring schaden. Als dat nog geen goede reden is om er een te maken, volgen hier nog enkele voordelen van use cases:

• Waarde uitleggen: Use cases leggen de functies van een systeem in duidelijke bewoordingen uit. Dus als je je plannen voorlegt aan belanghebbenden, maakt een use case je systeem makkelijker te begrijpen.
• Kosten voorspellen: Een use case geeft de complexiteit van een systeem weer. Meer complexiteit kan gepaard gaan met extra functies of beveiligingsmaatregelen. Door te bepalen hoe complex jouw systeem is, kun je de ontwikkelingskosten ramen.
• De planning verbeteren: Zonder een use case richten ontwerpers en ontwikkelaars zich op wat een systeem doet, niet hoe het dat doet. Use cases helpen teams echter om na te denken over alle manieren om functies en beveiligingen te implementeren.
• Alternatieve gebruiksmogelijkheden delen: Niet alle alternatieve stromen in een systeem leiden tot mislukte uitkomsten. Door verschillende scenario's in kaart te brengen, vind je nieuwe oplossingen voor oude problemen of vergroot je je begrip van wat een systeem kan bereiken.

Perfectioneer je use cases met FigJam

Gebruiksscenario's gaan verder dan beschrijven wat je product kan. Ze geven belanghebbenden en teams een duidelijk beeld van gebruikersinteracties en succesvolle resultaten. Of het nu gaat om het toevoegen van een nieuwe functie, snel een prototype bouwen, of het opnieuw ontwerpen van een systeem; je planning moet beginnen met het opstellen van een use case.

Hoe meer inzichten in actoren, interacties en uitkomsten, hoe beter - daarom is het van belang om samen met je team en belanghebbenden aan use cases te werken. Een gedeeld online whiteboard zoals FigJam stroomlijnt de samenwerking tussen teams op afstand om je te helpen uitgebreide use cases op te stellen. Onze galerij van meer dan 300 sjablonen kan teams in elk stadium van de ontwikkeling samenbrengen.