Híd a Stripe és a magyar számlázás között
A Számlabridge egy klasszikus middleware-megoldás, ami a Stripe és a magyar adózási szabályok közötti szakadékot hidalja át.
A Stripe a világ egyik legnépszerűbb fizetési kapuja, azonban önmagában nem képes a magyar NAV-bekötéssel rendelkező rendszerek (például a Számlázz.hu) felé megfelelően adatot továbbítani. A kereskedőknek ezért két választásuk maradt: kézzel kiállítani a számlát, vagy egyedi fejlesztéssel API-integrációt kiépíteni minden egyes webshophoz.
A Számlabridge egy „set-and-forget" típusú, automatizált szoftver. Az MVP-fázis azonban elsősorban a funkcionális működésre fókuszált, ami a felhasználói élmény rovására ment.
A számlázási adatok útja
Mit rontott el az MVP-felület?
Az ikonok nem elég beszédesek
Az ikonok önmagukban nem hordoztak elég kontextust, a felhasználónak „meg kellett tanulnia" a jelentésüket, ez növelte a belépési küszöböt. Egyetlen ikon próbálta az egyes szakaszok státuszát leírni, ami nem adott elegendő visszajelzést a hibáról.
Nem megfelelő elnevezések
A „Stripe adat" gomb nem utalt arra, hogy itt a táblázat oszlopait lehet szerkeszteni.
Adat-túlsúly
A Stripe ID-k uralták a táblázatot, kiszorítva a releváns üzleti adatokat, például a státuszokat és a fizetés részleteit.
A szűrő kizárólagossága
A szűrő egyszerre csak egyetlen szempont szerint működött: státuszt és időszakot nem lehetett kombinálni, így egy-egy specifikus tranzakció megtalálása lassú keresgéléssé vált.
A fejlesztői logika rátelepszik a felületre
Az eredeti felület megkövetelte a felhasználótól a rendszer belső architektúrájának ismeretét. A szoftver a saját alapfeladatát, az adatok lekérését és strukturálását, sablonok formájában visszatolta a felhasználóra: pontosan ismernie kellett a Stripe metaadat-mezőinek mélyebb rétegeit.
Részletek, mint kognitív útvesztő
A felhasználónak a history lista technikai naplózásából, apró ikonokból és bizonytalan tooltip-szövegekből kellett kikövetkeztetnie a hiba valódi okát, majd segítség nélkül megtalálnia a megoldáshoz vezető funkciót.
Kényszerű popup-használat
Olyan kritikus üzleti funkciók, mint a „Teszt számla kiállítása" vagy az „Adatellenőrzés", csak a „Részletek" mögött voltak elérhetőek. Egy egyszerű művelethez is mindenképpen popupot kellett nyitni.
Fejlesztői logika helyett üzleti felület
Proaktív hibakezelés és diagnózis
A korábbi, nehezen észrevehető és bizonytalan tooltip-üzeneteket egy döntéshozatal-alapú hibaelhárító mechanizmus váltotta fel. Bevezettük a hangsúlyos „Javítás" gombot és a hozzá tartozó intelligens popupot, amely közérthetően elmagyarázza a hiba pontos okát, és azonnali, egykattintásos javítási lehetőségeket kínál a felhasználónak.
Táblázat szerkesztése
A félrevezető „Stripe adat" elnevezést a közérthető „Táblázat szerkesztése" kifejezésre cseréltük. Bevezettünk egy modern, oszlopalapú szerkesztőfelületet, amely leveszi a technikai terhet az ügyfél válláról: a felhasználónak csak ki kell választania, mely oszlopokra van szüksége (Vevő, Ország, Összeg).
Felismertük, hogy a hosszú, táblázatot uraló azonosítókat a felhasználók nem olvassák, csupán másolásra vagy hivatkozásként használják. Az ID-t rövidített, kattintható és másolható hivatkozássá alakítottuk, amivel kritikus helyet szabadítottunk fel a felületen.
Rugalmas és összetett szűrés
A szűrési rendszert alapjaiban gondoltuk újra: a korábbi kizárólagos választási lehetőségek helyett egy rugalmasabb és átláthatóbb panelt hoztunk létre. Az új megoldás lehetővé teszi, hogy a felhasználó egyszerre több szempontot is érvényesítsen, például státuszt és időintervallumot kombináljon, felgyorsítva ezzel a specifikus tranzakciók keresését.
A jó felület a motorháztető alá rejti a komplexitást
A fejlesztői szemléletű felületalkotás gyakran a rendszer belső logikáját és technikai paramétereit kényszeríti a felhasználóra, ami jelentős kognitív terhelést és bizonytalanságot okoz. A projekt tanulsága, hogy a valódi felhasználói élmény akkor kezdődik, amikor a technológiai komplexitást a szoftver a „motorháztető" alá rejti, és helyette közérthető, üzleti döntéseken alapuló felületet kínál.
Hiba esetén a passzív diagnózis helyett a rendszernek vezetett folyamatot kell kínálnia, amely az észlelés, a megértés és a beavatkozás lépésein visz végig, és biztosítja a döntéshozatal alapjait, hogy a speciális szaktudás nélküli ügyfél is magabiztos döntéshozóvá válhasson.
A te szoftvered is többet tudna egy jobb felülettel?
Egy UX-audittal megmutatjuk, hol veszíted el a felhasználóidat, és mit érdemes először javítani.
Harminc perc, prezentáció nélkül. Ha nem látunk közös munkát, a hívás végén megmondjuk.