OI-01 Basis ⏱ 30 min

Het ontwerpprobleem en de criteria begrijpen

Training in het kort

Competentie: Ontwerpen & itereren
Indicator: OI-01 — Ontwerpprobleem en criteria begrijpen
Niveau: Basis
Duur: ongeveer 30 minuten
Projecttype: ontwerpproject
Resultaat: een afgebakende ontwerpvraag en controleerbare criteria

🎯 Wat leer je?

Je leert hoe je voorkomt dat het team te snel een oplossing kiest. Je onderzoekt eerst:

voor wie je ontwerpt;
welke situatie of behoefte centraal staat;
welke functies de oplossing moet vervullen;
welke harde eisen en wensen gelden;
welke aannames en onzekerheden nog gecontroleerd moeten worden.

📌 Wanneer gebruik je dit?

Gebruik deze training:

aan het begin van een ontwerpproject;
wanneer de opdrachtgever al één oplossing noemt;
wanneer het team meteen wil tekenen of bouwen;
wanneer gebruikersbehoeften nog vooral aannames zijn;
wanneer eisen vaag of tegenstrijdig zijn;
wanneer niet duidelijk is wat het ontwerp minimaal moet kunnen;
voordat je veel ideeën gaat ontwikkelen.

🧠 Begrijp eerst de behoefte, niet alleen het genoemde product

Een opdrachtgever kan zeggen:

“Wij willen een app.”

De werkelijke behoefte kan zijn:

“Bezoekers moeten snel kunnen zien waar activiteiten plaatsvinden.”

Misschien is een app passend, maar misschien werkt bewegwijzering, een display of een andere dienst beter.

Gebruik deze route:

Gebruiker → Context → Behoefte → Functies → Criteria → Ontwerpvraag

🛠️ Aan de slag

Stap 1 — Beschrijf de huidige situatie

Gebruik feiten uit de opdracht, observaties, gesprekken of bronnen.

Vraag	Bevinding
Wie ervaart het probleem of de behoefte?
Waar en wanneer speelt dit?
Wat gebeurt er nu?
Wat gaat goed en moet behouden blijven?
Wat belemmert of ontbreekt?

Schrijf nog geen oplossing.

Stap 2 — Maak stakeholders zichtbaar

Stakeholder	Belang of behoefte	Invloed op het ontwerp	Nog te vragen
gebruiker
opdrachtgever
beheerder/uitvoerder
andere betrokkene

Tip

De opdrachtgever en de dagelijkse gebruiker zijn niet altijd dezelfde persoon.

Stap 3 — Controleer aannames

Noteer drie aannames die jullie nu maken.

Aanname	Hoe controleren we dit?	Uitkomst
	interview / observatie / bron / meting

Voorbeelden van aannames:

leerlingen willen vooral meer zitplaatsen;
een product moet draagbaar zijn;
gebruikers begrijpen een symbool;
een materiaal is geschikt voor buiten;
de beheerder kan dagelijks onderhoud uitvoeren.

Stap 4 — Formuleer de kernbehoefte

Gebruik:

[Gebruiker] heeft behoefte aan [verbetering of mogelijkheid], omdat [relevante context of probleem].

Voorbeeld:

Beginnende mountainbikers hebben langs de route behoefte aan een eenvoudige plek om kleine reparaties veilig uit te voeren, omdat zij vaak geen eigen gereedschap meenemen en de dichtstbijzijnde werkplaats ver weg is.

Stap 5 — Maak een functieoverzicht

Functies beschrijven wat de oplossing moet doen, nog niet hoe.

Oplossing

Er moet een metalen kast met pomp komen.

Functies

fiets stabiel ondersteunen;
band kunnen oppompen;
basisgereedschap beschikbaar maken;
materialen tegen weer en diefstal beschermen;
gebruiker uitleg geven.

Hoofdfunctie	Deelfunctie	Waarom nodig?

Stap 6 — Verzamel criteria uit meerdere bronnen

Criteria kunnen komen uit:

opdracht en opdrachtgever;
gebruiker;
locatie en context;
veiligheid;
wet- of regelgeving;
techniek en materialen;
onderhoud;
duurzaamheid;
budget en planning;
onderzoek of expertadvies.

Maak onderscheid:

Harde eis

Moet worden gehaald. Een ontwerp dat niet voldoet, kan niet zonder aanpassing worden gekozen.

Wens

Verhoogt de kwaliteit, maar kan worden afgewogen tegen andere belangen.

Open onzekerheid

Is nog niet bewezen en moet worden onderzocht, berekend of getest.

Criterium	Eis / wens / onzekerheid	Herkomst	Hoe controleren we dit?

Stap 7 — Maak criteria controleerbaar

Te vaag

Het ontwerp moet stevig zijn.

Controleerbaar

De steun moet een fiets van 25 kg gedurende 10 minuten dragen zonder blijvende vervorming.

Te vaag

Het ontwerp moet gebruiksvriendelijk zijn.

Controleerbaar

Minimaal vier van de vijf testgebruikers kunnen de fietsklem zonder uitleg binnen 20 seconden correct gebruiken.

Een bruikbaar criterium bevat waar mogelijk:

Wat → Voor wie/waar → Onder welke omstandigheden → Grens of gewenste prestatie

Warning

Niet ieder criterium hoeft direct een getal te bevatten. Het moet wel duidelijk zijn hoe je later beoordeelt of het ontwerp eraan voldoet.

Stap 8 — Controleer tegenstrijdigheden

Voorbeelden:

licht én zeer sterk;
goedkoop én onderhoudsvrij;
open toegankelijk én diefstalbestendig;
compact én geschikt voor grote groepen.

Noteer:

Mogelijke spanning	Welke informatie of keuze is later nodig?

Los nog niet alles op. Maak zichtbaar waar later een afweging nodig is.

Stap 9 — Formuleer de ontwerpvraag

Gebruik bijvoorbeeld:

Hoe kunnen we voor [gebruiker] een [soort oplossing, niet te specifiek] ontwerpen die [kernfunctie/behoefte], binnen [belangrijke randvoorwaarden]?

Voorbeeld:

Hoe kunnen we voor beginnende mountainbikers een onderhoudsvoorziening ontwerpen waarmee zij langs de route veilig kleine reparaties kunnen uitvoeren, binnen de beschikbare ruimte en met beperkt beheer?

Controleer:

gebruiker en behoefte zijn zichtbaar;
de vraag schrijft nog niet één technische oplossing voor;
belangrijke context of grens is genoemd;
de vraag laat meerdere oplossingsrichtingen toe;
de vraag past bij de opdracht.

Stap 10 — Laat de probleemanalyse controleren

Vraag aan gebruiker, opdrachtgever, expert of docent:

“Herkennen we de belangrijkste behoefte goed?”
“Welke stakeholder of situatie ontbreekt?”
“Is dit werkelijk een harde eis?”
“Welk criterium is nog te vaag?”
“Welke aanname moeten we vóór het ontwerpen controleren?”
“Laat de ontwerpvraag voldoende verschillende oplossingen toe?”

Verwerk de feedback voordat je uitgebreid ideeën ontwikkelt.

💡 Voorbeeld uit een Technasiumproject

Eerste opdrachtinterpretatie

Ontwerp een reparatiezuil voor een mountainbikebaan.

Het team denkt meteen aan een metalen kast met gereedschap.

Onderzoek van de context

Uit observatie en gesprekken blijkt:

gebruikers hebben vooral problemen met lekke banden en losse onderdelen;
lange reparaties worden niet langs de baan uitgevoerd;
de beheerder wil weinig losse onderdelen;
de plek staat onbewaakt buiten;
kinderen moeten veilig langs de voorziening kunnen lopen.

Kernbehoefte

Recreatieve mountainbikers moeten kleine reparaties veilig en zelfstandig kunnen uitvoeren zonder dat de voorziening veel dagelijks beheer vraagt.

Functies

fiets ondersteunen;
banden oppompen;
enkele gereedschappen veilig aanbieden;
korte instructie geven;
regen en vandalisme weerstaan.

Criteria

Criterium	Type	Controle
gebruiker kan fiets stabiel plaatsen	eis	test met vijf verschillende fietsen
losse onderdelen kunnen niet eenvoudig worden meegenomen	eis	technische controle en beheerdersfeedback
voorziening past binnen 1,2 × 0,8 m	eis	maatcontrole
gebruiker begrijpt instructies zonder docent	wens	gebruikerstest
onderdelen zijn afzonderlijk vervangbaar	wens	ontwerpcontrole
geschikte fundering	onzekerheid	locatie en expert controleren

Ontwerpvraag

Hoe kunnen we voor recreatieve mountainbikers een compacte en vandalismebestendige onderhoudsvoorziening ontwerpen waarmee zij langs de route veilig de meest voorkomende kleine reparaties kunnen uitvoeren?

Nu kan het team meerdere oplossingsrichtingen ontwikkelen in plaats van alleen verschillende vormen van dezelfde kast.

✅ Controleer jullie probleemanalyse

✅ Wanneer is deze training voltooid?

Je kunt de training als Voltooid markeren wanneer:

gebruiker, context en kernbehoefte zijn beschreven;
belangrijke aannames zijn gecontroleerd of als onzekerheid vastgelegd;
hoofd- en deelfuncties zijn benoemd;
harde eisen en wensen controleerbaar zijn geformuleerd;
een open ontwerpvraag is opgesteld;
feedback op probleemanalyse en criteria is verwerkt.

Warning

Voltooid is niet hetzelfde als beheerst.
Alleen de docent kan aangeven dat je deze vaardigheid beheerst. De docent kijkt ook of je in nieuwe situaties zelfstandig gebruikersbehoeften, functies, randvoorwaarden en onzekerheden kunt herkennen.

🔄 Wat schrijf je in je reflectie?

Welke aanname bleek niet te kloppen?
Welk gebruikersperspectief veranderde de opdracht?
Welk criterium werd concreter?
Welke spanning tussen criteria verwacht je?
Welke onzekerheid moet nog onderzocht worden?
Hoe veranderde de ontwerpvraag?

Voorbeeldreflectie

Wij dachten eerst dat gebruikers vooral veel gereedschap nodig hadden. Uit interviews bleek dat zij vooral een stabiele fietssteun en pomp missen. We hebben daarom de functie “alle soorten reparaties mogelijk maken” verkleind naar veelvoorkomende kleine reparaties. De eis “stevig” is veranderd in een testbare draag- en stabiliteitseis. Diefstalbestendigheid en eenvoudige vervanging kunnen elkaar tegenwerken. We moeten nog met de beheerder controleren welke bevestigingsmethode op de locatie mogelijk is.