Het RISEN Framework

Sommige taken zijn te complex voor een simpele prompt. Je hebt niet alleen een rol en een doel nodig, maar ook een stappenplan, heldere eindcriteria en afbakening van wat wél en niet bij de opdracht hoort. Dat is precies waar het RISEN framework voor is ontworpen. Het is ideaal voor meerstaps-projecten waarbij je het AI-model als een volwaardige projectmedewerker wilt inzetten.

Wat is RISEN?

RISEN staat voor Role, Instructions, Steps, End Goal, Narrowing. Het framework is specifiek ontworpen voor complexe opdrachten die meerdere stappen vereisen en waarbij je precies wilt sturen hoe het model te werk gaat. Waar CO-STAR focust op communicatie en schrijfwerk, richt RISEN zich op gestructureerde uitvoering.

RISEN werkt het beste voor projectplannen, technische specificaties, onderzoeksopzetten, strategiedocumenten en alle taken die een duidelijke reeks stappen vereisen.

De vijf onderdelen

• R — Role: Welke expert moet het model zijn? Dit bepaalt het perspectief en de diepte van het antwoord. Bij RISEN mag de rol uitgebreider zijn dan bij simpelere frameworks, omdat de taak complexer is.
• I — Instructions: Wat moet het model doen? Dit is de hoofdopdracht, helder en ondubbelzinnig geformuleerd. Wat is de kernactiviteit?
• S — Steps: Welke stappen moet het model volgen? Dit is het onderdeel dat RISEN onderscheidt van andere frameworks. Je schrijft een expliciet stappenplan dat het model moet doorlopen. Dit voorkomt dat het model stappen overslaat of in de verkeerde volgorde werkt.
• E — End Goal: Wat is het gewenste eindresultaat? Beschrijf niet alleen wát je wilt krijgen, maar ook de kwaliteitseisen. Wanneer is het resultaat "af" en "goed genoeg"?
• N — Narrowing: Wat hoort er níét bij? Welke onderwerpen, perspectieven of oplossingsrichtingen moet het model vermijden? Afbakening is cruciaal bij complexe taken om te voorkomen dat het model te breed gaat.

Het RISEN template

# ROLE
[Beschrijf de expert die het model moet zijn]

# INSTRUCTIONS
[Wat is de hoofdopdracht?]

# STEPS
1. [Eerste stap]
2. [Tweede stap]
3. [Derde stap]
...

# END GOAL
[Beschrijf het gewenste eindresultaat en kwaliteitseisen]

# NARROWING
[Wat moet het model vermijden of weglaten?]

RISEN in de praktijk: een Product Requirements Document

Stel, je moet een PRD (Product Requirements Document) schrijven voor een nieuwe feature. Zo pak je dat aan met RISEN:

# ROLE
Je bent een senior productmanager met 8 jaar ervaring
bij B2B SaaS-bedrijven. Je schrijft heldere, uitvoerbare
requirements documenten die development teams direct
kunnen gebruiken als basis voor hun werk.

# INSTRUCTIONS
Schrijf een Product Requirements Document voor een
notificatiesysteem in onze projectmanagement-app
"TaskFlow". Gebruikers moeten meldingen kunnen
ontvangen wanneer taken aan hen worden toegewezen,
deadlines naderen of teamgenoten comments plaatsen.

# STEPS
1. Begin met een executive summary van het probleem
   en de voorgestelde oplossing (max 100 woorden)
2. Beschrijf de user stories (als [rol] wil ik [actie]
   zodat [resultaat])
3. Definieer de functionele requirements per user story
4. Beschrijf de niet-functionele requirements
   (performance, schaalbaarheid)
5. Maak een prioriteitenlijst (must-have, should-have,
   nice-to-have)
6. Beschrijf de belangrijkste risico's en open vragen

# END GOAL
Een compleet PRD van 800-1000 woorden dat het development
team kan gebruiken om de feature te bouwen. Het document
moet concreet genoeg zijn om er direct user stories en
taken van te maken, zonder verdere verduidelijking.

# NARROWING
- Geen technische implementatiedetails (geen database
  schema's, geen API-endpoints, geen code)
- Geen vergelijking met concurrenten
- Focus alleen op de notificatiefunctie, geen andere
  features beschrijven
- Geen tijdsplanning of resource-allocatie

Wanneer gebruik je RISEN?

• Projectplannen en specificaties: Wanneer je een gestructureerd document nodig hebt dat stap voor stap wordt opgebouwd.
• Onderzoeksopzetten: Als je het model wilt laten werken volgens een methodische aanpak.
• Strategiedocumenten: Wanneer meerdere aspecten systematisch moeten worden behandeld.
• Complexe analyses: Als de analyse meerdere stappen vereist die in de juiste volgorde moeten worden uitgevoerd.
• Handleidingen en procedures: Wanneer het eindresultaat zelf ook een stapsgewijze structuur moet hebben.

Veelgemaakte fouten

• Stappen te vaag formuleren: "Analyseer het probleem" is geen bruikbare stap. "Beschrijf het probleem in maximaal 3 zinnen, inclusief de impact op de gebruiker" is wél bruikbaar. Hoe concreter de stappen, hoe beter het resultaat.
• Narrowing vergeten: Zonder afbakening gaat het model te breed. Vooral bij complexe onderwerpen is het cruciaal om aan te geven wat het model niet moet doen.
• End Goal niet meetbaar maken: "Een goed document" is geen bruikbaar einddoel. "Een document van 800-1000 woorden dat het development team direct kan gebruiken" geeft duidelijke criteria.

Zelf aan de slag

Denk aan een complex project of document dat je binnenkort moet opstellen. Breek het op in de vijf RISEN-onderdelen: wie is de expert, wat is de opdracht, welke stappen moeten worden doorlopen, wat is het gewenste eindresultaat, en wat hoort er niet bij? Je zult merken dat alleen al het invullen van het framework je helpt om helderder na te denken over wat je eigenlijk nodig hebt. En die helderheid vertaalt zich direct naar een beter resultaat van het AI-model.