Deel 1: Mythes ontkrachten en op één lijn komen
“Onze processen bepalen de kwaliteit van onze producten.” - Hugh Dubberly
Hugh Dubberly, ervaren ontwerpplanner en professor, wijst op de noodzaak om zowel de procesuitvoering als het proces zelf te bestuderen en te verbeteren. Dit is inderdaad een van de essentiële vaardigheden van de ontwerper: hoe het proces te om te zetten van strategie tot een professionele praktijk.
Een waarheid als een koe zou moeten zijn: “Elke ontwerpprofessional die zijn proces niet kan verwoorden en ernaar kan handelen, is geen volledig professionele ontwerper.” Maar die uitspraak is om twee redenen niet eerlijk tegenover mijn collega-ontwerpers. Ten eerste staan we onder grote druk om pragmatisch en onprofessioneel te zijn van de mensen die ons inhuren (of dat nu een externe klant is of een ontwerpgroep binnen een groter bedrijf). Ten tweede, als we het over het ontwerpproces hebben, kunnen we het over twee verschillende processen hebben die door elkaar gehaald worden:
- Het overkoepelende ontwerpproces voor een specifiek project, of wat ik het projectontwerpproces noem. Het doel is om een tijdgebonden en vertrouwenwekkend zakelijk voorstel te doen.
- Het design doing proces (jammer dat de term “Design Thinking” is gekaapt voor iets anders) dat de iteratieve dynamiek van hoe een ontwerper werkt probeert te vangen.
Elke discussie over het ontwerpproces gaat gepaard met misverstanden, dus deze eerste post is bedoeld om ons allemaal op één lijn te krijgen over wat het betekent om een ontwerpproces te hebben.
Wat een ontwerpproces niet is
Veel ontwerpers met wie ik heb gesproken zijn vaak bang dat een proces hun vrijheid beperkt en hun creativiteit inperkt. Zoals we zullen zien, is de realiteit het tegenovergestelde: een goed ontwerpproces ontketent je creativiteit door mogelijkheden te openen, niet door ze af te sluiten. Door de ontwerper te confronteren met de werkelijke diepgang van de ontwerpopgave, dwingt een goed proces de ontwerper en zijn stakeholders bovendien om buiten de gebaande paden te denken. Zoals ik in volgende posts zal laten zien, geeft een goed ontwerpproces de ontwerper de professionele discipline om de echte magie van ontwerpen te ontsluiten: om problemen zowel duurzaam als innovatief op te lossen naar het beste van je kunnen.
Het is ook leerzaam om op te merken wat een ontwerpproces niet is. Hoe graag sommigen het ook zouden willen, een goed ontwerpproces is geen kookboek of recept voor succes. Het suggereert misschien een bepaalde striktheid en discipline, maar het is aan de ontwerper om die uitdaging aan te gaan en een succesvolle manier te bedenken om dat te doen. Het proces ontwerpt op geen enkele manier voor jou en vertelt je ook niet welke ontwerptools, welke methoden of welke activiteiten je moet gebruiken. Die zijn allemaal context-specifiek. Dus in het kort: een goed ontwerpproces begeleidt ontwerpers en stelt hen in staat om de beste oplossing te kiezen voor de context waarin zij zich bevinden; maar zo'n proces kan, zal en zal nooit voor ontwerpers ontwerpen of hen vertellen hoe zij moeten ontwerpen. Een proces zal een ontwerpers zeker vertellen wat (doelen) en wanneer (fasen) zij het moeten doen, maar niet hoe (welke technieken of methoden) zij het moeten doen.
Ontwerpproces ≠ Agile
Bovendien bestaat er ook een misverstand over waar het ontwerpproces past in het totale softwareproces. Vooral het gelijkstellen van het ontwerpproces aan Software Engineering Agile methoden is een vergissing. Nog verwarrender is dat sommige bedrijven agile benaderingen inpassen in hun bedrijfsvoering. Want voor zulke bedrijven lijkt het alsof alles volgens een agile methode verloopt, maar deze schijn bedriegt, en ze zijn vooral relevant bij het begrijpen van de juiste rol van ontwerp in de bedrijfs- of organisatorische levenscyclus.
Waar wordt het ontwerpproces gebruikt?
Zoals de geschiedenis van user-centered design aangeeft (meer hierover in Post 3) wordt ten onrechte aangenomen dat het software engineering proces het software creatie proces is. Het maken van software bestaat uit vele subprocessen die eigendom zijn van verschillende softwaremakers. Het software creatieproces is wat ontwerpen zo complex, multidisciplinair en multicultureel maakt. Er bestaat echter nog steeds een tendens om het Agile ontwikkelproces gelijk te stellen aan het software creatie proces.
Laten we eerst eens kijken naar het Agile-proces en hoe dit normaal gesproken in wisselwerking staat met design. Veel ontwerpteams, bureaus en consultants hebben vaak agile-gebaseerde ontwerpaanbiedingen. Maar deze aanbiedingen richten zich meestal op het maken van sprint-assets en het stiekem opnemen van ontwerpprioritering in het Sprint Backlog Management om het bouwen van bepaalde UI's uit te stellen zodat er wat minimaal onderzoek kan worden gedaan voordat de ontwikkeling plaatsvindt.
Agile software development proces
Bij nadere bestudering van het Agile proces hierboven, wordt er niet veel melding gemaakt van ontwerp of ontwerp processtappen of zelfs activiteiten. Zoals hierboven vermeld, vinden veel ontwerpers meestal manieren om zich aan te passen aan agile ontwikkeling, zoals te zien is in het gele gedeelte van de backlog management meetings waar sommige ontwerp-onderhandelingen kunnen plaatsvinden. Dat is echter niet bepaald een ontwerp-vriendelijk proces, laat staan een goede manier om ontwerp "on the fly" met het ontwikkelproces te oefenen.
Wanneer ontwerp geforceerd wordt ingepast in Agile, wordt het vaak aan de voorkant geplaatst alsof de enige ontwerp-activiteiten aan het begin van de ontwikkeling plaatsvinden. Managers zullen vaak misbruik maken van processen zoals (Google Ventures') Design Sprints omdat het lijkt te vertellen wat ontwikkelaars willen horen: dat ontwerpen kan worden teruggebracht tot 3-5 dagen inspanning. Ze zullen “design sprints” aanprijzen alsof een ontwerp vooraf kan worden gedaan, terwijl de realiteit is dat wanneer zo'n design sprint is afgerond, het ontwerp de volgende dag is verouderd omdat er tijdens de ontwikkeling nieuwe informatie is opgedaan.
Zoals we in onze volgende post zullen zien, vindt ontwerp plaats tijdens zowel het software development proces als het software-creatie-proces.
Er zijn nog twee andere nadelige effecten van ontwerpen tijdens Agile: Ten eerste, hoe meer een ontwikkeling vordert, hoe meer "technical debt" het begint op te bouwen die ook gerelateerd is aan "design debt" omdat ontwerpen onvolmaakt of slechts gedeeltelijk worden geïmplementeerd. Ten tweede komt design bijna nergens voor in Agile manifesten en in de versies waar het wel voorkomt wordt vaak verwezen naar software engineering design en niet naar UX design.
Tot slot, zoals we hieronder zien, is Agile slechts één van de vele processen die betrokken zijn bij het software creatie proces. In die afbeelding zien we dat er veel processen zijn die plaatsvinden vóór Agile in het software creatie proces. Rechts van elke stap staan gerelateerde ontwerp-activiteiten. Als we het Agile proces in het bredere plaatje van de software creatie processen plaatsen, zien we dat Agile erg laat begint. Laten we eerst eens kijken naar het gemiddelde Agile software development proces.
Zoals je kunt zien bij het Marketingproces aan de rechterkant, zijn er niet alleen veel specifiek ontwerp-gerelateerde stappen, maar zijn sommige ook herkenbaarder ontwerp-georiënteerd dan de stappen in Agile stappen, waar de ontwerper wel betrokken is, maar nooit echt een stap initieert. Bijvoorbeeld, het werk met Journey Mapping vindt plaats in deze marketingstap, wat betekent dat als design pas tijdens Agile komt, deze map al bestond zonder de nodige input van design, omdat design te laat kwam.
Het hele proces van software development heeft een veelheid aan stappen die voorafgaan aan agile, waarbij ontwerp een sleutelrol speelt, zoals te zien is in het diagram hieronder dat het product-creatieproces voorstelt, waarvan agile deel uitmaakt.
In het bovenstaande diagram zijn de ontwerp-stappen in geel weergegeven, zodat je kunt zien hoeveel ontwerp-stappen de ontwerper volledig zou missen als hij of zij alleen in Agile zou werken.
Dit is ook de reden waarom veel ontwerpers die op deze manier werken, klagen dat alle belangrijke beslissingen al genomen zijn.
Daarom zit de ontwerper opgescheept met een suboptimale set van omstandigheden waarin hij kan ontwerpen; omdat het ontwerpproces werd verstikt voordat het de input kon krijgen en geven die het nodig heeft om echt succesvol te zijn.
De bovenstaande afbeelding toont een softwareproces van een volwassen organisatie waar de product-planningsfase vaak een heel kalenderjaar duurt. Dit proces schaalt zich echter, net als het ontwerpproces zelf, naar de omvang van de uitdaging, de volwassenheid van de organisatie en de volwassenheid van de software. Sommige softwareprocessen kunnen zelfs op agile lijken omdat ze soms gelijktijdig worden uitgevoerd in sprintachtige schema's, ook al zijn hun activiteiten en managementstijlen enorm verschillend.
Een ontwerpproces dat goed wordt uitgevoerd, zoals we zullen uitleggen, is een van de weinige processen die alle andere processen voor het maken van software met elkaar verbindt en ervoor zorgt dat ze allemaal het ontwerp informeren dat de leidende concepten zullen zijn bij de ontwikkeling van software. Als zodanig is het ontwerpproces ook een coördinerend proces tussen vele disciplines, niet alleen engineering. Aan de andere kant, als het ontwerpproces begint met engineering, dan is het niet alleen te laat voor het ontwerp om zijn volledige positieve impact op het project te hebben, het is ook te laat voor een ontwerper om een bevredigende professionele ervaring op te doen. Het software creatieproces, niet Agile, is de beste manier om de plaats van het ontwerpproces te begrijpen, net zoals het beter is om te denken aan stakeholder-centrisch ontwerpen in plaats van alleen gebruikers-centrisch ontwerpen als drijvende kracht achter dat proces.
Of korter gezegd: tegen de tijd dat Agile klaar is, is veel van het belangrijke ontwerpwerk al gedaan.
Om ervoor te zorgen dat een ontwerper optimaal kan werken en dat een organisatie optimaal kan profiteren van de voordelen van een goed ontwerp, stellen we in het volgende artikel het schaalbare ontwerpproces voor.
Dit ontwerpproces maakt gebruik van de generaliseerbare stappen in elk ontwerpproces. Dit universele tijdloze ontwerpproces maakt gebruik van de hardleerse ontwerpprocessen die niet alleen zijn geworteld in het maken van softwareproducten, maar ook teruggaan tot het begin van de 20e eeuw (hoewel sommige wortels zelfs teruggaan tot de renaissance). Net als een goed ethisch ontwerpproduct, om Horst von Rittel te parafraseren, vergroot het proces het aantal positieve keuzes voor alle belanghebbenden. Het doet dat door een tijdloze schaalbare structuur te bouwen die altijd de beste ontwerpen heeft voortgebracht die een ontwerper kan leveren. Net als een goed ontwerp dwingt het proces je om moeilijke keuzes te maken en moeilijke vragen te stellen. Het dwingt een zorgvuldige aanpak af zodat het ontwerpproces complex, professioneel en natuurlijk plezierig is.
Wat dit proces inhoudt, zal het onderwerp zijn van mijn volgende artikel dat in de komende weken zal verschijnen.
Als je op de hoogte wilt blijven wanneer het volgende artikel wordt gepubliceerd, vul dan het onderstaande formulier in en stuur het ons toe.
