A szoftver, amit a dolgozók csendben kikerülnek
Miért a UX-tervezésen múlik, hogy a céges szoftvert valóban használják-e
- AI Körkép
A legtöbb céges szoftver csendben mond csődöt, anélkül hogy bárki panaszkodna. A rendszer elindul, hetente nagyjából egyszer lép be valaki, a tényleges munka pedig visszaszivárog a táblázatokba, az e-mail-szálakba és egy közös fájlba, amelynek senki sem a gazdája. A funkciók nagy valószínűséggel rendben voltak, a bevezetés is nagyjából a terv szerint ment, a betanítás megtörtént, a rendszer mégis félig kihasználatlanul áll, miközben a cég továbbra is fizet érte. Egy olyan vállalatnak, amely a működéséhez szoftvert vásárol, ez a csendes kudarc sokba kerül.
A jó hír, hogy a használt és a kerülgetett szoftver közötti különbség egyetlen jól megnevezhető tényezőn múlik: a UX-tervezésen. Erről szól ez a cikk.
A kihasználatlan szoftver rejtett költsége
Amikor a kollégák kikerülik a hivatalos rendszert, a költség ritkán jelenik meg külön tételként; inkább a mindennapi működés réseiben bújik meg. Ugyanazokat a számokat kétszer viszik be: egyszer a rendszerbe, egyszer pedig abba a táblázatba, amelyben valójában megbíznak. Így az adatoknak két lassan széttartó változata keletkezik. A riportok tovább készülnek, mert valakinek kézzel kell összefésülnie őket, és minden kézi átadásnál újabb hibák csúsznak be. A szabályozott területeken pedig az árnyékfolyamat megfelelőségi kockázattá válik, hiszen az auditnyom egy olyan fájlban marad, amelyet sosem erre szántak.
Hogy ez mennyire általános, azt az iparági adatok is megerősítik: a Zylo 2026-os SaaS Management Index szerint a megvásárolt szoftverlicencek több mint 40 százaléka kihasználatlan marad. A kidobott pénz azonban csak a jéghegy csúcsa. A mélyebb veszteség az a munka, amely csendben megkerüli azt a rendszert, amelybe a cég beruházott.
A döntéshozó számára az üzenet egyszerű: kétszer fizet. Egyszer magáért, a rendszerért, másodszor pedig azokért a kerülőmegoldásokért, amelyek csak azért léteznek, mert az első beruházás sosem gyökerezett meg.
Arról, hogyan alakulnak ki a hivatalos rendszereket megkerülő, párhuzamos digitális folyamatok, részletesebben is írtunk a Shadow AI a munkahelyen → cikkünkben.
Miért tervezési kérdés a használat
Ha alacsony a használat, az első reflex az, hogy a felhasználókat okoljuk: tartsunk még egy tréninget, küldjünk emlékeztetőt, vigyük a kérdést a változáskezelés szintjére. Ez a reflex azonban rendszerint melléfog, mert az emberek a legkisebb ellenállás irányába mozdulnak. Ha a táblázat négy kattintás, a hivatalos képernyő pedig tizennégy, akkor a táblázat minden alkalommal nyer, bármit is ír elő a betanítási terv.
A használat sorsa már a tervezésnél eldől, jóval az éles indulás előtt. Egy jól megépített felület a helyes műveletet teszi a legegyszerűbbé, leköveti a munka tényleges menetét és eltünteti azokat az apró súrlódásokat, amelyek visszaterelik az embereket a régi megszokásaikhoz. Valójában ez a felhasználói élmény tervezésének igazi feladata: gyorsabbá tenni a munkát, mint a kerülőutat.
Hogy a tervezést érdemes komolyan venni, annak megvan a pénzügyi alátámasztása is. A McKinsey öt éven át követett 300 vállalatot, és azt találta, hogy a tervezésben legjobbak jóval gyorsabban növelték a bevételüket, mint a versenytársaik; a különbség elérte a 32 százalékpontot. A jó tervezés tehát az eredménykimutatásban is meglátszik. Sok egyedi szoftver- és alkalmazásfejlesztési projekt épp itt bukik el: a funkciókat eltalálják, a felhasználói élményt viszont elvétik, az ebből fakadó alacsony használatot pedig emberi problémának olvassák, miközben az ok a tervezésben rejlik.
Hogy néz ki az alacsony használat a kis- és nagykereskedelemben
A kis- és nagykereskedelemben az alacsony használat ára szokatlanul jól látszik, mert itt a szoftver a napi működés kellős közepén áll. Vegyünk egy kasszarendszert (POS), amely a csúcsforgalomban a pultnál fél másodperccel lassabban reagál. A dolgozók a biztonság kedvéért papíron is vezetni kezdik a tételeket, és csak később egyeztetik. Vagy egy hűségprogram-alkalmazást, amelyben túl sok koppintás kell egy vásárló regisztrálására, így az eladók előbb-utóbb fel sem ajánlják, a beléptetés pedig csendben elakad. Vagy egy nagykereskedelmi rendelőfelület, amely annyira nehezen átlátható, hogy a kiemelt partnerek inkább telefonon adják le a rendelést, így az önkiszolgáló csatorna teljes értelmét veszti.
Mindegyik esetben megvan a funkció és működik is. Csak épp az élmény annyira kényelmetlen, hogy veszít, és minden elvesztett interakció mérhető: egy elmaradt regisztráció, egy lassabb fizetés, egy újra begépelt rendelés.
Hogyan működik a használatra fókuszáló UX-tervezés
Hogyan tervezhető tehát olyan szoftver, amelyet valóban használnak? A válasz korábban kezdődik, mint a legtöbb csapat gondolná: ott, ahol a problémát megértjük. Több mint 15 év nagyvállalati rendszerek fejlesztése és integrációja után megtanultuk, hogy a valódi szűk keresztmetszet ritkán az, amely a briefben szerepel. Ezért kézzelfoghatóan dolgozunk: az Ön csapatával együtt, lépésről lépésre felrajzoljuk a tényleges munkafolyamatot egy falra, és megnézzük, hová tart valójában a munka. A valódi probléma az esetek többségében ott bújik meg, ahol nem is kerestük volna. Kiderült, hogy a sokat panaszolt képernyővel semmi baj, a néma akadály pedig egy két lépéssel korábbi átadás-átvétel.
Innentől a tervezés a tényleges használatot mérhető számként kezeli, olyanként, amelyre lépni is lehet.
A tényleges használat mérése
Kövessük a használati és aktivitási mutatókat, a DAU/MAU-t, valamint a feladathatékonyságot, vagyis azt, hogy a tényleges munka mennyi időbe telik a rendszerben a kerülőúthoz képest. A megvásárolt licencek száma azt mutatja meg, mit vettünk meg; a használat azt, mit vezettünk ténylegesen be.
Arról, hogyan kapcsolható a technológiai használat valódi üzleti megtérüléshez, részletesebben is írtunk az AI projektek: mikor lesz a ROI több mint elmélet → cikkünkben.
Tesztelés és iterálás valódi felhasználókkal
Tegyük a korai változatokat azok elé, akik majd nap mint nap használják a rendszert valódi feladatokra, még mielőtt a fejlesztés véglegesedne. A McKinsey épp ezt a szokást emelte ki: a felhasználók folyamatos meghallgatását és a fejlesztés közbeni finomítást, mint a négy olyan tervezési gyakorlat egyikét, amely megkülönbözteti az élbolyt. Hagyjuk, hogy minden javítást az adatok által feltárt súrlódás vezessen.
Újra tervezés, majd automatizálás
Ahol egy lépést azért hagynak ki újra meg újra, mert körülményes, ott a megoldás gyakran az, hogy előbb újra tervezzük, majd automatizáljuk: így a felület végzi el az unalmas részét, a rendszer használata pedig megszűnik a többletmunka lenni. A jó tervezés és az automatizálás épp ezen a ponton erősíti egymást.
A használat az első képernyő előtt dől el
Itt jön a kellemetlen rész. A használati problémák többsége már azelőtt eldől, hogy bárki megnyitna egy tervezőeszközt, abban, ahogyan a feladatot megfogalmaztuk. Ha a projekt úgy szól, hogy „készítsünk egy hűségprogram-alkalmazást”, akkor egy hűségprogram-alkalmazást kapunk, amelyet talán senki nem használ. Ha viszont úgy, hogy „az eladó tíz másodperc alatt be tudjon léptetni egy vásárlót a csúcsforgalomban”, akkor olyasmit kapunk, amiért az emberek maguktól nyúlnak. A helyes feladatmeghatározás a használat előfeltétele; ez az első, amit a projekt indulásakor jól kell eltalálni.
A következő fejlesztés előtt tehát érdemes elidőzni egyetlen kérdésen: tudja-e, hogyan kerüli ki a csapata azt a rendszert, amellyel ma is dolgoznak?
A tanulság
Mindehhez nem kell különleges tehetség, hanem csupán néhány következetesen alkalmazott szokás. Mérjük a tényleges használatot, a feltételezés helyett. Rajzoljuk fel a munkát azokkal együtt, akik végzik. Tervezzük úgy a felületet, hogy a kívánt művelet legyen a legkönnyebb út, és a bevezetés után is folyamatosan teszteljünk. A jó szoftver egy tiszta kérdéssel kezdődik arról, hogyan működik valójában a cég, és akkor szolgálja meg az árát, ha az emberek gondolkodás nélkül nyúlnak hozzá.
Ha az Ön szoftvere él, de alig használják, érdemes a helyes probléma meghatározásával kezdeni, még az első sor kód megírása előtt is. Pontosan ezt szolgálja az Omnit Megoldás-koncepció (Service Design) szolgáltatása: felrajzoljuk a tényleges működést, pontosan beazonosítjuk a valódi problémát, és a használatra tervezett fejlesztési koncepcióvá formáljuk, és ott automatizálással egészítjük ki, ahol az megszünteti a kerülőutakhoz vezető súrlódást.
Források és ajánlott olvasmányok
Ez a cikk az Omnit projekttapasztalatára, valamint az alábbi adatokra épül, amelyek alátámasztják a szoftverek kihasználatlanságáról és a tervezés pénzügyi hatásáról szóló állításokat.
- Zylo. (2026). 2026 SaaS Management Index. Zylo. Cikk megnyitása →
- McKinsey & Company. (2018). The Business Value of Design. McKinsey & Company. Cikk megnyitása →
Fekszi Csaba
Fekszi Csaba informatikai szakértő, több mint két évtizedes tapasztalattal az adatmérnökség, a rendszerarchitektúra és az Mesterséges Intelligencia alapú folyamatoptimalizálás területén. Munkájának középpontjában olyan skálázható megoldások tervezése áll, amelyek mérhető üzleti értéket teremtenek.
Kapcsolódó cikkek
Gyakorlati útmutató világos, hiteles és konverzióra hangolt íráshoz a mesterséges intelligencia korában
Megalapozott döntések a kritikus pillanatokban
Biztos benne, hogy az AI a megfelelő következő lépés?
Segítünk feltárni a valódi lehetőségeket, korlátokat és a reális következő lépéseket.