Deel 5: Het Proces in Actie
Na een uitgebreid overzicht van de historische ontwerp theorie in mijn vorige post, richten we ons nu op de ontwerppraktijk.
"Beschouw het ontwerpproces als een proces waarbij eerst alternatieven worden gegenereerd en deze alternatieven vervolgens worden getest aan de hand van een hele reeks eisen en beperkingen." - Herbert Simon
Het beheren van een ontwerpproces: Fasenamen
Laten we eerst eens kijken naar een voorbeeld van hoe dit ontwerpproces wordt beheerd in een typisch project. De focus hier ligt op het demystificeren van het ontwerpproces voor niet-ontwerpers en het bieden van een best practice in ontwerp voor de ontwerpcommunity. Het eerste dat ik wilde bespreken, zijn de naamgevingsconventies van de stappen zelf. Het is belangrijk om de algemene functie van de fasen van het ontwerpproces te begrijpen. Daartoe zijn er labels voor elke stap die hun best doen om te beschrijven wat er tijdens deze fasen gebeurt:
- Ontdekken — het verkennen en definiëren van de ontwerputdaging
- Concept — het bedenken en definiëren van de oplossing voor de ontwerputdaging
- Detail — het creëren van een gedetailleerd ontwerp vanuit het conceptuele ontwerp
- Leveren — het iteratief creëren en leveren van middelen met engineering en andere belanghebbenden.
Deze labels zijn bedoeld om zo nauwkeurig mogelijk te zijn. En ik heb heel hard gewerkt om deze generaliseerbare titels in bijna elke situatie goed te maken. Echter, in het algemeen, wanneer iemand (of een groep) probeert iets universeel toepasbaars te maken, eindigen ze onvermijdelijk met iets intens persoonlijks. Het is dus belangrijk om ontwerpers de vrijheid te geven om deze fasenamen aan te passen aan de groep waarmee je ontwerpt.
Een paar termen voordat je gaat
Voor de doeleinden van dit artikel en vooral voor een overeengekomen vocabulaire voor het praten over de fasen, gelden de volgende definities. Dit zijn niet per se semantisch zuivere definities, maar een uitleg over hoe ik de woorden gebruik en je in staat stel ze te vertalen naar termen van je eigen begrip.
Doelen — een universeel doel voor een fase in een project (bijv. "het probleem herformuleren" tijdens Ontdekken en "conceptueel ontwerp" tijdens Concept).
Oplevering — het document of ontwerpartefact of anderszins een zelfstandig naamwoord dat een of meer van de doelen zal adresseren, (bijv. een probleemstelling in Ontdekken, of een prototype in Concept).
Activiteit — de methode of techniek of anderszins een werkwoord dat een of meer van de opleveringen zal adresseren, (bijv. een actie kan een eenvoudige daad zijn zoals een gesprek met een productmanager).
Methode — een mini-proces waarbij technieken en opleveringen worden gecombineerd, bijv. scenario-gebaseerd ontwerp is een onderzoeksmethode voor het leveren van eindgebruikersvereisten.
Techniek — Een ontwerpactiviteit generiek of specifiek van smaak. Bijv. een gebruikerstest versus een formatieve gebruikerstest. Een meer generieke term zou iets betekenen voor een niet-ontwerper dan de specifieke zou. Evenzo geeft een meer gespecialiseerde term meer richting aan een ontwerper over wat ze zullen doen.
Fase Naamgevingsconventies
De gemakkelijkste route is om gewoon de hier besproken namen te gebruiken om de redenen dat ze functioneren zoals hierboven beschreven; niet omdat deze namen perfect zijn, maar omdat ze er zijn en een discussie over welke namen deze fasen moeten krijgen gemakkelijk kan ontaarden in een religieuze oorlog bestaande uit een onontwarbare mix van semantiek, smaken en voorkeuren. De waarheid van de een is de fictie van de ander. Hetzelfde geldt bij het benoemen van de stappen in het proces.
Maar als je vastbesloten bent om die doos van Pandora te openen en op eigen houtje op zoek te gaan naar je eigen namen, laten we dan beginnen met het erkennen van enkele zeer valide redenen om deze storm te trotseren.
Er zijn goede redenen om met andere namen voor de fasen te komen. Bijvoorbeeld, het kan zijn dat de naam van een van de fasen een compleet andere betekenis heeft in een bepaald bedrijf of domein. Bijvoorbeeld, in de jaren 60 was het gebruikelijk dat ontwerpers een gedetailleerde fase een "programmeerfase" noemden. Nu ontwerp plaatsvindt in de context van software, is die term ongepast en misleidend.
Andere redenen kunnen zijn: Spreker- en luisterfactoren kunnen ook een rol spelen, aangezien de bedoelde betekenis en geïnterpreteerde betekenis kunnen verschillen op basis van individuele kennis, ervaringen en aannames. Pragmatische invloeden moeten ook in overweging worden genomen, bijv. wat iets betekent hangt vaak sterk af van waarom het wordt gezegd, niet alleen van de letterlijke semantische inhoud. Culturele struikelblokken en gedeeld begrip of andere termen kunnen redenen zijn om de namen te veranderen, evenals de vreemde kans dat iemand een ouder had zoals een ontwerpversie van Frank Zappa en hun kind "Concept" noemde, die nu de hoofdontwikkelaar in het project is.
Maar voordat je in een uitgebreide discussie over naamgevingsconventies duikt, als het gaat om labels, zou ik liever een eigenzinnige maar oprechte belanghebbende tegemoetkomen en de namen veranderen, zolang het de doelen van de fase niet verandert. De doelen in die fasen vormen de ruggengraat van het ontwerp, niet hoe je ze noemt. Het bereiken van deze doelen in verschillende activiteiten kan het proces buigen (of wat ik schaal noem), maar het volledig negeren van een doel maakt het proces kapot vanuit het perspectief van een ontwerper.
Het is ook belangrijk om in gedachten te houden dat wanneer je één term verandert, dit de betekenis en het begrip van de anderen kan beïnvloeden. Daarom, bij het veranderen van namen, gebruik termen die samenwerken als een familie of concept. Hier zijn enkele alternatieve namen die, voor beter of slechter, zijn gebruikt door andere ontwerpbureaus, ontwerpers en deskundigen (de namen zijn verwijderd om andere mensen zoals ik te beschermen):
En deze lijst kan nog verder gaan. Je kunt ook allerlei volkomen geldige waardeoordelen bedenken als een van de bovenstaande sets beter of slechter is; want er is geen echte semantiek. Een semantiek hangt af van een gedeelde referentiebasis. Met andere woorden, er is geen echte naamgeving—alleen echte overeenstemming over naamgeving. Er moet ook worden gezegd dat zolang een enkele gedeelde basisreferentie de ontwerprationale is voor alle namen van de fasen, de resulterende namen zowel begrijpelijk als conceptueel verenigd moeten zijn. Met andere woorden, semantiek is de kunst om het willekeurige onvermijdelijk te laten voelen.
Of om Lewis Carroll te citeren uit "Alice Through the Looking Glass," met Humpty Dumpty die spreekt voor een heel ontwerpteam:
"Wanneer ik een woord gebruik," zei Humpty Dumpty, in een nogal minachtende toon, "betekent het precies wat ik kies dat het betekent – niet meer en niet minder." "De vraag is," zei Alice, "of je woorden zoveel verschillende dingen kunt laten betekenen." "De vraag is," zei Humpty Dumpty, "welke de baas is——dat is alles."
Uitbreiden/Verdelen van de Fasen
The steps are designed to sequentially follow one after the other. For example, no one can start the Concept phase without knowing the problem they were solving, as established in the prior phases. Nor can you detail design without a concept, unless you like taste wars and ineffectual software. To be clear, reordering the steps makes no sense and is not recommended for professional results (for an example of what such a project looks like see this educational Buster Keaton film: https://youtu.be/Xd6ddOlbKp8?feature=shared .
Toch rijst de vraag over het uitbreiden of verdelen van de stappen.
Uitbreiden van de fasen
Door fasen uit te breiden, bedoel ik het toevoegen van niet-ontwerpactiviteiten en -doelen aan het project. Dit helpt bij het creëren van uniforme projectplannen en het coördineren van afhankelijke activiteiten. Bij het toevoegen van doelen, scheid ze duidelijk—ontwerpdoelen versus engineering versus marketing—om het werk van elk team te verduidelijken zonder concurrerende prioriteiten te creëren. Deze aanpak maakt ontwerpprioriteiten duidelijk voor andere belanghebbenden en helpt wanneer niet-ontwerpers ideeën voorstellen die al in ontwerpdoelen zijn opgenomen, maar met andere terminologie. Het coördineert ook de ontwerpinspanningen met het werk van andere belanghebbenden, informeert het ontwerpteam en elimineert dubbel werk.
Echter, iets om op te letten, hoewel dit niet vaak gebeurt, is wanneer je ontwerpt in een vijandige omgeving (bijvoorbeeld wanneer een belanghebbende tegen het gebruik van design is en het hen wordt opgelegd), sommige mensen met minder eerbare bedoelingen kunnen proberen doelen te plannen om de jouwe te vervangen. Het is belangrijk om niet te onderhandelen over de doelen. De tools of methoden kunnen om verschillende geldige redenen worden onderhandeld, maar niet de doelen; deze blijven altijd essentieel voor goed ontwerp.
Verdelen van de fasen
Met of zonder het toevoegen van doelen, is het mogelijk om de stappen in een willekeurig aantal subcategorieën te verdelen. Zes- of zevenstapsprocessen zijn gebruikelijk. Bruce Archer, bijvoorbeeld, verdeelde zijn academische ontwerpproces in 239 stappen.
Het gaat erom wat het kleinste aantal fasen is dat nodig is. Stel dat er een grote formele onderzoeksinspanning zal zijn die begint en eindigt tussen fasen 1 en 2. En die fase moet geïsoleerd van de anderen worden beheerd. Dan zou dat een overtuigende reden zijn om een extra stap toe te voegen om die stap alleen op te nemen. Over het algemeen zijn 4-9 stappen waarschijnlijk groot genoeg om zelfs de meest complexe projecten aan te kunnen. De belangrijkste factor is dat de integriteit van Ontdekken - Concept - Ontwikkelen - Leveren intact blijft. Met andere woorden, de doelen en hun afhankelijkheden van de vorige stappen worden gehandhaafd. Terug naar ons onderzoeksexample, de projectbenaming zou er als volgt uit kunnen zien:
Ontdekken - Onderzoeksinspanning - Definiëren - Ontwikkelen - Leveren
Maar vanuit het perspectief van de 4 stappen is het:
Discover - Define 1 (Research Effort) - Define 2 (Other Define phase goals) - Develop - Deliver
Bij het splitsen van een fase is het belangrijk ervoor te zorgen dat onderling afhankelijke activiteiten aan de juiste gesplitste fase worden toegevoegd. Met dit in gedachten is het splitsen van de stappen volledig mogelijk, maar of het noodzakelijk is of niet, hangt af van het project of de gebruikte methode.
Het managen van het ontwerpproces
Het beheren van het proces is essentieel voor een goed ontwerp. Laten we duidelijk zijn, dit is geen ontwerpmanagement, het is procesmanagement dat volledig anders is. Ik verwijs hier puur naar het beheer van de ontwerpactiviteiten en -resultaten, wat een klein maar essentieel onderdeel van ontwerpmanagement vormt. Het beheer van het proces moet de iteratieve aard van ontwerp ondersteunen, met andere woorden, de mogelijkheid om je stappen te herzien of zelfs opnieuw te volgen op basis van nieuwe inzichten.
Dit procesbeheer maakt het ontwerpproces ook expliciet en transparant, minder obscuur voor de niet-ontwerpers. Dit procesbeheer moet ook procesverkortingen ondersteunen: hoe het proces kan buigen zonder te breken. Een voorbeeld van een procesverkorting zou zijn om de onderzoeksinspanningen te verminderen tot iets dat minder tijd kost vanwege een nieuwe tijdsbeperking. Maar door de veranderingen of offers in activiteiten of resultaten in het ontwerpproces expliciet te maken, kun je ook duidelijk maken welk verhoogd risico inherent is aan het doorvoeren van een projectwijziging halverwege.
Om het ontwerpproces te helpen beheren, raad ik een structuur aan die het gemakkelijkst kan worden uitgedrukt in een tabelstructuur. Een tabelstructuur die met het project kan meegroeien in verschillende parallelle functies naarmate het door verschillende iteraties gaat:
- Ontwerp Projectreferentie voor klant en intern team
- Projectontwerptool
- Projectvoorsteltool
- Ontwerpleertool
- Projectvolgtool
- Ontwerp- en Projectreferentie
Voordat ik inga op de details van elke versie van deze tool, wil ik erop wijzen dat ik een tabelversie laat zien puur om de algehele structuur duidelijk te maken zonder een uitleg van databasestructuren en andere technische elementen. Deze tabel kan eenvoudig worden geïmplementeerd in Apple's Numbers, Excel of andere spreadsheet. Maar het is nog krachtiger wanneer het enige databasefunctionaliteit erachter heeft en/of geïntegreerd is in een bestaande ontwerp-infrastructuur zoals Miro, Jira, Slack, GitHub, etc.
Ontwerp Projectreferentie
Op het eenvoudigste niveau begint de tabel als een tabel met een kolom voor elke fase en een lijst met doelen voor elke fase. Dit document alleen is een geweldige manier om zowel een team als een klant te oriënteren op wat te verwachten in het ontwerpproces. De bespreking van doelen op hoog niveau is ook een kans voor belanghebbenden om eventuele aanvullende doelen toe te voegen die essentieel zijn voor dit specifieke project.
Het document is ook een gespreksonderwerp specifiek voor een klant, als een soort ontwerpverklaring van rechten: iets dat een klant of teamleider kan gebruiken om het ontwerp verantwoordelijk te houden voor het bereiken van alle noodzakelijke doelen van een project.
Ontwerpprojecttool
Een andere iteratie van dit project is wanneer je een lijst van activiteiten en opleveringen aan elke fase toevoegt. Het projectplan kan worden geleid door een oplevering aan een doel te koppelen. Deze koppeling bepaalt in welke fase een oplevering moet worden voltooid. Evenzo, als je ook activiteiten aan een oplevering koppelt, kan de activiteit, eenmaal geselecteerd, ook een einddatum hebben aan het einde van de fase. Met behulp van gekoppelde lijsten of een database is het mogelijk om de lijst van activiteiten te filteren op basis van de geselecteerde opleveringen, waardoor de ontwerper de juiste activiteiten voor een oplevering kan kiezen, maar ook activiteiten kan selecteren die ze niet hadden overwogen of misschien zelfs niet kenden. Een gekoppelde lijst kan een aantal dagen of uren aan middelen aan de geselecteerde activiteiten koppelen. De totale activiteiten in een fase kunnen je een duur en ruwe schatting van het project geven. Dit kan de ontwerper helpen bij het opstellen van een budget en scope voor het project dat de basis kan vormen voor een projectplan.
Bovendien, gezien de alomtegenwoordige koppelingsfaciliteit die in bijna elk hulpmiddel beschikbaar is, kunnen opleveringen en activiteit-artifacten gemakkelijk worden gekoppeld, waardoor het eenvoudig is om projectopleveringen bij te houden.
Project deliverables worden meestal geüpload naar een algemeen toegankelijke cloudopslagmap. Maar door deze opleveringen en activiteiten te koppelen, hoeft men niet te weten waar het bestand wordt bewaard; ze hebben er via dit document met één klik toegang toe.
De opleveringslink kan de gebruiker rechtstreeks naar de oplevering leiden en deze openen. Een activiteitenlink, of opleveringslink waar meerdere artifacten zijn, kan de gebruiker rechtstreeks naar de map met alle documenten die nodig zijn voor een activiteit leiden, bijvoorbeeld het testschema voor de test evenals sessieverslagen, video's, enz.
Bijna al deze samenwerkingsdocumenten hebben enkele eenvoudige rolgebaseerde beperkingen, zodat sommige gebruikers alleen-lezen toegang tot het document kunnen hebben, zodat ze op links kunnen klikken maar het project niet kunnen wijzigen. Bovendien, wanneer een niet-editor het document ziet, kunnen ze de huidige status van het project in één oogopslag zien en de projectmanager op de hoogte stellen van eventuele updates die ze hebben gemist: bijvoorbeeld een zojuist voltooide activiteit naar een afgewezen oplevering.
Ontwerp- en projectreferentie
Wanneer het project is voltooid, kan men beoordelen welke activiteiten of opleveringen best practices zijn om te volgen. Het blijft alleen nog over om aan te geven welke van de opleveringen best practices zijn (en misschien ook een commentaarfunctie te gebruiken om te vermelden wat wel en niet werkte).
Je kunt deze geleerde lessen of best practices samenvoegen in één gebied in uw ontwerp-infrastructuur. Als u een pagina onderhoudt voor een specifieke activiteit of oplevering, kunt u projectlinks toevoegen als aanvullende voorbeelden. Bijvoorbeeld, een pagina gewijd aan gebruikerstests zou het testschema kunnen bevatten dat bijzonder effectief was.
