Egy képernyő megtervezése és egy folyamat megtervezése nem ugyanaz

A Figma és a hasonló designeszközök hosszú ideje alapvető részei a digitális termékfejlesztésnek. Segítségükkel pontosan meghatározható egy felület megjelenése, a komponensek elhelyezkedése és a különböző képernyők vizuális struktúrája.

Egy komplex üzleti alkalmazás esetében azonban önmagában nem az a legfontosabb kérdés, hogy hogyan néz ki egy képernyő, hanem az, hogy mi történik, amikor a felhasználó használni kezdi.

Mit csinál a rendszer egy adott művelet után? Mi történik hibás adat esetén? Hogyan jutunk el egyik állapotból a másikba? Milyen információ jelenik meg különböző felhasználói döntések hatására?

Ezeket egy működő prototípus sokkal kézzelfoghatóbban tudja megmutatni.

A statikus tervet értelmezni kell

Egy hagyományos tervezési folyamatban több képernyő készül el Figmában, amelyeket specifikációk és folyamatleírások egészítenek ki.

Az ügyfélnek ezek alapján kell elképzelnie, hogyan fog működni a kész rendszer. Ugyanezeket az anyagokat később a fejlesztőknek is értelmezniük kell.

Minél összetettebb egy folyamat, annál több olyan részlet jelenhet meg, amely egy statikus képernyőn egyszerűen nem látható.

Egy működő prototípusnál ezzel szemben nem elképzelni kell a folyamatot: ki lehet próbálni.

Nem képernyőket mutatunk az ügyfélnek, hanem működést

Az ASH-nál ezért az üzleti alkalmazások tervezésében egyre nagyobb szerepet kapnak a működő prototípusok.

Ahelyett, hogy például öt egymást követő képernyőt mutatnánk meg az ügyfélnek, létrehozhatunk egy olyan prototípust, amelyben ténylegesen végigjárható az adott folyamat.

A felhasználó rákattinthat egy gombra, megnyithat egy modalt, kitölthet egy űrlapot, válthat különböző állapotok között, és láthatja, hogyan reagál minderre a rendszer.

Így az egyeztetés kérdése is megváltozik.

Nem azt kérdezzük:

„Így megfelelő lenne?”

Hanem azt:

„Próbáljuk ki. Így szeretnétek használni?”

Az AI megváltoztatja a prototípuskészítés költségét

Korábban egy részletes, működő prototípus elkészítése önmagában is jelentős munkát igényelhetett. Az AI-alapú fejlesztő- és designeszközök ezt a folyamatot jelentősen felgyorsíthatják.

Az ASH-nál a projekt meglévő design systemét adjuk át a Claude-nak, így a prototípus már a meghatározott vizuális rendszerből és komponensekből épülhet fel.

Ezután a projekten dolgozó tanácsadó az üzleti igények alapján elkészíti a működő prototípust.

Ez fontos változás: az üzleti problémát és az ügyféligényt közvetlenül ismerő szakember már az egyeztetés korai szakaszában működő formába tudja önteni a megoldást.

A hibák hamarabb láthatóvá válnak

Egy statikus terven egy gomb tökéletes helyen lehet, miközben csak használat közben derül ki, hogy a mögötte lévő folyamat nem logikus.

Egy prototípusban ezek a problémák már implementáció előtt felszínre kerülhetnek.

Az ügyfél kipróbálja a folyamatot, visszajelzést ad, a prototípust módosítjuk, majd ismét egyeztetjük. Mindez még azelőtt történik, hogy az adott funkció tényleges fejlesztése elkezdődne.

Ez nem szünteti meg az iterációt. Az iterációt egyszerűen egy korábbi és olcsóbban módosítható szakaszba helyezi át.

A fejlesztő is pontosabb kiindulópontot kap

A prototípus nemcsak az ügyfél számára teszi érthetőbbé a tervezett rendszert.

Az implementáció során a fejlesztő már egy olyan referenciát kap, amelyen látható a felület, a felhasználói folyamat, az interakciók és a rendszer különböző állapotainak működése.

Ez csökkentheti a specifikáció értelmezéséből fakadó oda-vissza egyeztetéseket, és pontosabb közös képet teremthet az üzleti és a fejlesztői oldal között.

Akkor már nincs szükség Figmára?

Nem erről van szó.

A Figma továbbra is értékes eszköz lehet a design system kialakítására, UI-tervezésre, komponensek definiálására és vizuális koncepciók kidolgozására.

A változás inkább abban van, hogy nem feltétlenül érdemes egy komplex alkalmazás minden egyes állapotát és folyamatát külön statikus képernyőként megtervezni, ha ugyanez gyorsan működő prototípussá alakítható.

Az ASH megközelítésében ezért a két eszköz nem feltétlenül egymás versenytársa:

Design system → működő prototípus → ügyfél-validáció → implementáció.

A cél nem az, hogy kihagyjunk egy lépést a tervezésből. Hanem az, hogy már a fejlesztés megkezdése előtt a lehető legközelebb kerüljünk ahhoz, amit az ügyfél végül valóban használni fog.