Egy gyógyszeripari tesztlabor számára terveztünk egy automatizálási megoldást. A labor gyógyszeralapanyagokat vizsgál, és meglepő módon számos folyamatuk teljesen manuálisan vagy Excelben zajlott. Startupként azért vontak be minket, hogy üzleti folyamataik egy részét automatizáljuk. Az első lépés az volt, hogy megértsük, valójában hogyan működik a folyamatuk, majd megtervezzünk egy integrációt, ami összeköti:
→ a mi szoftverünket (az automatizálási réteget)
→ a belső laborrendszereiket
→ és az ügyfeleiket (azokat a külső cégeket, akik mintákat küldenek tesztelésre)
A projekt elején nagyon kevés információnk volt: csupán a weboldaluk és néhány e-mail, amelyekben nagyvonalakban leírták, hogyan képzelik el a folyamatot. Ez nem sok egy olyan komplex és szigorúan szabályozott területen, mint a gyógyszeripar. Volt néhány képernyőtervünk egy korábbi, hasonló funkcióhoz, de hamar kiderült, hogy ezek nem lesznek megfelelőek. Az egyes ügyfelek üzleti folyamatai és igényei jelentősen eltérhetnek egymástól. A meglévő megoldásaink nem passzoltak ehhez az ügyfélhez. Így teljesen elölről kellett megterveznünk mindent.
A határidő pedig szoros volt: az integrációt másfél hónap alatt szerettük volna elindítani. Az első demó az ügyféllel pontosan egy hét múlva volt esedékes.
Ezért gyorsan kellett megterveznem a folyamat architektúráját.

Egy magas szintű folyamatábrát készítettem FigJamben:

→ bemutatva a teljes folyamat menetét
→ feltérképezve a három felhasználói szerep közötti kapcsolatokat
→ definiálva, hogy melyik szerepkör milyen információkat lát az egyes lépésekben
Először a csapatunkkal egyeztettem ezt az ábrát. Megosztottuk egymással, mit tudunk, milyen forgatókönyvekre nem gondoltunk még, és hogyan lehetne ezt technikailag megvalósítani az elérhető erőforrásokkal. Az idő szűkössége miatt e-mailben küldtem célzott kérdéseket az ügyfélnek, hogy pontosítsuk a hiányzó részeket — ők pedig a lehetőségeikhez mérten válaszoltak. A válaszaik alapján frissítettem az ábrát és a tervezést, hogy a demó során már valami kézzelfoghatót tudjunk megbeszélni. Emellett képernyőterveket is készítettem a folyamat egy részéhez a bemutatóra. Ehhez a már meglévő design systemünket használtam (amit még hónapokkal korábban fejlesztettem ki), és korábbi komponenseinkre építettem.

Egy hét alatt eljutottam oda, hogy:
megértettem a felhasználói problémát,
feltérképeztem és validáltam a valódi folyamatot,
és gyors tesztelést tudtam végezni az ügyféllel.
Ez a közös munka után végre lehetőségünk nyílt a projekt fókuszának véglegesítésére. Láttuk, mely részek kritikusak az induláshoz, és miket lehet későbbi fejlesztési körökre hagyni.

Néhány kulcsfontosságú tanulság ebből a projektből:
→ Néha nehéz kérdezni az ügyféltől, mert a megoldásod még „nem tökéletes”. De sokkal jobb őszintén bevonni őket a folyamatba. A demó előtt elmondtam: most a folyamatot validáljuk, nem kész terméket mutatunk.
→ A korai validáció rengeteg időt és energiát spórol. Megakadályozza, hogy olyan funkciókat építsünk, amik nem működnek vagy nem valós igényeket szolgálnak.
→ Az ügyfelek értékelik az átláthatóságot. Szívesen elmagyarázzák a folyamataikat, főleg ha látják, hogy valóban meg akarjuk érteni az üzletüket.
→ A folyamatábrázolás + közös gondolkodás segít elkerülni, hogy rossz irányba induljunk. Az ábra azonnal láthatóvá tette a hiányosságokat és nyitott kérdéseket — mindkét fél számára.
→ Tervezőként vagy fejlesztőként gyakran derül ki, hogy a dolgok nem úgy működnek, ahogy elképzeltük. Fontos ezt időben felismerni.
→ Soha ne alapozd a tervezést csak saját feltételezésekre. Még tapasztalt csapatok is könnyen elsiklanak lényeges részletek felett, ha nem ellenőrzik azokat.
→ A legjobb megoldások közösen születnek: az ügyfél üzleti tudása és a csapat technológiai és UX ismeretei együtt hozzák létre a valódi értéket.
→ A folyamat feltérképezése a priorizálásban is segít: mi automatizált, mi manuális, mi csak „jó lenne, ha lenne”.
→ A korai validáció az ügyféllel — még vázlatos ábrák alapján is — kulcsfontosságú. Nem kell csillogó prototípus. Nálunk volt, ami még csak post-itek formájában létezett (pl. listák, legördülők tartalma), míg más elemek már a design system UI-t használták — és ez így is teljesen működőképes volt. Különösen szoros határidők mellett sokkal fontosabb az, hogy a folyamatban és a prioritásokban egyetértsünk, mint az, hogy tökéletes látványt adjunk. Ez néha nehéz a belső perfekcionistának, de ez nem kiállítás — ez közös építés.