Het tijdloze schaalbare ontwerpproces deel 3

Deel 3: Fasen van het ontwerpproces uitgelegd

Recap

Ik opende de serie met een artikel met een begrip van wat ik bedoel met een schaalbaar proces. Schaalbare processen scheiden de doelen van een ontwerpfase van de gebruikte methoden en/of technieken. Omdat er niet alleen talloze ontwerpmethoden en -technieken zijn, zijn er ook eindeloos veel smaken. Elk heeft zijn plaats gegeven een bepaalde context en de betrokken ontwerper. Veel ontwerpprocessen in het verleden pleitten vaak voor een bepaalde ontwerpmethode. Karen Holtzblatt's Contextual Inquiry bijvoorbeeld, vereiste oorspronkelijk een zeer lange onderzoeksfase die niet veel ontwerpers konden uitvoeren. De oorspronkelijke versie van het proces werd dan ook zelden gebruikt: het was te inflexibel om op de meeste projecten toe te passen.

Als alternatief gingen sommige ontwerpprocessen het tegenovergestelde uiterste en werden zo vaag dat ze weinig praktische waarde hadden, zoals de "double diamond".

Echte duurzaamheid in een ontwerpproces dwingt een minimumstandaard van professionaliteit af en geeft de ontwerper of designmanager tegelijkertijd de richtlijnen om de creativiteit van het ontwerpteam op een effectieve manier te ontketenen.

Schaalbaarheid in een effectief ontwerpproces bestaat uit drie elementen:

1. Tijdloze ontwerpfasen die de ontwerpinspanning volledig afdekken
2. Universele doelen voor elke ontwerpfase (universeel betekent dat ze elk essentieel doel van een ontwerpproject dekken)
3. Deliverables die de context vastleggen die het doel ondersteunen.

Het vorige blogartikel behandelde de nummers 1 en 2; dus laten we, voordat we ingaan op de details van het proces, even de tijd nemen om de rol van deliverables in het ontwerpproces te begrijpen.

 

Deliverables

De deliverables voor het ontwerpproces worden hier voorgesteld, maar niet voorgeschreven. Eén van de deliverables zou bijvoorbeeld een document met vereisten kunnen zijn. Het is echt gevaarlijk en onprofessioneel om verder te gaan met een ontwerp zonder te begrijpen wat het moet doen, ook wel requirements genoemd.  Maar er zijn veel manieren om requirements te documenteren, van een database tot een conceptuele kaart tot een prototype. De vorm is onbelangrijk, het belangrijkste is dat alle belanghebbenden met beslissingsbevoegdheid het eens zijn over de vorm en inhoud van de deliverable(s).

Een belangrijke opmerking: het is van vitaal belang voor de duurzaamheid van het proces dat een proces geen deliverable omwille van zichzelf nodig heeft. Elke deliverable moet ook een operationeel onderdeel zijn van het ontwerpproces, dus het is in wezen zelf-documenterend. Ontwerpprojecten zijn meestal erg intensief en hebben weinig tijd voor activiteiten van puur administratieve aard.

De deliverables helpen om hiaten in het project te ontdekken voordat het project begint. Elke deliverable moet bijvoorbeeld aan een doel gekoppeld zijn. En elke deliverable moet aan minstens één methode/activiteit gekoppeld zijn. Dus als het goed gepland is, zijn alle doelen geassocieerd met deliverables en hoe die deliverables gemaakt worden (activiteiten).

Daarom zal ik in dit artikel deliverables voorstellen, maar deze zijn bedoeld ter illustratie, omdat veel ervaren ontwerpers alternatieve deliverables en/of formats zullen hebben om dezelfde doelen te bereiken.

 

Gedetailleerde uitleg van de details van het projectproces

Zoals we in een latere blogpost over het beheer van het ontwerpproces zullen zien, zijn de fasen opdeelbaar in meer stappen, waarbij het de uitdaging is om een project op te delen in stappen die zinvol zijn voor de omvang van het project. Het is echter niet aan te raden om de fasen in te korten tot minder dan de vier die hieronder worden gegeven, omdat elk van deze fasen een ontwerpmijlpaal vertegenwoordigt die onafhankelijk is van een ontwerpproject en gegrond is in ontwerppraktijken en -theorieën (deze praktijken en theorieën die dit een tijdloos proces maken, komen aan bod in de volgende blogposts). Voor deze post richten we ons alleen op de vier fasen en hun details. Voor elke stap gebruiken we de volgende structuur:

1. Definitie en uitleg
2. De universele doelen
3. Voorbeeldresultaten die de doelen ondersteunen
4. Optioneel enkele voorbeeldactiviteiten die de deliverables ondersteunen

 

Het projectontwerp Projectproces Stappen

Dit zijn de stappen in het ontwerpproces:

De te beschrijven stappen van het proces zijn:

• Toestand 1 - de status quo voordat het ontwerp wordt gestart
• Ontdekken - de uitdaging begrijpen
• Concept - de conceptuele oplossing bepalen
• Detail - de oplossingsrichting detailleren in een concreet ontwerp
• Opleveren - het ontwerp implementeren in samenwerking met engineering
• Toestand 2 - de gewenste eindtoestand van het ontwerp.

Elke stap zal achtereenvolgens worden onderzocht, maar we moeten de iteratieve aard van ontwerpen in gedachten houden.  Het is goed om te herhalen dat elke stap ook nieuwe informatie aan het licht kan brengen die niet beschikbaar was in de vorige stap. Bevindingen tijdens het conceptueel ontwerp kunnen bijvoorbeeld de probleemruimte informeren; gedetailleerde ontwerpevaluatie kan een iteratie van het concept uitlokken, enz. Volgorde betekent dus niet waterval, maar iteratieve oplevering.

 

Toestand 1: De status-quo

De eerste plek in onze proces roadmap is een pre-conditie, of de status quo, aan het begin van het ontwerpproces.

Toestand 1: dit is de toestand voordat het ontwerp begint, maar het is niet noodzakelijkerwijs het begin van een softwareproject. Vaker is dit de toestand van de software op het moment dat het ontwerp begint.

Zelfs aan het begin van een softwareproject komt het vaak voor dat toestand 1 geen schone lei is. Er zijn meestal al wat oude beslissingen, beperkte middelen en andere beperkingen waarbinnen het proces moet werken.

 

Doelen

Het hoofddoel van toestand 1 is het begrijpen van de huidige status van het softwareproject. Namelijk:

• Bekijk en onderzoek de bestaande softwareoplossing, als die er is.
• Begrijp de activiteiten die al aan de gang zijn: waarom zijn ze gedaan en op welk bewijs zijn ze gebaseerd, enz.

Als we de huidige staat bestuderen, kunnen we ontdekken dat er in deze oorspronkelijke staat misschien al een ontwerp bestaat. Werk dat het waard is om van te leren en misschien opnieuw te gebruiken.

Er zijn meestal veel waardevolle gegevens te halen uit deze oorspronkelijke status-quo, zodat dit werk een fundament of ten minste een basis vormt waarop het ontwerp wordt gebouwd. Bijgevolg informeert deze toestand 1 het daaropvolgende ontwerpproces.

 

Fase 1: Ontdekken

In Discover proberen het ontwerpteam en de belanghebbenden de volledige reikwijdte van de ontwerpuitdaging te begrijpen. Hiertoe legt de ontwerper de ontwerpuitdaging vast vanuit het perspectief van de klant. Dit draagt bij aan het begrijpen van de scope van het ontwerpproject. De scope is echter niet afhankelijk van de zaken die de opdrachtgever heeft overwogen. Het is ook de verantwoordelijkheid van de ontwerper om de volledige uitdaging te begrijpen, inclusief zaken waar de klant geen rekening mee heeft gehouden, om zo tot een zo volledig en systematisch mogelijk begrip van de ontwerpuitdaging te komen.

De fase begint met een afwijkende gedragslijn waarbij een goede ontwerper belanghebbenden met kritisch denkvermogen uitdaagt om volledig te begrijpen wat de problemen zijn en welke problemen misschien ontbreken. Vaak wordt de uitdaging iteratief opnieuw gekaderd in nieuwere termen met een dieper begrip en het besef dat lang gekoesterde overtuigingen slechts aannames zijn.

De Discover-fase wordt afgesloten met een convergentietraject waarbij de stakeholders, door zowel kritisch als systeemontwerpdenken toe te passen, zich concentreren op een definitie van de oplossing die de rest van het project zal bepalen. Ontwerpers faciliteren vaak andere belanghebbenden in deze processtap door middel van brainstormen, ideëren en verschillende visualisaties om iedereen op één lijn te krijgen.

 

Basisdoelen

• Staat 1 opnemen
  De ontwerpuitdaging/het probleem definiëren zoals de softwaremakers het op dit moment zien.
• Het probleem in een nieuw kader plaatsen
  Iteratief herkaderen van het probleem vanuit meerdere perspectieven om een meer holistisch en systematisch begrip van de ontwerpuitdaging te krijgen. Om dit begrip te vergemakkelijken, herkadert de ontwerper de ontwerpuitdaging. Reframen is iteratief en vindt plaats gedurende het ontwerpproces bij de meeste reflectieactiviteiten in het ontwerpproces. Maar hier, in de Definitiefase, heeft het verschuiven van perspectieven, het gezamenlijk herdefiniëren van het probleem en het vergroten van de scope het meest radicale effect op het project. In deze fase is bijna alles nog mogelijk. Na het herdefiniëren van de problemen wordt er een definitieve scope van het probleem getrokken, waarin de beperkingen worden gedefinieerd waarbinnen een ontwerp zal opereren.
• Verkennend bewijs definiëren
  Doelen vaststellen voor verkennend onderzoek
• Verkennend onderzoek uitvoeren
  Bepaal en bevestig de probleemruimte door deze eerst zo groot mogelijk te maken en vervolgens te verkleinen om een basis te leggen voor de reikwijdte van een project.
• Definieer het formaat van de oplossing
  Door middel van verschillende systeemdenkoefeningen en het verzamelen van co-creatie van schetsen en concepten met belanghebbenden, tot overeenstemming komen over een oplossingsrichting.

 

Basic Deliverables

Project requirements: high level values, metrics en requirements waaraan de oplossing moet voldoen om als een succes te worden beschouwd: dit zal ook bepalen wanneer het ontwerp klaar is.

Probleemstelling: de beknopte beschrijving van de problemen die moeten worden aangepakt en de omstandigheden die moeten worden verbeterd. en het identificeren van de inherente barrières die een oplossing in de weg staan en die het project moet aanpakken. Een probleemstelling omvat: ten eerste, een beschrijving van de huidige situatie (dat is de situatie die de aanleiding vormt voor het ontwerpproject.); ten tweede, een beschrijving van de pijnpunten of problemen; en ten derde, een uitleg wie er getroffen wordt en hoe.

Projectdoelen: de definitie van de oplossing en de metrieken die bepalen of het zal slagen voor de softwaremakers. Dit kan ontwerprichtlijnen en -principes omvatten.

Modellen van de scope van de uitdaging: visualisaties die de volledige oplossingsruimte en het onderliggende systeem van de oplossing weergeven, die worden gebruikt om de ontwerpuitdaging te informeren.

 

Voorbeeldactiviteiten

Enkele voorbeelden van activiteiten zijn:

• Project kick off met alle belangrijke stakeholders die gebruikt kan worden om toestand 1 vast te leggen.
• Brainstorm-/ideationworkshops om design thinking te gebruiken om de probleemruimte te verkennen.
• Klant- en cliëntinterviews om inzicht te krijgen in andere problemen waar de klant zich mogelijk niet bewust van is. De klant kan zich bijvoorbeeld niet bewust zijn van een systematisch of structureel probleem dat ze intern hebben en dat hen verhindert om de ontwerpuitdaging effectief aan te pakken.

 

Fase 2: Concept

De conceptfase begint met formatief onderzoek als vervolg op het verkennend onderzoek in de vorige fase. Dit omvat ook een conceptueel model of conceptkaart van de mogelijke oplossing. Dit model of deze kaart dient dan als referentie om meerdere concepten van de mogelijke oplossing te creëren. Vervolgens worden deze meervoudige concepten (5-10 zijn gebruikelijk) gesynthetiseerd door middel van iteratief ontwerp in combinatie met formatief-evaluatief onderzoek. Tot slot worden deze meerdere concepten samengevoegd tot een enkel conceptueel model dat richting geeft aan de creatie en details van het ontwerp in de volgende stap.

 

Doelen

Conceptueel ontwerp - het conceptuele model en de ontwerpbenadering die gevolgd zullen worden voor de rest van het project.

Formatief onderzoek - informeren over systeemworkflow en conceptuele richting (tegen het einde van de fase omvat het onderzoek ook evaluatieve aspecten om de effectiviteit van de concepten te beoordelen).

Oplossingsdefinitie - in deze fase wordt het antwoord op het ontwerpprobleem bepaald. Welk type oplossing of pakket van oplossingen wordt bepaald en is klaar voor een conceptueel ontwerp.

 

Deliverables

Deze fase begint met een divergerende stap, waaronder formatief onderzoek. Formatief onderzoek is gericht op een dieper begrip van het probleem op een manier die helpt bij het vinden van een oplossing. Er worden vaak verschillende modellen en visualisaties gebruikt; twee veel voorkomende groepen zijn concept maps en stroomdiagrammen.

Conceptmodellen en/of -kaarten - verschillende abstracte voorstellingen die mensen helpen om de reikwijdte van de oplossing te begrijpen, onafhankelijk van een concreet ontwerp. Het zijn manieren om mensen uit verschillende disciplines en domeinen op één lijn te krijgen over wat het ontwerp zal aanpakken. Een veelgebruikt bruikbaar conceptueel model is dat wat Daniel Rosenberg beschrijft in zijn UX Magic boek, het object-actie model. Hierin worden alle objecten voor een bepaald systeem gedefinieerd en worden hun relaties en acties weergegeven om een overzicht te geven van de gegevens en de interacties in één oogopslag. Een ander uitstekend conceptueel model zijn de concept maps zoals beschreven door Novak en Gowin (https://cmap.ihmc.us/). Deze site biedt zelfs gratis software aan (die er misschien verouderd uitziet, maar toch gemakkelijk concept maps maakt).

Stroomdiagrammen daarentegen proberen zich voor te stellen hoe je de abstracte concept map toepast op een oplossing en wat dat inhoudt. Modellen zoals:

• Journey maps
• Taakanalyse
• Andere stroomdiagrammen

helpen ontwerpers om deze concepten te synthetiseren. Dit soort deliverables hebben als doel om stakeholders een gemeenschappelijk begrip te geven van een mogelijke oplossing.

Conceptuele ontwerpen - meerdere concepten met begeleidende documentatie en vervolgens het gedetailleerde samengestelde concept dat zal worden gebruikt voor de ontwerpoplossing.

Low fidelity prototypes - low fidelity prototypes, storyboards of schetsen die dienen als visualisatie van de concepten die tijdens het hele proces worden gepresenteerd.

Probleemafbakening - de probleemstelling omgezet in een algemene oplossingsdefinitie (een product, een dienst, een systeem van producten en diensten, etc.)

Requirements document - eisen geanalyseerd op basis van onderzoek en ontwerp waarin de behoeften van gebruikers, technische beperkingen en behoeften van andere belanghebbenden zijn opgenomen.

 

Stap 3: Detail

De detailfase is de fase waarin het ontwerpteam en de belanghebbenden het conceptuele ontwerp omzetten in een concreet ontwerp. Het onderzoek wordt meer evaluatief, maar er zijn nog steeds formatieve details die moeten worden uitgewerkt. Ook wordt in deze fase de coördinatie met ontwikkelingsbronnen essentieel voor het succes van het ontwerp.

De gedetailleerde ontwerpfase begint met het uitwerken van het abstracte ontwerp in verschillende gedetailleerde ontwerpen. Deze ontwerpen worden geïtereerd totdat ze gevalideerd zijn door evaluatief onderzoek. Deze gevalideerde ontwerpen worden vertaald naar ontwerprichtlijnen en -principes, die als leidraad dienen voor de volgende gedetailleerde ontwerpen. Het evaluatief onderzoek helpt niet alleen bij het valideren van ontwerpen, maar ook bij het verder detailleren van eisen.

De gedetailleerde ontwerpstap eindigt in een verdere convergentie als de verschillende uitgewerkte schermen worden uitgewerkt in interactiepatronen, UX-conventies, kleuren, typografie en andere gedetailleerde ontwerpelementen. In deze stap wordt ook documentatie opgebouwd die softwareontwikkelaars kunnen gebruiken bij het maken van de software op basis van het ontwerp.

 

Doelen

Detailontwerp - Vertaling van concept naar een stabiele ontwerprichting

Ontwerpdocumentatie - de manier waarop het ontwerp wordt gecommuniceerd naar de softwareontwikkelaars (in samenwerking met de ontwikkelaars, soms is het zo simpel als een interactief prototype, maar complexere software kan meer direct mentorschap of documentatie vereisen.

Evaluatief onderzoek - onderzoek waarbij gebruik wordt gemaakt van vastgestelde maatstaven om bewijs te verzamelen van wat wel of niet werkt in het gedetailleerde ontwerp.

 

Deliverables

High fidelity prototypes - Gedetailleerde wireframe-ontwerpen die pixel-perfect benaderen. Als er geen visueel element is opgenomen (bijv. een steminteractie of geautomatiseerde interactie), dan kan het wireframe de vorm hebben van een logische stroom of andere systeemprocesdiagrammen.

Bewijs uit onderzoek - Bewijs uit gebruikersonderzoek en metrische prestaties met analyse ter ondersteuning van de implementatie of om te wijzen op verdere verfijningen van het ontwerp.

Stijlgids of Design System - de ontwerpdocumentatie die specifiek is voor de behoeften van Ontwerp (voor het maken van andere ontwerpen) en Engineering (voor het implementeren van ontwerpen) en die ook wordt gebruikt voor het vastleggen van ontwerprichtlijnen en andere ontwerprationalen.

Bijgewerkte requirements - Laatste grote toevoegingen van gebruikersvereisten (meestal extra details van bestaande vereisten) evenals een controle of alle eerdere vereisten zijn geïmplementeerd of ongeldig zijn gemaakt.

 

Stap 4: Leveren

De Deliver-fase is de fase waarnaar in het begin vaak wordt verwezen als de “Devil is in the details”-fase; vanwege alle onverwachte lastige problemen die zich voordoen wanneer ontwikkelaars het ideale ontwerp proberen te implementeren in een technische realiteit. Deze problemen zijn moeilijk omdat naarmate je meer ontwerpbeslissingen hebt genomen je vrijheidsmarge beperkter wordt om een conceptueel bevredigende oplossing te maken voor nieuwe problemen die opduiken. Maar aan het einde van deze fase, als je die lastige problemen hebt opgelost in overeenstemming met je concept, wordt de fase “God is in the details” genoemd omdat de elegante en overtuigende gebruikerservaring die je in Concept voor ogen had hier eindelijk vorm krijgt.

Coördinatie en samenwerking met ontwikkeling staan centraal in deze fase. De fase begint met ontwerp en onderzoek, in nauwe samenwerking met ontwikkeling, om elegante oplossingen te bedenken en het ontwerp en het ontwerpsysteem aan te passen aan de nieuwe realiteit.  Design thinking-sessies met engineering kunnen ook helpen bij het bedenken van oplossingen voor ontwerpproblemen die een technische oorzaak hebben.

Deze fase eindigt op een afgesproken punt in het ontwikkelingsproces, meestal een MVP (minimal viable product) of een ander doel (bijv. bepaalde meetwaarden zijn behaald) of beperking (bijv. geen budget meer) is behaald.

Onderzoek is in deze fase vooral bedoeld om voorgestelde oplossingen te evalueren en nieuwe oplossingen te helpen onderbouwen. Op een bepaald moment in de implementatie stabiliseert het ontwerp en heeft de ontwikkeling minder hulp nodig van het ontwerp. Op dat moment is het meestal tijd voor het ontwerp om door te gaan naar het volgende project, maar nog steeds beschikbaar te zijn voor periodieke mentoring of beoordeling.

 

Doelen

Bereiken van ontwerpdoelen/metrics - Coördinatie met alle softwaremakers zodat een punt wordt bereikt waarop de ontwerpdoelen zijn bereikt of waarop het ontwerp kan worden overgedragen aan anderen voor afwerking.

Fit en afwerking voor het ontwerp - de onverwachte herzieningen en fijne details worden iteratief uitgewerkt met de ontwikkeling

 

Deliverables

Design assets - leveren van UI-elementen en advies dat engineering nodig heeft om ontwerpen te implementeren

Metrics en bewijs bijhouden - ervoor zorgen dat revisies van het ontwerp het ontwerp niet uit koers brengen.

Ontwerpdocumentatie bijwerken - ontwerpdocumentatie bijwerken op basis van de ontwikkeling.

 

Toestand 2

Na fase 4 komen we bij toestand 2. In de goede oude tijd was toestand 2 een voorspelbare doelgerichte eindtoestand van het afleveren van een eindproduct. De overwinning werd uitgeroepen, een releaseparty werd gehouden en de teams gingen verder met hun volgende technologische strijd. Nu is de meeste moderne ontwikkeling meer organisch en amorf. Niet alleen de snelheid van agile, maar ook de ondersteuning van continue verbeteringen, of beter gezegd continue releases en andere snelle reacties op technische en marktbehoeften. Dit houdt een zeer toegewijde inspanning in om de software levend en actueel te houden. Het ontwerp eindigt tegenwoordig als de afgesproken metrics of doelen zijn gehaald, of als de middelen op zijn, of als andere prioriteiten het overnemen.

Hiermee is de discussie over de details van de stappen van het schaalbare ontwerpproces afgerond. Wat dit proces schaalbaar maakt, is de nadruk op de doelen van de fase en niet op de activiteiten of methoden die afhankelijk zouden zijn van talrijke contextuele situaties. Door zich te concentreren op de doelen is de ontwerper vrij om zijn project te ontwerpen en zich te richten op het opnemen van activiteiten en op te leveren producten die voldoen aan de tijdloze doelen van de projectstap. Dat dekt het schaalbare aspect van het ontwerpproces. In een volgende post zullen we het management van het ontwerpproces bespreken of liever nog in actie zien met een casestudy. Maar onze volgende blogpost gaat over de tijdloosheid van het project. Het zal niemand verbazen als ik zeg dat dit proces niet alleen gebaseerd is op mijn eigen meer dan 30-jarige carrière in design, maar ook op bijna een eeuw designgeschiedenis, collectieve designervaring, designonderwijs en -theorie.

 

In de volgende blogpost krijg je een kijkje in die bronnen. Je zult zien dat dit ontwerpproces is gebaseerd op solide praktijken en bewezen ontwerptheorieën.