Het tijdloze schaalbare ontwerpproces deel 4

Deel 4: Tijdloosheid en zijn oorsprong

De belangrijkste innovatie in dit ontwerpproces zit in de schaalbaarheid. Te veel auteurs beweren dat hun proces schaalbaar is, maar laten het niet zien of leggen het niet uit. Deze aanpak onderscheidt zich doordat ze vanuit meerdere perspectieven komt. Dit proces combineert zowel mijn ontwerpstudies van vele wijze auteurs, via gesprekken met toonaangevende ontwerpers op UX-conferenties, als de werkpraktijk en het mentorschap van veel van mijn briljante collega's, naast mijn eigen praktijk en de praktijken die ik heb gedeeld tijdens de lange reis die mijn multi-domein carrière in design is geweest. (Zie een gedeeltelijke lijst in de referenties en dankbetuigingen aan het einde.)

Zo leerde ik uit de eerste hand wat wel en niet werkte. En wat niemand in ontwerpprocessen die ik ken, heeft gedaan, is de methode of techniek loskoppelen van het proces, met name voor softwareprojecten. En dat is de kern van dit schaalbare ontwerpproces: laat je leiden door de procesdoelen, niet door een specifieke, onschaalbare methode of activiteit. Een scherpzinnige ontwerper weet hoe hij een context moet analyseren om de methode of techniek te kiezen die de ontwerpdoelen in een bepaalde context het beste bereikt. (En inderdaad, Keen Design helpt bedrijven vaak die analyse te leren, zowel voor een specifiek project als voor een bedrijf of organisatie.)

In mijn vorige artikel, deel 3, beschreef ik het Tijdloze Schaalbare Ontwerpproces en presenteerde ik een gestructureerd maar flexibel raamwerk dat creatieve vrijheid in evenwicht brengt met methodische progressie. Deze 'gecontroleerde willekeurige wandeling'-aanpak maakt innovatie mogelijk, niet alleen binnen een gestructureerd raamwerk, maar ook door de ontwerper te dwingen geconfronteerd te worden met ongemakkelijke en ongemakkelijke kwesties en door ontwerpers te dwingen hun kritisch denkvermogen te gebruiken. Minder professionele ontwerpers en designmanagers hebben dit bekritiseerd vanwege de 'hoofd-exploderende' complexiteit, wat eerder een erkenning is van de bescheiden capaciteit van hun ontwerpend denken dan een kritiek op hoe eenvoudig ontwerp zou moeten zijn. In veel opzichten onderscheidt een echt ontwerpproces een echte ontwerper van een carbonversie van een AI-machine. De resultaten van een ontwerpproces zullen ontwerpen opleveren die zowel innovatief als duurzaam zijn, iets wat een standaardontwerpoefening nooit kan. [Terzijde, een vraag voor de AI-specialisten in het publiek: klopt het dat AI alleen conservatieve resultaten kan opleveren omdat het gebruikmaakt van een LLM die van nature geworteld is in wat al is gedaan en wat momenteel mogelijk is (met andere woorden: kan AI synthetiseren, maar niet innoveren)?

Een goed ontwerpproces kan meer tijd kosten om tot een eerste resultaat te komen, maar levert uiteindelijk innovatievere, consistentere en duurzamere ontwerpen op dan ad-hocbenaderingen. Die zullen namelijk uiteindelijk resulteren in een 'monster van Frankenstein' van ontwerpoplossingen en inconsistenties die voortvloeien uit ad-hoc-ontwerpen.

Het onderstaande proces in vier fasen gaat van een concreet startpunt, de “bestaande toestand”, naar de meer ongrijpbare “voorkeurstoestand”. De voorkeurstoestand is ongrijpbaar omdat deze onbepaald is. In een vroeger tijdperk, zoals toen Herbert Simon voor het eerst de term “voorkeursresultaten” bedacht, had een ontwerp een vastomlijnd einde. Maar nu bevinden we ons in een tijdperk dat beter wordt beschreven door Horst von Rittel, waar het ontwerpproject eindigt "niet om redenen die inherent zijn aan de logica van het probleem. In plaats daarvan stoppen we vanwege overwegingen die buiten het probleem liggen: de tijd, het geld of het geduld raakt op. Uiteindelijk zeggen we: ‘Dat is goed genoeg,’ of ‘Dit is het beste waarmee ik uit de voeten kan binnen de beperkingen van het project,’ of ‘Deze oplossing bevalt me,’" enz. De vier fasen tussen deze twee fasen zijn:

1. Discover (Ontdekken): Deze fase begint met het begrijpen van de ontwerpuitdaging en vervolgens met het uitbreiden en opnieuw kaderen van het probleem. Door kritisch en systeemdenken interactief met belanghebbenden te gebruiken, herkaderen ze het probleem om een holistisch begrip te krijgen voordat ze tot een definitie komen die het project zal sturen.
2. Concept: Formatief onderzoek in combinatie met kritisch denken legt de basis voor 3-10 unieke conceptuele oplossingen. Door middel van iteratief ontwerp en formatief-evaluatief onderzoek worden deze concepten samengevoegd tot één conceptueel model dat de rest van het project stuurt.
3. Detail: Via meer evaluatief onderzoek wordt het conceptuele ontwerp vertaald naar een concreet ontwerp. Het ontwerp coördineert ook met technische middelen voor implementatie en ontwerpactiva. De gedetailleerde ontwerpen worden gevalideerd door gebruikersonderzoek en convergeren uiteindelijk in interactiepatronen, building blocks, and other design elements.
4. Deliver (Leveren): Deze fase begint vaak als de “Devil is in the details”-fase vanwege onverwachte problemen die zich voordoen tijdens de implementatie. Deze fase vereist nauwe samenwerking met ontwikkeling om problemen op te lossen en tegelijkertijd de conceptuele integriteit te behouden. Tegen het einde wordt het de fase van “God is in the details” wanneer de beoogde gebruikerservaring vorm krijgt.

Tijdloos

Zoals hierboven vermeld, is wat dit proces schaalbaar maakt de nadruk op universele doelen per fase in plaats van specifieke activiteiten of methoden. Door de activiteiten te scheiden van de ontwerpdoelen kunnen ontwerpers hun aanpak afstemmen op de reikwijdte van het project, de middelen en hun eigen expertise, terwijl ze toch voldoen aan de tijdloze doelen van elke fase. Maar de stappen zelf zijn essentieel voor dit proces en de vraag rijst waar ze vandaan komen, aangezien ik ze niet zomaar heb verzonnen, maar eerder op enkele zeer hoge schouders heb gestaan.

Waar kwam het proces vandaan?

Een eenvoudig antwoord: dit proces kwam voort uit een synthese van de ontwerpprocessen die ik en mijn vele collega's hebben beoefend; van de ontwerptheorie die ik heb toegepast en van de vele andere ontwerpers die hebben geholpen bij het becommentariëren en verfijnen van dit proces (zie de lijst met referenties en erkenningen aan het einde voor een omvangrijke, zij het onvolledige lijst). Zoals hierboven vermeld, was ook de studie van vele ontwerpprocessen van toonaangevende ontwerpers, ontwerpscholen en ontwerpbewegingen van bijzonder belang.

Wat hadden al deze processen en theorieën gemeen? Het waren zeker niet de methoden of de gebruikte technieken. Voor die activiteiten was er weinig overeenstemming. Maar er waren nog veel lessen te leren, die ik hieronder met jullie zal delen.

Wat is het ontwerpproces en waar komt het vandaan? Een complete geschiedenis van ontwerpen met de Discover-Define-Develop-Deliver (de termen die worden gebruikt door de meest voorkomende versies van de "double diamond) methode zou gemakkelijk een boekwerk vergen dat veel groter is dan wat we hier kunnen behandelen. Voor ons doel geef ik slechts een korte samenvatting (en mijn excuses voor de liefhebbers van de geschiedenis van design die dit als een oververeenvoudiging zullen zien) aan de hand van een paar voorbeelden van vroege en formatieve versies van het ontwerpproces en zijn stappen. In deze voorbeelden lijken deze termen sterk uiteen te lopen, maar naarmate de ontwerppraktijk meer en meer ervaren wordt, krijgen we steeds meer verfijnde en gedestilleerde thema's en variaties tot het punt waarop we de stappen kunnen samenvatten zoals hieronder beschreven.

Vroege pioniers

Onze reis moet ergens beginnen, dus in het belang van de tijd begin ik met een van de eerste ontwerpprocessen en een begrip van design dat we zouden herkennen. László Moholy-Nagy, die zijn carrière begon in de Bauhaus-school, verwoordde zijn ontwerpproces het best in zijn werk aan het Chicago Institute of Design, dat later bekend zou worden als het Institute of Design aan het Illinois Institute of Technology. Maar hij begon al veel eerder in de Bauhaus school in Weimar, Duitsland. Bij het Bauhaus en andere designbewegingen uit die tijd (constructivisme, Deutsche Werkbund, enz.), ontwikkelde zich een standaardbenadering van design die kan worden samengevat als “vorm volgt functie”, wat betekent dat de vorm moet worden bepaald door de functie van een object. In Chicago breidt Moholy-Nagy dit concept uit: “de uitspraak ‘vorm volgt functie’ moet worden aangevuld; dat wil zeggen dat de vorm ook bestaande wetenschappelijke, technische en artistieke ontwikkelingen volgt - of in ieder geval zou moeten volgen - met inbegrip van de sociologie en de economie.” Door dit te doen erkent het ontwerpproces een wereld buiten alleen de vorm en functie, en omvat het zowel een bredere context inclusief esthetiek. Hiertoe heeft hij een ontwerpproces ingekapseld. Je kunt Moholoy-Nagy's proces als volgt destilleren:

Deze stappen komen ongeveer overeen met Discover-Concept-Detail-Deliver.

Discover – Investigation

Define – Ideation

Detail – Experimentation

Deliver – Realization

Sindsdien zijn er herhalingen van deze ontwerpbenadering opgedoken, met dit gemeenschappelijke thema in de een of andere vorm.

Academische pogingen: Brian Archer

De systematische ontwerpmethodologie van Brian Archer heeft het proces gespecificeerd in een soort kookboek of checklist die alle permutaties van een ontwerpproject probeert vast te leggen. De oefening omvatte meer dan 250 stappen, maar ze pasten in ruwweg 7 fasen:

Als we de definities van deze fasen zouden bestuderen, zouden ze ook gemakkelijk kunnen worden samengevat in de vier verschillende fasen:

Discover – Preliminaries & briefing

Concept – programming & data collection

Detail – Synthesis

Deliver – Communication

HCI Engineering-Processen

Parallel aan de ontwerpgemeenschap volgde de HCI-gemeenschap haar eigen koers. De HCI-gemeenschap stond bekend onder twee vergelijkbare namen: de CHI (Computer-Human Interaction community), de academische gemeenschap die verbonden was aan ACM/SIGCHI of de HCI (Human-Computer Interaction community) die verbonden was aan de academische discipline in het algemeen. Deze groepen waren grotendeels uitwisselbaar, afhankelijk van wie je vond dat eerst moest komen, de computer of de mens. Maar de vlaggenschipconferentie voor UX ontwerp in de jaren 80 en 90 waren de CHI conferenties (en andere gespecialiseerde UX conferenties) gesponsord door ACM/SIGCHI. Op deze conferenties was de ontmoeting met andere UX-designers een plek voor het delen en ontwikkelen van HCI-werk.

Deze gemeenschap volgde zijn eigen UX-ontwerpprocessen, los van wat er elders op het gebied van design gebeurde. Hun benadering leek meer op een engineering benadering. In de jaren 1980 en 1990 noemden veel HCI-beoefenaars zichzelf “Usability Engineers”. Er ontstond ook een wildgroei van Usability Engineering Consultants die softwarebedrijven konden helpen bij het maken van gebruiksvriendelijkere software, omdat er intern niemand was die deze functie kon uitvoeren. Deze vroege HCI-professionals waren zeker meer in lijn met het oude Bauhaus van vorm volgt functie met zeer weinig aandacht voor esthetiek, met uitzondering van een van IBM's oude favoriete mantra's: Keep It Simple Stupid.

Unified Software Development Process

Net als tegenwoordig, waar design lijkt te worden gedomineerd, zo niet onderworpen, door Agile software engineering, werden de jaren 80 en 90 gedomineerd door een ander softwareontwikkelingsproces, het Unified Software Development Process. Het was extreem invloedrijk, omdat het een gegeven was dat Usability Engineering het engineeringproces van die tijd moest volgen.  Het Unified Software Development Process was een watervalmethode. In die tijd zag het Unified Software Development-proces er als volgt uit:

Deze stappen volgden een puur engineering-proces waarbij Inception het begin was, beginnend met een eerste bijeenkomst van het softwareteam met een eerste “iteratie” en na enige analyse wordt een tweede iteratie geproduceerd die de basis zou vormen voor de volgende stap. Uitwerking zou dan de tweede iteratie nemen en vereisten extrapoleren en een verdere analyse die zou eindigen met de start van wat ze ‘ontwerp’ noemen. Vervolgens werd in de constructiefase de software gemaakt en getest, dat was dan het einde van het ontwerp. Het proces werd afgesloten met de transitiefase, het uitrollen van deze software. Deze overgang werd ook wel “Iteraties 3+” genoemd, zie deze “iteraties” als versies van software waarbij het hele proces niet wordt herhaald maar aangevuld: nieuwe functies of bugfixes.

HCI-professionals probeerden ontwerpactiviteiten geforceerd in te passen in dit (en andere) Software Engineering watervalproces.

Het Unified Software Development Process legde de nadruk op het uitbrengen van een enkel waterval-programma waar vervolgens versies van werden gemaakt. Het gaf een definitief einde aan het softwareproject waar Herbert Simon en zijn ontwerpvolgelingen blij mee zouden zijn geweest, als het iemand iets had kunnen schelen (maar dat deed het niet). Waterval-development processen zouden niet overleven omdat software steeds complexer werd, zodat het steeds langer duurde om de software te produceren, wat resulteerde in de behoefte aan eerdere feedback. Deze behoefte gaf aanleiding tot de nu alomtegenwoordige incrementele Agile-ontwikkelmethoden.

User Centered Design

Naarmate het ontwerp in HCI volwassener werd, werden ook de ontwerpprocessen volwassener. In het bijzonder onderscheidde de HCI-gemeenschap zich als degenen die “opkwamen voor de gebruiker” in de vorm van gebruikersgericht ontwerp. Verschillende smaken van het user-centered design proces begonnen vooral op te duiken in workshops op verschillende HCI-conferenties, zoals die van J. Gulliksen, die probeerde user-centered design te onderwijzen aan HCI-professionals. Gullicksen's proces sloot aan bij de Unified Software Development Process software engineering processen, niet bij de ontwerpprocessen van mensen als Laszlo Moholy-Nagy of Brian Archer.

Deze op HCI gebaseerde processen hadden een vereenvoudigde kijk op de plaats van ontwerp in softwareprojecten. Wat met name ontbreekt is een expliciete ontdekkingsfase, omdat deze gewoon een ontwerpopdracht accepteert zoals die aan hen wordt gegeven en onmiddellijk doorgaat met het bedenken van een gedetailleerd UX-plan (waarvan werd gedacht dat het universeel was voor het ontwikkelingsproces) en vervolgens de behoeften en eisen van gebruikers analyseert in formatief gebruikersonderzoek, wat resulteert in een concept dat het dichtst in de buurt komt, hoewel het niet zo wordt genoemd. Ontwerpen voor bruikbaarheid is de detailfase in combinatie met evaluatie, die vanaf het begin aan het einde van het proces verschijnt.

Invloed van andere disciplines

Naarmate de HCI-gemeenschap groeide, kwam ze in contact met andere, vergelijkbare vakgebieden zoals architectuur, antropologie en zelfs design. Aspecten van deze andere disciplines begonnen op elkaar in te werken in termen van methoden en technieken en soms zelfs processen. De ontwerpgemeenschap kwam bijvoorbeeld oorspronkelijk met het concept van ontwerprationale, uit het werk van Horst von Rittel. Maar de CHI-gemeenschap maakte zich hier al snel sterk voor en de meest recente werken over design rationale komen meestal uit de CHI-gemeenschap. Het feit dat de helft van de lezers zich nu op het hoofd krabt, bewijst hoe weinig rol design rationale speelt in veel UX-projecten, ondanks het feit dat het een essentieel aspect is.

Veel ontwerpers zoals Karen Holtzblatt (die een zeer succesvol Usability adviesbureau leidde) namen een gepopulariseerde versie van antropologie, pasten vereenvoudigd in situ onderzoek creatief toe en pasten het toe op HCI engineering. Holtzblatts specifieke benadering wordt contextueel ontwerp genoemd. Dit proces ontwikkelde zich ook rond de tijd van de groei van een nieuwe generatie HCI-consultants om softwarebedrijven te helpen die zelf geen ontwerpers in huis hadden. Het ontwerpwerk werd daarom vooraf in het project geladen, het werk werd opgeleverd en meestal waren de consultants er zelden tijdens de ontwikkelingsfase en konden ze de resultaten van hun werk niet zien. Deze versie van Contextual Design hanteerde een formule of kookboekbenadering voor hoe een gebruikersgericht ontwerpproces moest worden uitgevoerd met vereiste stappen en deliverables. Het bevatte ook duidelijk het idee van iteratief ontwerp, waaruit een toenemend bewustzijn van de externe ontwerpgemeenschap bleek. De oorspronkelijke versie (sindsdien zijn er gemoderniseerde versies) van Contextual Design volgde deze stappen:

Dit proces probeert, onafhankelijk van engineering, een proces op gang te brengen om te komen tot een gebruikersgericht ontwerp dat enkel ontworpen is om een benadering te volgen die het product bevraagt vanuit het perspectief van de gebruiker. De fasen zijn beschrijvend en een voorbeeld van een kookboekbenadering die volgens de auteur altijd zou moeten resulteren in een succesvol gebruikersgericht ontwerp.

De eerste 2 stappen komen overeen met het ontdekkingsproces, maar alleen als het gaat om het verkrijgen van gebruikersbehoeften en feedback. Er is geen reframing van het probleem of enig ander belangrijk ontwerpdenken. Dit is nog steeds geworteld in het leveren van ontwerpmiddelen aan ontwikkeling op basis van vastgestelde behoeften en vervolgens het toevoegen van gebruikersinput. Dit is ook niet echt een ontwerpproces, zoals de ontwerpgemeenschap het zou begrijpen. De volgende 2 stappen hebben betrekking op de define fase, maar met voorgeschreven activiteiten, zoals paper prototyping. De define fase zoals ontwerpers die toen begrepen, volgde de praktijken van ontwerptheoretici zoals Donald Schon, waar er veel meer nadruk lag op ontwerpreflectie en conversationeel generatief ontwerpen met belanghebbenden (meestal klanten en anderen, maar niet noodzakelijk de gebruikers). Zoals een grafisch ontwerper, anno 1994, me ooit trots vertelde “we hebben geen gebruikersinput nodig, wie test er nou een brochure op bruikbaarheid?”.

De laatste twee fasen in Contextual Design verschijnen wanneer het ontwerpwerk klaar is en klaar om te worden opgeleverd voor ontwikkeling. Op dat moment werd het visuele ontwerp (dat werd gezien als een apart ongerelateerd ontwerpaspect) onafhankelijk toegevoegd aan het eindproduct.

Dichter bij de gebruiker komen: Ontwerp waarbij het scenario centraal staat

Andere variaties op HCI user-centered design doken op in pogingen om dichter bij de gebruiker te komen. Een van de meest interessante en duurzame benaderingen die opdoken, heette “Scenario Based Design” van Mary Beth Rosson en John Carroll. In deze benadering kwamen eindgebruikersscenario's voort uit gebruikersinterviews die weergaven hoe de gebruikers werken en hun werk opvatten en resulteerden in scenario's van workflow- en taakanalyses die als leidraad dienden voor het ontwerp. Hun oorspronkelijke proces volgde deze structuur:

Net als Holtzblatt heeft ook dit proces geen direct verband met ontwikkeling, omdat na Evaluate ontwikkeling het overneemt. De ontwerpverkenning is ook beperkt tot de scenario's die vervolgens worden vertaald in wireframes.

Usability Engineering

Het proces van Deborah Mayhew was een grote stap in de richting van een meer design-achtig proces (ondanks de zeer engineering-gedreven structuur). Ze introduceerde ook het concept van iteratie in wat ze de Usability Engineering Life Cycle noemde. Die cyclus gebruikte deze stappen:

Het conceptuele model wordt voor het eerst expliciet opgenomen in het ontwerp en in plaats van te kiezen voor opeenvolgende stappen, legt Mayhew's proces de nadruk op de iteratieve aard van wat zij Usability Engineering noemt. Hier wordt het testen ook laat in het proces genoemd, maar het is iteratief met schermontwerpen en sluit nauwer aan bij het detailontwerp in ons ontwerpproces. Mayhew's inspanningen zijn de eerste stappen van hoe HCI en Design naar elkaar toe beginnen te groeien. De ontwerp- en de HCI-gemeenschap begonnen te strijden om hetzelfde gras bij het ontwerpen van software: de een had de superieure processen, de ander de superieure methoden. Toen beide disciplines dit begonnen in te zien, begonnen ze van elkaar te lenen.  Er waren scholen zoals Carnegie Melon University die zowel een ontwerpschool als een aparte afdeling computerwetenschappen hadden, die beide diploma's in UX-design verleenden (hoewel ze toen nog niet zo werden genoemd).

Uiteindelijk werden ontwerpers jaloers op user-centered design en HCI-mensen jaloers op designers en zo ontstond design thinking, een gebied dat tot op de dag van vandaag wordt gedomineerd door niet-ontwerpers die denken als iemand anders dan een ontwerper. En dat brengt ons bij ...

Populaire versimpelingen

Dit is het begin van wat een hoogtepunt had moeten zijn in design, met name de designinstelling in het bedrijfsleven (wat hard nodig is, zelfs tot op de dag van vandaag). In plaats daarvan hebben we nu een situatie waarin het ontwerpproces vaak lippendienst wordt bewezen, maar weinig daadwerkelijke rol speelt in het softwareontwerpproces. Hoe is dat zo gekomen na deze veelbelovende start?

Een belangrijke factor is dat engineering niet het geduld of het begrip heeft van het holistische ontwerpproces en daarom was het idee om de zakelijke kant van software te integreren in het softwareproces. Dit voorspelde veel goeds omdat de ontwerpgemeenschap op dat moment meer op haar gemak was bij het werken met het bedrijfsleven en de HCI-gemeenschap meer op haar gemak was bij het werken met engineering. De bedrijfsstrateeg Roger Martin, toen hoofd van de Rotman School of Design, probeerde design te introduceren als een belangrijk onderdeel van het bedrijfsproces. Hij was niet succesvol, in plaats daarvan begonnen pogingen van niet-ontwerpers om het idee op te pikken, te simplificeren en te vercommercialiseren een trend in UX-design die in wezen design van zijn professionele standaarden ontdeed, omdat de designpraktijk werd gescheiden van de designfundamenten. Dit zette de wilde groei in gang van “we zullen je in een workshop opleiden tot een UX-designprofessional”. En net zoals ze gedoemd waren te mislukken als ze werden gegeven door ontwerpbureaus, waren ze een nog grotere ramp als ze werden gegeven door online bootcamps.

Er werden dappere pogingen gedaan om design in HCI te introduceren, dit waren ontwerptrajecten die waren ontworpen om naast de academische strengheid van HCI ook strengheid op het gebied van design te creëren. Gerrit van der Veer, Wendy Mackay, Boyd de Groot, Marilyn Tremaine, vele anderen en ik probeerden CHI zover te krijgen dat het design serieus nam.

Ondertussen waren er aan de ontwerpkant soortgelijke inspanningen aan de gang. Samen met Elizabeth Dykstra-Erickson (en later Richard Anderson) hebben we contact gezocht met de AIGA, het American Institute of Graphic Artists. Rick Grefe, de toenmalige voorzitter van het instituut, zag het belang in van een gecombineerde inspanning van HCI en Design en sponsorde samen met de ACM/SIGCHI gezamenlijke topontmoetingen, met als hoogtepunt dat de AIGA (Terry Swack en John Zapolski) samen met de ACM/SIGCHI (ikzelf en Richard Anderson) de DUX-conferentieserie presenteerden in 2003 en 2005. Net als CHI strandden deze inspanningen echter nadat veranderingen in leiderschap bij zowel de AIGA als ACM/SIGCHI ertoe leidden dat beide groepen steeds meer op zichzelf gingen wonen en minder relevant werden.

Op dat moment was er een situatie ontstaan waarin niemand op de designwinkel lette. Vooral de HCI-curricula waren in die tijd gestrand. Men vond goede HCI-ontwerpopleidingen verborgen op plaatsen, zoals de School of Library Sciences aan de Universiteit van Michigan en vond ze niet op plaatsen die je zou verwachten: RISD of Parsons, of veel toonaangevende computerwetenschappelijke afdelingen.

In de begindagen was er geen duidelijke UX-specialiteit. Dus vaak begonnen niet-succesvolle ingenieurs of mensen uit andere disciplines de ontwerptaken over te nemen bij veel softwarebedrijven. Het resultaat was dat softwarebedrijven vaak relatief ongetrainde “ontwerpers” hadden die geen ontwerpachtergrond hadden; maar wanneer echte ontwerpers werden ingehuurd, hadden ze niet de senioriteit die deze ongetrainde UX mensen hadden. Toen UX steeds belangrijker werd, stegen de “senior” niet-ontwerpers op naar de top van het UX management met desastreuze gevolgen voor het ontwerpproces. Mensen zonder ontwerpachtergrond werden verantwoordelijk voor het managen van degenen die wel een ontwerpachtergrond hadden. Dingen zoals een ontwerpproces werden geschrapt omdat men ten onrechte dacht dat ze dingen vertraagden. Dit bracht ontwerpers in het defensief en vielen terug op het enige proces dat ze wel zagen: hoe ze het technische beslissers naar de zin konden maken. Tot op de dag van vandaag zijn er mensen zonder verstand van ontwerpprocessen die design leiden in grote bedrijven, en het is geen wonder dat hun teams worden ontslagen en vervangen door commerciële designers.

Dat wil niet zeggen dat ontwerpprocessen volledig dood waren. Individuele teams met een meer visionair leiderschap zetten professionele ontwerpprocessen in en hun product floreerde als een eiland in een zee van software. Er was ook Design Thinking, dat klaarstond om op zijn minst een beginnend gevoel voor design terug te brengen in het maken van software.

Design Thinking zoals het over het algemeen wordt beoefend, is strikt genomen geen ontwerpproces omdat dit nieuwe proces opnieuw werd verpakt om compatibel te zijn met - en dit zal je ongetwijfeld verbazen - bestaande engineering-praktijken. Praktijken die tegen die tijd waren omgezet naar Agile met een nog kleinere eetlust voor ontwerp dan waterval had. En het resultaat is de oversimplificatie en afzwakking van het design thinking proces.

Design Thinking

Since HCI professionals and software engineers were usually not trained in design, designing or design processes, there started the Design Thinking movement which commoditized the process into something simple and sellable. These non-design trained professionals offered a simplified version of the design process, that catered to their simpler understanding of how design works. 

Its utilization was a successful way to introduce design into companies that were new to design. They wanted a simple and easy to understand design method that produced quick results that were an improvement over their processes (that did not use design thinking of any flavor). In this way, design thinking was a good tool to introduce design to new companies who are not ready for a fuller design engagement. For example, you want multiple iterations or ideas? Design thinking processes will give them to you, if they fit on post-it note. Okay, that’s not completely fair, there are many practitioners of design thinking that thoughtfully try to integrate design processes, as we shall see below. But still, a majority of these efforts emphasized a quick and uncomplicated process. These processes were more meant to clarify product thinking than to truly facilitate the critical and systems thinking that a true designer would bring into a software project.

The reader will not be surprised that most of these design thinking processes, like most early HCI process, were meant to be front-loaded into the software engineering process and barely interact with it. Moreover, many companies utilize these design thinking sessions as if it were a substitute, not an introduction to real design thinking. That had the negative effect of this emerging design process being siloed and while useful with fleshing out an existing product idea, it did not have the critical thinking to challenge that initial definition nor the carryover design processes to actually realize the product definition effectively.

Attempts at Design Thinking process codification

The Interaction Design Foundation captures the canonical commoditized design thinking process. The positive step here is the more prescriptive steps of previous HCI processes are getting replaced with more goal-oriented descriptions, that harken back to the design processes discussed earlier.

Dit proces lijkt veelomvattend, maar dat is het niet. Het is ook geen afspiegeling van de manier waarop een ontwerper denkt. In plaats daarvan is het een reeks verkorte en vereenvoudigde ontwerpstappen. Deze stappen zijn niet schaalbaar, bijvoorbeeld een grote en moeilijk te bereiken gebruikerspopulatie stoot dit proces al in het begin af.

Deze reeks stappen is een snel proces dat serieel wordt uitgevoerd. De definitie van de stappen is beperkt. De onderzoeksfase is bijvoorbeeld gericht op empathie (een mantra in design thinking), maar het is een snelle en overgesimplificeerde versie van wat Holtzblatt al behandelt in haar contextueel ontwerp. Van daaruit vloeien de stappen in elkaar over en uiteindelijk is er een prototype dat is geëvalueerd (met meestal voorspelbaar succes). Men kan aanvoeren dat deze formulebenadering van design thinking het eigenlijke doel van design thinking in de war schopt: buiten de gebaande paden treden en naar meerdere perspectieven kijken om een probleemruimte te ontdekken die niet in een gebruikersgerichte wereld leeft, maar eerder in een ecosysteem dat gebruikers, klanten, bedrijven, de markt, de maatschappij, enz. omvat.

"Design Thinking" voor 'Designen' in Agile

De Google Design Sprint beveelt ook fasen aan, maar is vergelijkbaar met andere methoden die variaties zijn op dit thema. Het Google Design Sprint boek legt expliciet uit dat het geen volledige software ontwerpmethode is, maar eerder een ideatietool, vooral geschikt voor start-ups en andere blue-sky ontwerpprojecten. En daarom is er geen aandacht voor daadwerkelijke ontwikkeling omdat het prototype een op zichzelf staand bewijs van concept is.

De Google Sprint methode doet een valide poging om het ontwerpproces te miniaturiseren voor een specifiek beperkt doel. In de eerste fase wordt bijvoorbeeld geprobeerd om de probleemruimte te begrijpen voordat er dingen worden gedaan. Ik hou ook van de integriteit van dit proces in die zin dat het aangeeft waar het goed voor is en dat het slechts een eerste iteratie van een ontwerpproces is, niet het einde ervan. Dit hele sprintproces zou kunnen passen als een activiteit in een breder ontwerpproces. Het feit dat sommige onkritische ontwerpers de design sprint gebruiken in plaats van een ontwerpproces verkort het ontwerpproces en is niet in de geest van waar een design sprint voor bedoeld is.

Het volgende proces is het design thinking-proces van de Stanford Design School, geschreven door Stanford-archeoloog Michael Shanks.

Hun proces is bijna identiek aan dat van de IDF, behalve dat ze in plaats van “Onderzoek” de eerste stap “Inleven” noemen.

Net als het IDF-proces hierboven is het een verkorte en vereenvoudigde reeks ontwerpoefeningen die op zijn minst enige reflectie op de definitie van een product mogelijk maken. En in een omgeving waar er anders geen ontwerpactiviteiten zouden zijn, zal dit proces je op zijn minst enige ontwerpinput geven, wat beter zou kunnen zijn dan geen. Ik zeg ‘zou kunnen’ omdat het in zijn korte methoden iets als ‘compleet’ presenteert terwijl het dat niet is. Bovendien zijn er nog steeds veel professioneel opgeleide ontwerpers die het design thinking hebben opgepakt en gebruiken om op een hoger niveau te reflecteren op het ontwerp, maar die meer kritisch denken en verkennend onderzoek toevoegen aan de design thinking agenda.

De standaardisatie van 4D-ontwerp

Tot slot de klassieke bron van het gestandaardiseerde 4D proces, namelijk het dubbele diamant proces, het meest bekend geworden door de Design Council. Ongetwijfeld zullen velen opmerken dat het dubbele diamant proces een meer algemeen herkenbaar beeld geeft van de ontwerpmethode en het gebruik van de stappen van het 4D ontwerpproces heeft genormaliseerd. Dit proces heeft, zij het vaag, het beste van de ontwerpprocessen met de gebruikersgerichte HCI-processen samengevoegd tot één proces voor het maken van goed ontworpen software.

De double diamond in de Design Council-smaak ziet er als volgt uit:

De dubbele diamant ondersteunt een divergentie- en convergentiegedachte.

Hoewel velen beweren dat de visualisatie oversimplificeert, biedt de dubbele diamant met zijn subtiele gebruik van pijlen een handige manier om in beknopte bewoordingen over design te communiceren, waarbij de rommeligheid van design wordt geïntimideerd terwijl de klant wordt gerustgesteld dat alles uiteindelijk goed zal komen. Op deze manier is de double diamond niet zozeer een alomtegenwoordig ontwerpproces als wel een alomtegenwoordige ontwerpverpakking. En daarin is het zeer flexibel en effectief omdat het eenvoudigweg de taal van het bedrijfsleven lijkt te spreken in de jas van een ontwerper.

Er zijn nog veel meer bronnen en kwesties die een rol hebben gespeeld in ons Tijdloos Schaalbaar Ontwerpproces, maar voor zover ik weet is er geen enkele die de doelen zo beknopt heeft gescheiden van de activiteiten, zodat het ontwerpproces kan worden opgeschaald om de uitdaging van elke omvang aan te gaan, zoals we in de vorige blogposting hebben besproken.

De vraag rijst hoe dit in de praktijk werkt. Hoe kan een ontwerpproces zoals wij voorstellen daadwerkelijk worden geschaald en op welke manieren? Dat is het onderwerp van onze volgende blogpost. Hieronder herhaal ik voorlopig een lijst met referenties die in de vorige vier blogposts zijn gebruikt, waaronder deze. Dit zijn de referenties die mijn ontwerppraktijk en dit ontwerpproces in het bijzonder hebben beïnvloed en gevormd. Daarna volgt een lijst met ontwerpprofessionals die deze aanpak van het ontwerpproces, direct of indirect, hebben helpen vormgeven.

Referenties

• Alexander, C. Notes on the Synthesis of Form, 1964 
• Archer, L. B. (1965). Systematic Method for Designers. The Design Council
• Beyer, H and Holtzblatt, K, Contextual Design: Defining Customer-Centered Systems (Interactive Technologies) Morgan Kaufmann 1997
• Cross, N. (2006). Designerly Ways of Knowing. Springer
• Deborah Mayhew, The Usability Engineering Lifecycle, A Practitioner's Handbook for User Interface Design, Morgan Kaufman, 1999
• Design Council (2012). Double Diamond. The Double Diamond by the Design Council is licensed under a CC BY 4.0 license. https://www.designcouncil.org.uk/our-resources/the-double-diamond
• Design Sprint Methodology, Google Design Spring Website accessed on 5 January 2025 at https://designsprintkit.withgoogle.com/methodology/overview
• Dubberly, H. (2024) “Conversations and models: Secrets to designing great products” https://presentations.dubberly.com/conversations_and_models.pdf
• Dubberly, H. (2025) “How do you design?” https://www.dubberly.com/wp-content/uploads/2008/06/ddo_designprocess.pdf
• Dubberly, H. (2025) “Why we should stop describing design as ‘problem-solving’” from Dubberly Design Office web site, https://www.dubberly.com/articles/why-we-should-stop-describing-design-as-problem-solving.html
• Eisermann, R. “The Double Diamond design process — still fit for purpose?”  from Medium, accessed on 24 December 2024 at https://medium.com/design-council/the-double-diamond-design-process-still-fit-for-purpose-fc619bbd2ad3
• Esther Han, 4 Stages of Design thinking from Harvard Business School Online. Accessed on 3 January 2025 at https://online.hbs.edu/blog/post/stages-of-design-thinking
• Evenson, Shelley, Dubberly, H. “Design as learning—or “knowledge creation” — the SECI model” from ACM interactions, Volume XVIII — January + February 2011
• von Foster, H., World in Spectacular Light, London Review of Books, Vol. 46 No. 23 · 5 December 2024, https://www.lrb.co.uk/the-paper/v46/n23/hal-foster/world-in-spectacular-light. This is a book review of Robin Schuldenfrei’s Objects in Exile: Modern Art and Design across Borders 1930-60
• Google Design Sprint Website (2025) “Design Sprint Methodology.” https://designsprintkit.withgoogle.com/methodology/overview
• Gulliksen, J.; Goransson, B. Usability Design – Integrating user-centered systems design in the software development process. Tutorial at INTERACT 2003, Zurich, Switzerland, 2003
• Holtzblatt, K. (2012). Contextual design. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 19). CRC Press. https://doi.org/10.1201/b11963 
• Horst Rittel, H. “On the Planning Crisis: Systems Analysis of the ‘First and Second Generations,’” 1972
• Interaction Design Foundation . What are UX Design Process Best Practices? https://www.interaction-design.org/literature/topics/ux-design-processes#ux-design-process-faqs
• Interaction Design Foundation (2024) What are UX Design Process Best Practices? https://www.interaction-design.org/literature/topics/ux-design-processes#ux-design-process-faqs 
• Jacobson, Ivar; Booch, Grady; Rumbaugh, James. (1999) The Unified Software Development Process. New Jersey: Addison-Wesley.
• Jones, J. C. (1970). Design Methods: Seeds of Human Futures. Wiley.
• Mayhew, D. J. (2012). Spreadsheet tool for simple cost-benefit analyses of user experience engineering. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 12). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, D. J. (2012). Usability + persuasiveness + graphic design = eCommerce user experience. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 13). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, D. J., & Follansbee, T. J. (2012). User experience requirements analysis within the usability engineering lifecycle. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 9). CRC Press. https://doi.org/10.1201/b11963 
• Mayhew, DJ (1999) The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design, Morgan Kaufman. 
• Moholy-Nagy, L. (1947) Vision in Theobald, P Chicago, 30-32. Realization is what Moholy-Nagy calls ‘Social Biological Synthesis’
• Peart, R. (20127) Why Design is Not Problem Solving + Design Thinking Isn’t Always the Answer from AIGA Eye on Design, January 19th, 2017 https://eyeondesign.aiga.org/why-design-is-not-problem-solving-design-thinking-isnt-always-the-answer/
• Rittel, H. W. J., & Webber, M. M. (1973). “Dilemmas in a General Theory of Planning.” Policy Sciences, 4(2), 155–169
• Rosenberg, D. (2020) UX Magic, Interaction Design Foundation
• Rosson, M. B. and Carroll, J., Usability Engineering: Scenario-Based Development of Human-Computer Interaction Morgan Kaufman, 2002
• Rosson, M. B., & Carroll, J. M. (2012). Scenario-based design. In J. A. Jacko (Ed.), Human-computer interaction handbook (3rd ed., pp. 20). CRC Press. https://doi.org/10.1201/b11963
• Schön, D. (1984) The Reflective Practitioner: How Professionals Think in Acton, Routledge Press, New York 
• Shanks, M. (2022) An Introduction to Design Thinking, Process Guide, from Stanford Business School https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf
• Simon, H. A. (1969). The Sciences of the Artificial. Cambridge, MA: MIT Press
• The 6 Steps of the Design Thinking Process, IDEO Website accessed on 5 January 2025 at https://www.ideou.com/blogs/inspiration/design-thinking-process?srsltid=AfmBOop-CfwQVih5_qooOG1svrgnByGUAF4EZvpaz9JRwTlNlP2E6-tb
• Winograd, T., Bringing Design to Software, 1996

Dankbetuigingen

Ik wil graag een kort lijstje maken van de professionele ontwerpers met wie ik het voorrecht heb gehad om samen te werken en die mij hebben beïnvloed en geïnspireerd in mijn ontwerpwerk:

Michael Arent, Hugh Dubberly, David Siegel, Iwan Cuijpers, Richard Anderson, Susan Dray, Daniel Rosenberg, Elizabeth Dykstra-Erickson, David Zeidman, Ruurd Priester, Nico ten Hoor, Gert van der Meulen, Jose Arcellana, Patrick Larvie, Irene Au, Nico MacDonald, Marilyn Tremaine, Wendy Mackay, Robert Jacobs en meest recent Anna Wildeman en Laura Chavarria.