Ha valamilyen digitális termékfejlesztéssel foglalkozol, valószínűleg a te cégednél is megvan a „nagy könyv” szerint minden. Van egy dedikált design folyamat, vannak sprintjeid, talán még a híres kettős gyémánt modellt is ismered, amire a fél tech világ esküszik. Először kutatunk, aztán definiálunk, tervezünk, és csak a legvégén fejlesztünk. Biztonságosnak hangzik, de mi a baj ezzel? Ez a biztonság gyakran csak illúzió, ami megfojtja az innovációt a csapatodban.

Jenny Wen, a Figma korábbi igazgatója és az Anthropic jelenlegi design vezetője nemrég egy konferencián adott elő, ahol próbálta feloldani a szakma belső korlátait. Azt állítja, hogy a designerek és termékfejlesztési csapatok évek óta a folyamatok mögé bújnak, hogy elkerüljék a felelősséget.

Lusták lettünk, és elfelejtettünk a lényeggel – magával a termékkel – foglalkozni.

A folyamat mint „biztonsági takaró”

Jenny Wen egyik fő premisszája, hogy a folyamat mára egyfajta „biztonsági takaróvá” vált. A designerek azért ragaszkodnak a lépésekhez, mert félnek a kudarctól.

Jenny egyenesen „performative artifacts”-nak, vagyis performatív kellékeknek nevezi azokat a dokumentumokat (hosszú PDF-ek, customer journey map-ek, persona leírások), amiket a csapatok gyártanak. Ezek gyakran csak arra jók, hogy a designerek „munkának látszó tevékenységet” végezzenek, és bizonyítsák a cégvezetésnek, hogy dolgoznak. De a valóságban ezek alibik, amik nem viszik előre a szoftvert.

A felhasználót nem érdekli a folyamatod. Nem érdekli a design rendszered, a kutatási riportod vagy a szépen rendezett rétegeid a Figmában. Őket csak egyetlen dolog érdekli: a termék, amit használnak.

Ugorj a megoldásra! – A drótváz halála

Tudod, mi a legnagyobb bűn a design iskolában? A „Solutionizing”, vagyis amikor azonnal a megoldással kezdesz, anélkül, hogy hetekig elemeznéd a problémát. Jenny Wen szerint viszont pontosan ezt kellene tennünk.

Régen azért rajzoltunk csúnya, szürke dobozokat (drótvázakat / low-fidelity), mert a végleges felület megtervezése lassú és drága volt. Nem akartunk pixel-tökéletes gombokat rajzolni, ha még a funkció sem volt biztos. De a technológia ezt a tételt megdöntötte. A „csúnya vázlat” már nem spórol időt, sőt, lassít, mert túl sok kérdést hagy nyitva.

Ma a High-Fidelity (magas kidolgozottságú) tervezés gyorsabb, mint a vázlatolás. 

Miért? Mert olyan eszközök vannak a kezünkben, mint a Figma, a Lovable vagy a V0 (Vercel).

• Figma: A komponens-könyvtárakkal (Design Systems) nem nulláról rajzolsz egy gombot, hanem behúzod. Kész van 2 másodperc alatt.
• Lovable / V0: Ezek az AI eszközök lehetővé teszik, hogy egy szöveges utasításból azonnal generálj egy működő, kód-szintű felületet.

Az intuíció visszatérése az adatok ellenében

Az elmúlt évtizedben a tech világ fetisizálta az adatokat. „Dilemma van? Majd az A/B teszt megmondja.” Ez kényelmes, mert leveszi a döntés terhét a vállunkról. De egyben gyáva dolog is. A nagy áttörések nem tesztekből születnek, hanem vízióból és ízlésből. Jenny ezt „Taste”-nek, vagyis szakmai ízlésnek, megérzésnek nevezi. Ha van egy tapasztalt szakembered, bízz a megérzésében! A folyamat nem helyettesítheti a tehetséget és a tapasztalatot.

A régi világban a munkafolyamat olyan volt, mint egy futószalag. A designer megálmodta a terméket, majd „átdobta a falon” a fejlesztőknek. Ez volt a design handoff, amely modell mára kezdi elveszíteni a legitimitását. A modern termékfejlesztés ugyanis nem lineáris, hanem egy „messy”, vagyis kaotikus, iteratív folyamat.

• A designer, mint technikai építész: Egy designer ma már nem engedheti meg magának, hogy ne értse a technológiát. Az Anthropicnál például a designerek nem „maszatolnak”, hanem együtt dolgoznak a mérnökökkel azon, hogy mire képes maga a nyelvi modell (említi pl. amikor a Claude Artifacts funkcióját fejlesztették).

• A fejlesztő, mint kreatív partner: A fejlesztőid többé nem ticket-végrehajtó gépek. Az olyan eszközökkel, mint a Figma Dev Mode, a fejlesztő már a tervezés alatt látja a kódot, a változókat. Nem a végén kap egy „meglepetés csomagot”, hanem valós időben látja, mit épít a designer. 

#kutatás A McKinsey jelentése szerint azok a cégek, amelyeknél a designerek és fejlesztők szorosan integrált csapatokban dolgoznak, 32%-kal magasabb bevételnövekedést érnek el, mint a silókban működő versenytársaik.

És mit csinál eközben a termékmenedzser/PM? Ha a designer és a fejlesztő így egymásra talál, a PM feladata többé nem a „rendőr” szerepe, aki a Jira jegyeket tologatja. Mivel a munkafolyamat kaotikusabbá válik (több kísérletezés, kevesebb dokumentáció), a PM-nek kell lennie annak, aki a víziót tartja a szeme előtt. Ő az, aki a „káoszban” is látja az üzleti célt, és nem engedi, hogy a csapat elvesszen a technológiai játszótéren. És így lerövidíti a sprintek/prototipizálás/tesztek idejét 1-2 hétről, akár pár napra is.

De vajon mindenhol működik ez a szemlélet?

Bár a tech startupok és fogyasztói appok világában üdítő a „csináljuk gyorsan, érzésből” hozzáállás és tényleg látni azt, hogy egyre több kis cég pakol ki (cinikusok által) úgynevezett “AI-slop”, vagyis alacsony minőségű AI-generált szoftvereket/termékeket, hogy minél előbb a userek előtt legyenek és használják őket, majd aztán iterálják a későbbi fejlesztéseket, updateket – és ez működik, ott vannak, használják őket! Ennek ellenére vannak helyzetek, ahol ez a módszer egyszerűen nem életképes. A kritikusok jogosan mutatnak rá néhány vakfoltra:

• Nem minden szoftver egyenlő: Könnyű „megérzésből” és „solution first” módon tervezni, ha egy már létező, érett kategóriát másolsz. De mi van, ha egy kórházi betegbiztonsági szoftvert tervezel? Itt a lépések kihagyása veszélyes lehet. Az ilyen komplex rendszereknél a szabványok és a mély kutatás nem „alibi”, hanem a biztonság záloga.
• Az intuíció torzíthat: A „Bízz magadban” tanács remekül működik szakértőknél, de a kezdőknél veszélyes lehet. Az emberi tényezők kutatása évtizedek óta bizonyítja, hogy elszámoltathatóság nélkül az intuíció könnyen elfogultsághoz vezet.
• Skálázhatósági problémák: A dokumentáció és a folyamatok (artifactok) gyakran azért léteznek, hogy biztosítsák az „intézményi memóriát”. Ha egy 500 fős cégnél mindenki csak a saját intuíciójára hallgat, a szervezet szétesik, és a tudás elvész, amint a „sztár designer” kilép az ajtón.

Ha egy gyorsan mozgó piacon vagy, ahol a felületi megkülönböztetés és a sebesség a lényeg, és profi csapatod van: fogadd meg Jenny tanácsát, felejtsd el a felesleges köröket és építs minél előbb high-fi prototípusokat. De ha “atomerőművet”, komplex rendszert tervezel, vagy csapatod nehezebben menedzselhető, kevésbé érett: tartsd meg a folyamatokat, mert ott azok védenek meg a bukástól.

De ne azért kövesd a folyamatot, mert „így szoktuk”, és ne is dobd ki az ablakon csak azért, mert egy nyugati unikornistól ezt hallottad. Használd az eszed, és válaszd azt a módszert, ami a TE terméked kockázataihoz illik.

Olvass még a témában!

• A saját JARVISOM: Hangalapú AI asszisztens kódolás nélkül (ElevenLabs + N8N)
• Mire lehet használi az AI asszisztenseket, AI ügynököket a cégben.
• AI Talks Budapest – AI Dev NYC: párhuzamos konferenciák a világ két oldalán
• Hogyan lehetünk mi a tech-érett és pártoló vezetők cégen belül?

Forrás:
Hatch Conference (Jenny Wen előadása), McKinsey

Fotó:
Envato License