Tekenend problemen oplossen
Nóg een boek. Ik heb een inspirerende zomer, qua leeswerk, dat moge wel blijken uit mijn eerdere leesverslagen. Maar dit is tot nu toe wel de topper: The back of the napkin. Solving problems and selling ideas with pictures, van Dan Roam. Althans, het is het enige boek van de hele reeks waarbij ikzelf aan het oefenen ben geslagen.
Roam introduceert SQVID-framework: de vijf letters staan voor vijf dimensies met elk twee polen die in totaal tien verschillende manieren laten zien waarop je een concept kunt visualiseren. Hij illustreert dat aan de hand van een appel, en dat kon ik goed volgen, maar ik heb zelf zitten uitproberen of ik het wel echt snapte, aan de hand van het concept ’triathlon’, in deze dagen voor mij nogal actueel. Dit is het resultaat, en dat is niet goed leesbaar omdat het van Roam met potlood moest, en dat is ook wel prima, want het was maar oefenen en ik ben een van die mensen die zeggen niet zo goed te kunnen tekenen maar dat maakt volgens Roam niet uit:
Ik laat het alleen maar zien als bewijs dat het me tot ‘huiswerk’ geïnspireerd heeft. Ik heb alleen geen flauw idee of ik het goed begrepen heb. Ik heb dat bijna nooit, maar bij dit boek zouden oefeningen met uitwerkingen welkom zijn.
Wat ik oefenend merkte, is dat ik die dimensies niet per se visueel invul, dat kan net zo goed in woorden, wat mij betreft. De eerste letter, die S, die staat voor ‘simple’ versus ‘elaborate’, en bij ‘elaborate’ dacht ik aan de 2000 deelnemers van een grote wedstrijd. Maar daarvoor hoef ik die massa niet per se voor me te zien. Of wel?
Dat brengt me wel op het spoor van de vraag die voor mij overblijft na het lezen van het boek: is dit nou echt een nieuwe manier van probleemoplossen, namelijk door te tekenen, of is het het visualiseren van probleemoplossen? Het lijkt namelijk af en toe makkelijker dan dat het is. Dan tovert Roam een getekende oplossing van een probleem tevoorschijn en dan denk ik: ja, maar hoe heb je dan precies die stap gezet? Het gaat dan denk ik vooral om de tweede en derde stap van de vier die Roam definieert: looking-seeing-imagining-showing. In termen van het piramideprincipe vindt daar synthese plaats: niet alleen kijken naar wat de feiten zijn (‘looking’), maar ze clusteren tot betekenisvolle eenheden, interpreteren. Ik weet vanuit het werken met het piramideprincipe dat dat iets ongrijpbaars heeft, en dat heeft het óók als je tekent, ook al kun je wellicht met tekenen wel jezelf helpen nadenken.
De showing van het boek is deels niet zoveel nieuws, bijvoorbeeld als Roam de bekende regels voor grafiekvormkeuze behandelt. Maar hij zet wel een stap in conceptuele beelden die ik niet eerder heb gezien, door de beeldkeuze te koppelen aan het type vraag dat je beantwoordt. Dat zijn er zes:
- Wie en wat –> portret
- Hoeveel –> grafiek
- Waar –> kaart
- Wanneer –> timeline
- Hoe –> flowchart
- Waarom –> plot
Niet heel revolutionair, maar ik heb dat nog nooit ergens zo systematisch gezien, en het maakt de keuze voor bijvoorbeeld het ontwerpen van een presentatie wel overzichtelijk. De waarom-vraag als plot visualiseren maakt overigens wel duidelijk dat dat geen echte waarom-vragen zijn (vragen naar zin- en betekenisgeving) maar veredelde hoe-vragen (naar oorzaken en werking – maar dat is ook een beetje filosofische kwestie).
In vier stappen, met zes mogelijke vragen, langs vijf dimensies – en da’s alles, daarmee kun je problemen oplossen. Daarmee kun je ook een reusachtig PowerPointpack terugbrengen tot de essentie die op één pagina te tonen is Zegt Roam, en ik denk dus dat hij daar inderdaad nuttige instrumenten voor aandraagt. Dat het dan allemaal een eitje is, dat geloof ik niet. Maar wel dus dat het enorm kan helpen om dat potlood te pakken en visueel aan het denken te slaan. Zouden we vaker moeten doen, zeker voordat we PowerPoint aanzetten. Of Word – want ook om te schrijven moet je oplossingen bedenken.
Reacties
Tekenend problemen oplossen — Geen reacties
HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>