[UX és stratéga tippek] User flow vagy kampánymechanizmus készítése BPMN 2.0 szabvány segítségével

Jelen cikk leegyszerűsített folyamata BPMN 2.0-ban

A cikk tartalomjegyzéke:

1. A user flow folyamatábrákról röviden
2. Az ismertebb folyamatábratervezési eszközök, szabályrendszerek
3. Mi az a “BPMN™ 2.0” és miért annyira jó?
4. A BPMN 2.0 szabályrendszeréről röviden
5. Pár BPMN 2.0 példa a projektjeimből
6. Még több érdekesség a BPMN világából
7. Ami a BPMN-ből (nekem) hiányzik
8. User flow tervezés BPMN 2.0 szabályrendszerben, de milyen eszközzel?
9. Verdikt, útravaló

1. A user flow folyamatábrákról röviden

Szeretek felhasználói folyamatokat modellezni, mert a modellezés során gyorsan kibukik, hogy egy felhasználó mit tud egy adott weboldalon vagy szolgáltatásban csinálni és az interakciói milyen további folyamatokat eredményeznek a rendszeren belül.

A folyamattervezés generálja a funkciókat és azok működésének egyszerű bemutatását, mely alapja lesz a funkcionális specifikációnak, és segítséget nyújt a felületek és értesítők felületi tervezésében is a tervezési folyamat következő lépéseiben.

Sokáig a józan paraszti ésszel (JPÉ) vázoltam fel ezeket folyamatokat. A modellezés során törekedek a modularitásra, tömbösítésre, hogy az egyes folyamatokat újra tudjam hasznosítani. A legegyszerűbb példával élve: egy e-mail ellenőrzési folyamatot (interakció > token generálás > értesítő küldése > értesítő lekattintása > értesítés az ellenőrzés sikerességéről) meghívhatunk egy felhasználói regisztráció, de akár egy profilmódosítás során is. Ennek legnagyobb előnye, hogy ha később ki szeretnénk egészíteni a folyamatot, akkor elég csak egy helyen megváltoztatni, hiszen a belefutó folyamatútvonalak (folyamatsorok) jelzik, hogy mikor futhat bele a felhasználó.

Egy foglalási folyamat, amelyet józan paraszti ésszel (JPÉ) terveztem, az egyes részfolyamatok tömbösítve, mindenféle népszerű szabályrendszer nélkül

A “JPÉ” nehézsége mindig az volt, hogy:

• a folyamat során bekövetkező hibalehetőségeket bonyolult volt szemléltetni a túl sok útelágazódás miatt. Pl. a “Kitöltötte az adatokat?” kérdésre (útelágazódás) rögtön két, egy “Igen” és egy “Nem” ággal bonyolíthattam a folyamatot, amely így újabb alágakat eredményezhetett és egy végtelenül hosszú folyamatsor lett az eredménye.
• Csak a folyamat egyik felét rögzítettem, a háttérben futó folyamatokat nem. Pl. azt, hogy a felhasználó által generált információkat, adatokat az adminisztrátor hogyan dolgozza fel, nem mindig vagy csak érintőlegesen dolgoztam ki.
• Ha a keep-it-simple (törekvés az egyszerűségre) vagy a Minimal Valuable Product (MVP, azaz az induláshoz szükséges alapvető funkciók) elvet követtem, akkor a hibalehetőségeket vagy a másik fél folyamatát nem jeleztem, így végül a modellezés is elmaradt. Mindez nagyon sok kérdést vetett fel a tervezés és a fejlesztés további szakaszában is.

Az mai világban az MVP-re törekvés egy kétélű fegyver. Az agilitás vagy a lean módszertanok miatt ez nem akkora probléma, hiszen a terméket a különböző sprintek vagy felhasználói visszajelzések során, folyamatosan lehet a megfelelő irányba tovább tervezni és fejleszteni.

Ez a gondolkodásmód elméletben jól hangzik, de a rögvalóságban, ahol a megrendelő a projekt elején akarja látni, hogy mennyit kell majd fizetnie a projekt végén — kb. mint egy dobozos termék vagy a kocsi vásárlásakor -, már nem olyan egyszerű. Ebben az esetben a minél pontosabb tervezés elengedhetetlen.

Az is elképzelhető, hogy ha észrevesszük a folyamatbeli adottságokat vagy hibalehetőségeket és az ezt okozó külön ágak lekezelését, már a projekt elején más fejlesztési technológiát használunk. Pl. ha egy webshopban a termékeket külön kategóriaoldalakon listázzuk vs. ha tulajdonságok (vagy “címkék”) alapján szűrjük. Utóbbi esetben az egyes termékekkel, kategóriákkal kapcsolatos gombokra történő kattintás egy összetett listaoldalt szűrnek le és alakítják annak kinézetét és további szűrőjét (kb. mint egy Árukereső).

Egy marketing kampány esetén még összetettebb a probléma: ott a médiavásárlást és -foglalást nagyban befolyásolja, hogy mit terveznek a stratégák, így már a tervezési képet kaphatnak róla, hogy a fogyasztók hol lépnek be és ki a kampány folyamatában.

Tehát a cél az, hogy a folyamatábránk legyen EGYSZERŰ, könnyen átlátható, mégis TARTALMAZZA A LEHETŐ LEGTÖBB ESHETŐSÉGET.

2. Az ismertebb folyamatábratervezési eszközök, szabályrendszerek

Szerencsére a folyamatábra készítésére régóta léteznek szabályrendszerek is, amik a tervezést és a megértést is segítik. Ilyen szabályrendszer pl. az UML is, viszont annak a sokrétű, de “bonyolult” formátumai nem ideálisak és prezentálni is nehéz a végeredményt.

Ezen kívül ott vannak a jóval felhasználóbarátabb, a UX szakmában jól ismert Service Blueprint és a User Journey Map eszközök, amik a nagyképet remekül szemléltetik, de korlátoltak a jelölési lehetőségei.

A Lynda.com-on egy üzleti tréning videóban szó esett egy rövid kitérőként a BPMN-ről, ami első blikkre megragadott. Mivel a Lyndán nincsen külön BPMN kurzus, így segítségül hívtam a Google-t, a Youtube-ot, de végül a Udemy volt a legnagyobb segítség (ez és ez). Itt megtaláltam azt két a kurzust, ami tényleg érthetően mutatta be a BPMN megfelelő használatát, ráadásul egy augusztusi Back to School akció keretén belül 10 EUR / kurzusért az enyém lett. Ezen kívül segítségemre volt egy összefoglaló cheatsheet táblázat is, de erről később.

3. Mi az a “BPMN 2.0” és miért annyira jó?

A BPMN™ a Business Process Model and Notation rövidítése és üzleti folyamatok tervezésére használják jellemzően a Business Analyst (Üzleti Elemző) munkakörben dolgozók. Sőt az élet minden területét remekül le lehet modellezni vele: nemcsak komplett üzleti folyamatokat, hanem (web)alkalmazások működésének szemléltetésére is tökéletesen alkalmas. Éppen ezért felhasználói élmény vagy service design tervezésekor, de még üzleti stratégia alkotáskor is remekül használható a szabályrendszer. Sőt, az a tapasztalatom, hogy marketingkampányok modellezéséhez is hasznos, ha vizuálisan is szeretnénk mások felé prezentálni a kampánymechanizmust.

A UX szakma felé úgy jellemezném, hogy valahol a fentebb említett Service Blueprint és az UML folyamatvizuálási szabályrendszerek között helyezkedik el és így tudja a bonyolult folyamatokat érthetően bemutatni.

4. A BPMN 2.0 szabályrendszeréről röviden

Igazság szerint a JPÉ módszerrel tervezés nem áll messze egyik folyamattervezéstől sem: feladat/esemény, mi következik ebből, milyen lehetőségek vannak, milyen feladat/esemény következik ebből.

A BPMN viszont nagyon hamar megtanulható jelöléseket használ és ezért tud túlemelkedni a többi szabályrendszeren.

Legfontosabb elemei:

• Kezdő- / belépő- és végesemény(ek) (mivel lehet több is) megadása egy fő- vagy alfeladatban: ez határozza meg egy feladat vázát, így ez szinte mindig kelleni fog.
• Milyen köztes események (event) lehetségesek és ezek mit eredményeznek. Ilyen pl. egy időzítés, hiba, “mégsem”, megszakítás, vagy üzenet esemény, stb.
• Milyen feladatok (taskok) találhatók a folyamatban és melyik szereplő (pl. júzer vagy rendszer) a felelős érte. Ezek a feladatok ráadásul kibonthatók még részletesebb folyamatokká bármikor, egészen a legapróbb részletekig, ha szükséges.
• Milyen útválasztókon (gatewayeken) megy végig a folyamat — kitérve arra, hogy azok az alfolyamatok párhuzamosan futnak vagy csak az egyiknek kell teljesülnie.
• Kiknek, mikor, mi a feladata, milyen feladat vagy esemény indítja el őket egy feladat elvégzésében — erre a sávok (lane) a legjobb eszköz (pl. külön a vevő és ügyintéző sávja). Ez a UX-eseknek már a Service Blueprintből is ismerős lehet.
• A sávokban elhelyezhető fázisok (ahogyan a Service Blueprintben is)…,
• … és persze ezek összekötése, a folyamat irányát jelezve.

5. Pár BPMN 2.0 példa a projektjeimből

A lenti példákat Microsoft Visioval készítettem és a program szerint az ábrák hibamentesen megfelelnek a BPMN2.0 szabályrendszernek. Az adatokat elhomályosítottam.

Egy háromszereplős (+ a rendszer folyamat az utolsó sávban) tervem BPMN 2.0 szabályrendszerben, mely tartalmaz fizetési és csevegési folyamatokat is. (Microsoft Visio)

Egy egyszerűbb webshop felhasználói és admin folyamatai szereplők (horizontális) és fázis (vertikális) folyamatokra bontva. (Microsoft Visio)

Korai próbálkozás: itt még féltem elengedni a JPÉ gondolkodásomat, de a BPMN szabályoknak ez is megfelel még ha nincsenek se sávok, se fázisok (Microsoft Visio)

Korai próbálkozás: felhasználói profilkezelés BPMN szabályrendszerben, sávok és fázisok nélkül (Microsoft Visio)

A legjobban azt szeretem benne, hogy a fázisok és a résztvevők sávjai miatt remekül átlátható és persze folyamatosan ki is bontható, pontosítható, ahogy merülsz el a projektben. Itt arra gondolok, hogy egy projekt elején első körben csak a fő üzleti feladatokat és összefüggéseket vázolod fel, majd ahogy mélyülsz el, úgy tudod kibontani az egyes részfolyamatokat; feltenni kérdéseket (megszakító események és elágazások) és azokra folyamatbeli válaszokat adni.

Például a projekt elején egy webshopos koncepció a következő feladatokból fog állni:

1. Felhasználó böngészik
2. Felhasználó kosárba rakja a terméket
3. Felhasználó sikeresen fizet
4. Ügyintéző csomagol és postázza a küldeményt
5. Felhasználó megkapja a csomagot és örül

A fenti folyamat az ideális és egyszerűsített út, rengeteg kérdéssel (“Mi van akkor ha…?”), és a projekt jellege fogja meghatározni, hogy szükség van-e a válaszokra.

A projekt közepén már részletes információd lesz az egyes feladatok alfolyamatairól:

• képet kapsz arról, hogy szükséges-e az addicionális folyamat/funkció, mint pl. egy regisztráció vagy az elhagyható,
• tudni fogod, hogy egy kosárral mi fog történni, ha nem tud fizetni a felhasználó,
• azt is tudni fogod, hogy ahhoz, hogy a termék eljusson a felhasználóhoz, milyen ügyintézői folyamatokon megy keresztül a termék,
• és mi történik akkor, ha meghiúsul a tranzakció bárhol a folyamatban.

6. Még több érdekesség a BPMN világából

A szabályrendszer 2011-ben nyerte el a ma is használatos formáját és a hivatalos összefoglaló leírás itt található: https://www.bpmnquickguide.com/view-bpmn-quick-guide/ , de egy kezdőnek ez nem sokat tud segíteni a szabályrendszer megismerésében.

• Kezdőbarát leírás angolul: https://camunda.com/bpmn/
• Kezdőbarát videó angolul: https://www.youtube.com/channel/UCe3p1Oq8dgSPet123tnQ3Rg
• Cheatsheet, magyar poszter: https://drive.google.com/file/d/1lmKpIQEbJo0pC6853w9MrAsdNyPA59R8/view?usp=sharing
• Cheatsheet, angol poszter: http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf
• Wiki angolul: https://www.visual-paradigm.com/tutorials/bpmn-tutorial-with-example.jsp

7. Ami a BPMN-ből (nekem) hiányzik

• Az adatmodellezés lehetősége, mivel nem lehet benne pl. információs architektúrát tervezni (így adatbázis kapcsolatokat sem);
• A felületek jelölése nehézkes — ha az alap szabályrendszert be akarod tartani nehéz jelezni, hogy az egyes feladatok milyen felületen helyezkednek el, főleg ha azt egy visszatérő modulként kezeled.

Cserébe a BPMN-nel könnyebb a stakeholderek felé prezentálni az üzleti, szolgáltatási vagy felhasználói folyamatot, de alkalmas egy promóciós kampány útját is modellezni és nagyon könnyen kibuknak a hiányosságok vagy a hibák, ha ügyelünk a szabályrendszer betartására.

8. User flow tervezés BPMN 2.0 szabályrendszerben, de milyen eszközzel?

Mivel Windowst használok és megrögzött Office-fan vagyok, ezért jellemzően Microsoft Visioval dolgozok. A programban a kiválasztható sablonok között szerepel a BPMN szabályrendszer is és abban kezdve a tervezést nem csak az elemeket készíti elő, hanem lehetőség van a tervezett folyamatokat szabályilag ellenőrizni.

Ami viszont tökéletes kezdőknek és haladóknak is egyaránt, a kiforrott BPMN-JS alapokon nyugvó ingyenes Cawemo (online, kollaboratív) vagy Camunda Modeler (desktop). A cég ugyanaz, a technológia ugyanaz, a termék ingyenes, csak a tervező környezet helye más. A tervezés során a szabályrendszert figyelembe véve engedi a tervezést és nem utólag kell ellenőrizni, mint a Visioval.

Ezen kívül ha a munkafolyamatok megkívánnák, akkor lehetőség lenne ezt a vizuális “megfogalmazást” üzleti logika szintjén egyszerűen átadni a fejlesztőknek, akik könnyebben átvezethetik a saját IDE-jükbe (és nem “idejükbe” 🙃). Erre léteznek nagyvállalati megoldások (pl. Oracle BPM), ezeket hivatásos nagyvállalati Business Analystek használják és ideális esetben remekül integrálódik a terv a nagyvállalati környezetbe, annak minden hiányosságával és rugalmatlanságával.

A teljesség igénye nélkül íme a lista BPMN készítéséhez:

• Lucid Cart — BPMN része fizetős (nem próbáltam).
• BPMN.IO / BPMN-JS — Camunda által menedzselt open source js library, lényegében minden tud ami BPMN. Integrálható saját rendszerbe. Tervezés közben ellenőrzi a kapcsolatokat és csak a szabálynak megfelelő kapcsolatokat engedélyezi. Stabil, folyamatosan fejlesztik, tökéletes.
• Cawemo — A BPMN.IO hostolt és ingyenes szolgáltatása. Legnagyobb előnye, hogy van benne kollaboráció.
• Camunda Modeler — A BPMN.IO desktop változata, kollaboráció nélkül. Az itt megtervezett folyamatrajzok importálhatók a Cawemoba, ekkor egy új iteráciü jön létre.
• Microsoft Visio — fizetős, de a világ összes népszerű ábrázolással kapcsolatos szabályrendszert tartalmazza (ezt használom, lakást is terveztem már benne, imádom, havi 15 EUR).

9. Verdikt, útravaló

Nincs ideális választás. Függ attól is, hogy mennyire indokolja a projekt, hogy elmerüljünk a folyamat ábrázolásában és függ attól is, hogy melyik áll kézre. Viszont ha szabályos diagramot szeretnél, mindenképpen olyat javaslok használni, amiben van szabályellenőrzés is.

Ha tetszett ez a cikkem, akkor olvasd el a Wikispeciről, egy újfajta funckionális specifikáció készítésről szóló cikkemet, mivel ezzel a két megoldással még a vizuális tervezés (drótváz és UI design) előtt szinte tökéletesen le lehet modellezni webes és szoftveres megoldásokat felületeket, funkciókat és fogalmakat úgy, hogy minden mindennel logikusan kapcsolódjon egymáshoz.