Mis on Design Driven Development?

Design Driven Development (DDD) ehk disainist juhitud arendus on tarkvaraarenduse metoodika, kus disainiprotsess ja kasutajakogemus (UX) dikteerivad arenduse suuna, mitte vastupidi. Erinevalt traditsioonilisest mudelist, kus disain on sageli vaid "ilusa välimuse lisamine" pärast tehnilist lahendust, algab DDD probleemi mõistmisest disaini vaatevinklist.

Eesmärk on luua tooteid, mis ei ole mitte ainult funktsionaalsed, vaid mida kasutajad soovivad kasutada. See aitab vältida olukorda, kus arendatakse valmis keerukas tehniline lahendus, mida tegelikult kellelgi vaja ei lähe.

Arendusmudeli etapid

Design Driven Development järgib sageli Design Thinking põhimõtteid. Peamised etapid on:

Empaatia (Empathize): Kasutajate vajaduste, valupunktide ja motivatsiooni süvauurimine.
Defineerimine (Define): Probleemi selge sõnastamine kasutaja vaatenurgast.
Ideede genereerimine (Ideate): Lahenduste ja kontseptsioonide väljamõtlemine (ajurünnakud).
Prototüüpimine (Prototype): Kiirete ja odavate mudelite loomine (paberil, Figmas jne).
Testimine (Test): Prototüüpide valideerimine reaalsete kasutajatega enne koodi kirjutamist.
Arendus (Build/Develop): Alles nüüd algab tehniline teostus, mis põhineb valideeritud disainil.

Alamvariandid ja seotud mudelid

DDD on pigem katusmõiste või filosoofia, kuid praktikas realiseerub see tihti läbi järgmiste metoodikate:

1. Dual-Track Agile

Kõige levinum praktiline väljund. Arendus ja disain toimuvad paralleelselt kahel rajal:
1) Discovery Track (Avastamine): Disainerid uurivad ja valideerivad ideid, olles arendajatest ajaliselt eespool.
2) Delivery Track (Tarnimine): Arendajad ehitavad valmis juba valideeritud ja disainitud lahendusi.

2. Lean UX

Keskendub vähem dokumentatsioonile ja rohkem koostööle ning kiirele tagasisidele. Tsükkel on: Mõtle > Tee > Kontrolli (Think > Make > Check). Eesmärk on minimeerida raiskamist.

Milline näeb välja arendusmudel joonisena?

Joonisena ei ole DDD sirgjooneline (lineaarne), vaid pigem tsükliline ja kattuv. Seda kujutatakse tihti kahe põimunud ringina (Discovery ja Delivery) või lõpmatuse märgina, kus info liigub pidevalt disaini ja arenduse vahel.

Visuaalne kirjeldus: Vasakul on "Disaini tsükkel" (Uurimine -> Ideed -> Prototüüp), mis söödab sisendit parempoolsesse "Arenduse tsüklisse" (Planeerimine -> Kood -> Testimine). Kui arenduses tekib tehniline takistus, liigub info tagasi disaini, et lahendust kohandada.

Kõige tähtsam omadus

Kasutajakesksus (User-Centricity)

See on DDD kõige kriitilisem omadus. Miks? Sest kõige kallim viga arenduses on ehitada tarkvara, mida keegi ei vaja või ei oska kasutada. Seades kasutaja vajadused ettepoole tehnilistest piirangutest, maandab see kõige suurema riski – ärilise ebaõnnestumise riski. Tehnoloogia on vahend, mitte eesmärk.

Head ja Vead (Plussid ja Miinused)

Omadus	Plussid (Head)	Miinused (Vead)
Kasutajakogemus	Väga kõrge kasutajarahulolu ja intuitiivsus.	Oht sattuda "over-design" lõksu (lihvitakse liiga kaua).
Arenduse kiirus	Vähem ümbertegemist hiljem, sest nõuded on selged.	Projekti algfaas on aeglasem ja nõuab kannatust.
Riskid	Maandab riski ehitada valet asja.	Risk, et tekivad eraldatud "silod" (disainerid vs arendajad).
Loe põhjalikumalt: Interaction Design Foundation

Viited ja allikad

Alljärgnevalt lingid usaldusväärsetesse materjalidele, mis selgitavad metoodikat süvitsi: