Door: Gerben de la Rambelje
Auteur: Nathalie Rooseboom de Vries – van Delft ● funtestic.fanatic@gmail.com
Een foto vertelt (vaak) een verhaal, net als een schilderij, even daargelaten of je het kunstwerk ‘snapt’. Ikzelf kan me nog voor het geestesoog halen dat ik tijdens mijn opleiding geschoold werd in ‘moodboarding[i]’, ‘storyboarding[ii]’ en ‘prototyping[iii]’. Dit zijn drie technieken die een ontwerp niet beschrijven, maar visueel weergeven.
Zo kwam er bij de ‘moodboards’ nagenoeg geen tekst aan te pas, tenzij het woorden waren die het beeld moesten ondersteunen. Zo werden woorden als ‘Fluffy’ en ‘Zacht’ zo trendy mogelijk over plaatjes van schapenvachtjes geplakt voor het ontwerp van een website voor babykleertjes, zodat het vooral duidelijk zou zijn dat het uiteindelijke resultaat heel zacht en aaibaar zou zijn. In de ‘storyboards’ namen we alleen tekst op die een actie of een beweging moesten uitleggen; bewegingen en handelingen blijven immers lastig om op een stilstaand beeld weer te geven.
De stap die er na kwam, nog steeds in de ontwerpfase trouwens, bestond uit het modelleren van de vragen en wensen van de klant. Ik leerde nog van modelleren volgens wat Booch en Rumbaugh hadden bedacht (nu kent iedereen het als UML). Unified Proces (voorloper van RUP) was net in zwang en we ontwikkelden volgens het Iteratief Application Development (leuke kennisvraag hier: Wanneer studeerde ik (ongeveer)?[iv]). Eindeloos heb ik modellen en diagrammen zitten tekenen. Datastromen, klassen, objecten en zelfs de navigatie werden vastgelegd in een model. Ik had nog het meest de ‘P’ in ‘use-case’ diagrammen, want dan moest je ineens een hoop er bij opschrijven. Ik was een persoon die liever alles uittekende.
De meeste tekst kwam pas in het functioneel ontwerp aan de orde en daarna deed de bouwfase zijn intrede. Oftewel: in de code. Dat was hét moment dat ik het meest gebruikmaakte van mijn toetsenbord, voor die tijd was het vooral het potlood, schaar, papier en mijn sleur-en-pleur WYSIWYG tooltje. Testen deden we met de klant er naast, we gaven een demonstratie en vervolgens lieten we iedere vraag en requirement zien in de applicatie; geen ding werd vastgelegd in geschrift, we pasten gewoon het prototype aan en maakten (digitale) krabbels er op.
Nu waren het op mijn opleiding (tweede quizvraag; welke opleiding deed ik?[v]) simpele applicaties en websites die we maakten, maar het kwam er op neer dat het overgrote deel van het proces gebaseerd was op visualisatie van dingen. Het ging om de plaatjes. Tekst was ondergeschikt.
Het is voor mij een vreemde gewaarwording dat, ondanks de roep (eigenlijk meer: schreeuw) om visualisatie, er tegenwoordig zo weinig wordt gewerkt met beelden en modellen. Zeker omdat ik het zelf vanuit mijn basis heb meegekregen en er veel gebruik van maak, ik zie het als iets vanzelfsprekends. Het is niet voor niets dat Kanban en/of Scrum-boards zo populair zijn. ‘Eén beeld zegt meer dan duizend woorden’, begon ik deze column. Wat ik echter zie, is dat er meer dan duizend woorden worden gebruikt om één beeld te schetsen. Lappen tekst waar je alleen nog wijs uit wordt als je er een schetsblok er bij pakt en start met uittekenen. Heb je het echter uitgetekend, dan is voor iedereen – nou ja, bijna iedereen – duidelijk wat er wordt bedoeld en ziet men ook vaak gelijk de problemen en kansen.
Het maken van een model of een diagram vergt echter wel kennis en kunde. Met andere woorden, het maken van een beeld dat boekdelen spreekt voor iedereen, vergt zowel een goede toepassing van modelleringstechnieken als kennis van het domein en/of systeem waarvoor gemodelleerd wordt, inclusief de plaats in het ‘grotere geheel’ van de organisatie. Het is een vak apart om iets dusdanig te condenseren tot één beeld dat het begrijpelijk is en eenduidig interpreteerbaar.
Over die kunde en kennis en het zien van problemen bij het visueel werken gesproken heb ik nog een klein voorbeeld uit de praktijk…
‘Toen ik – overigens al weer (heel) wat langer geleden- een ontwerper vroeg waarom hij zijn bedenksels niet in UML (nu is dat 2.5 inmiddels uiteraard) had neergezet, kreeg ik een bijna verwilderde blik toegeworpen. De beste man had toch use-cases gemaakt? Toen ik hem uitlegde dat er toch écht een verschil was tussen ‘use-case’ en ‘use-case diagram’, was er eerst onbegrip in de vorm van “Wat weet jij er nu van?”. Vlot daarna – en nadat ik hem vluchtig had zien zag Googlen – kwam er een stamelend “oh” vanachter het beeldscherm vandaan. De keer dat ik daarna de “specs” kreeg, was deze voorzien van een diagram én de verpakking had zelfs een mooi strikje: “Ik zag toen ik ‘m uittekende dat er nog wat miste en iets niet klopte” zei hij.’
Ik denk dat het steeds vaker aan de benodigde kennis en kunde ontbreekt en daardoor steeds vaker wordt teruggegrepen op tekst(en). Of dat nu komt omdat veel mensen zich genoodzaakt voelen ‘alleskunners’ (lees: analist, ontwikkelaar en tester) te moeten zijn, omdat het proces dat nu eenmaal beschrijft, of het niet meer leert in de opleiding of dat het komt omdat men zich er simpelweg niet in wil verdiepen (of de tijd wil spenderen om dit te doen). Ik heb geen idee.
Wat ik wel weet, is dat men steeds vaker dingen wil visualiseren, maar dat er geen moeite wordt gedaan dit op een goede, effectieve en bruikbare manier te (leren) doen. In plaats daarvan kiest men ervoor teksten te schrijven om datzelfde beeld te beschrijven. Teksten die op meerdere manieren opgevat kunnen worden, die vragen oproepen en uiteindelijk leiden tot een veel grotere tijdinspanning dan wellicht het ‘leren-van’ en ‘uittekenen-van’ bij elkaar had gekost. Het leuke is dat nota bene testers wel die inspanning leveren en teksten (vaak) nagenoeg automatisch omkatten tot een model (eigen mentaal model, praatplaat of UML-compliant om het even) en daarvoor ook weer credits krijgen dat juist deze testers het allemaal zo helder op hun netvlies hebben.
En dat brengt me dan ook weer op een volgend punt. Ik hoor de laatste jaren steeds weer op congressen en lees in blogs dat ‘de tester dood is‘. Ik ben het daar helemaal niet mee eens. Ik denk dat juist de tester bij uitstek zaken kan visualiseren. De tester heeft vaak wel het overzicht en kan prima aan de business zaken uitleggen. Ze zijn dé vertalers tussen wens en techniek. Testers hebben meer dan andere disciplines zich verdiept in andere vakgebieden omdat ze daar de toegevoegde waarde van hebben gezien en ze passen die toe in hun eigen vakgebied. Zo kunnen we bijvoorbeeld coderen in testautomatisering en analyseren bij het ontwerpen van testcases. Daartegenover ben ik van mening dat de ontwikkelaar vaak ‘testen’ nog ondergeschikt vindt en het liefst vermijdt (daar is een tester toch voor?) en de analist modelleren en reviewen steeds vaker achterwege laat (daar is de tester toch voor?). De tester is dood? Welnee! De tester is meer levend dan ooit! En dat is een beeldvorming waar ik graag wat woorden aan spendeer!
[i] Moodboarding is een techniek waarbij met afbeeldingen, kleuren en woorden een collage wordt gemaakt om een bepaalde sfeer of een generiek idee van een eindproduct te schetsen.
[ii] Storyboarding is een techniek waarbij men plaatjes en schetsen in volgorde plaatst zodat deze – bijvoorbeeld- interactie van een (multimedia)applicatie weergeeft zoals deze uiteindelijk zal worden.
[iii] Prototyping is een techniek waar een applicatie in ruwe vorm wordt gemaakt zodat de (eind)gebruiker zich een beeld kan vormen van het uiteindelijke product. In de gevolgde opleiding werd dit met een WYSIWYG software development product gedaan (Powerbuilder) en werden de schermen, inclusief menu’s en knoppen geheel neergezet.
[iv] 1997-2001
[v] Informatica; vormgeving en ontwerp van interactie