Mi valójában a UI/UX design
A legtöbb digitális termék nem a kódon bukik el.
Azon bukik el, hogy a felhasználó a harmadik képernyő után összezavarodik, és bezárja az appot.
Ezt a pillanatot kezeli a UI/UX design, jóval azelőtt, hogy bárki egyetlen sor kódot írna.
A UI/UX design nem dekoráció.
A felhasználói célt és az üzleti célt köti össze konkrét képernyőkön, gombokon, szövegeken és interakciókon keresztül.
Ha jól csinálják, a felhasználó észre sem veszi.
Csak azt érzi, hogy minden „magától működik”.
Vegyünk egy példát, amelyre a cikk során többször visszatérünk: egy foglalási app egy fodrászszalon-lánc számára.
A felhasználó célja, hogy egy perc alatt időpontot foglaljon a kedvenc fodrászához. Az üzleti cél kevesebb telefonhívás, kevesebb elmaradt időpont és több visszatérő vendég.
A kettő közötti hidat a design építi meg.
Ez az útmutató nem fogalomtár.
Végigköveti a teljes folyamatot a user research első interjújától a fejlesztői átadásig, és megmutatja, mi kell egy fejlesztésre kész tervhez 2026-ban.
Kinek szól? Alapítóknak, product managereknek és fejlesztőknek, akik el akarják dönteni, mikor és hogyan vonjanak be designert.
És azoknak, akik már egyszer újraírtak egy fél terméket, mert „mégsem így kellett volna”.
UI vs UX: hol húzódik a határ
Egy gomb színe UI döntés.
Az, hogy a felhasználó egyáltalán eljut-e odáig, hogy megnyomja azt a gombot, már UX kérdés.
A két terület összefonódik, de nem ugyanaz, és a különbség megértése sok felesleges vitát spórol meg a csapatban.
A foglalási appnál ez így néz ki: a „Foglalás véglegesítése” gomb lehet tökéletes kontrasztú, gyönyörű zöld.
De ha a felhasználónak előtte regisztrálnia kell, megerősítenie az e-mail-címét, majd újra kiválasztania a szolgáltatást, a gomb szépsége semmit sem ér.
A felhasználók jelentős része sosem jut el hozzá.
Mi számít UI-nak
A user interface (felhasználói felület) mindaz, amit a felhasználó lát és megérint: tipográfia, színek, ikonok, gombok, űrlapmezők, térközök és a visual hierarchy, vagyis az, hogy mi kerül először a szem elé. Ide tartoznak a microinteractions is, például egy apró animáció, amely jelzi, hogy a foglalás sikeresen elment.
A jó UI döntés azonban nem ízlés kérdése.
Mérhető hatása van a feladat-teljesítésre.
Ha a fő gomb vizuálisan kiemelkedik a másodlagos műveletek közül, csökken a téves kattintások aránya és rövidül a feladat elvégzésének ideje.
A szín, a méret és a pozíció tehát teljesítménydöntés, nem díszítés.
Mi számít UX-nek
A user experience (felhasználói élmény) a teljes útvonal: milyen sorrendben jönnek a lépések, hol kell döntést hozni, mi történik hiba esetén, és mennyi kognitív terhet ró a termék a felhasználóra. Ide tartozik az information architecture (mi hol található), a user flows (a feladatok lépéssorai) és az interaction design (hogyan reagál a rendszer a felhasználó műveleteire).
Gyakori tévhit, hogy a UX „érzés”, valami megfoghatatlan.
Nem az.
A UX mérhető folyamatokról és döntésekről szól: hány lépésből áll a foglalás, hány százalékban fejezik be a felhasználók, hol hagyják abba.
Egy tölcsérelemzés pontosan megmutatja, melyik képernyőn veszíti el a termék a felhasználók felét.
Termékdesign és UI/UX kapcsolata
A product design tágabb kategória.
Magában foglalja az üzleti stratégiát, a piaci illeszkedést, a funkciók priorizálását és azt a kérdést, hogy egyáltalán mit érdemes megépíteni.
A UI/UX ennek a megvalósítási rétege: a stratégiai döntésekből kézzelfogható képernyők és folyamatok lesznek.
A foglalási appnál a termékdesign dönti el, hogy legyen-e hűségprogram az első verzióban.
A UX eldönti, hol és hogyan jelenjen meg a pontgyűjtés a foglalási folyamatban.
A UI pedig azt, hogyan néz ki a pontszámláló.
A UI/UX tervezési folyamat lépésről lépésre
A legdrágább designhiba az, amelyet a fejlesztés közepén fedeznek fel.
Egy wireframe átrajzolása néhány óra. Ugyanaz a változtatás kész kódban akár hetekbe kerülhet.
A user-centered design folyamat ezért a lehető legolcsóbb ponton tárja fel a problémákat.
Kutatás és felhasználói célok
Kis csapatoknak nem kell hónapos kutatási projekt.
Egy könnyű, egy-két hetes terv is elég ahhoz, hogy a legnagyobb tévedéseket kiszűrje.
- Készíts 5 felhasználói interjút. Öt, 30-45 perces beszélgetés a célcsoport tagjaival meglepően sok mintázatot hoz felszínre. A foglalási appnál kérdezd meg, hogyan foglalnak most, és mi idegesíti őket benne.
- Elemezd a versenytársakat. Nézz meg 3-5 hasonló terméket, és jegyezd fel, hány lépésből áll náluk a fő feladat. Nem másolni kell, hanem megérteni, milyen elvárásokkal érkezik a felhasználó.
- Nézd át a meglévő analitikát. Ha már van weboldal vagy korábbi verzió, a lemorzsolódási pontok és a support-jegyek megmutatják, hol fáj a legjobban.
- Fogalmazd meg a fő felhasználói célokat. Legfeljebb 3-5 fő feladatot írj le, például „időpontot foglal a kedvenc fodrászához” vagy „lemondja a foglalást büntetés nélkül”.
Wireframe, mockup, prototípus
Ez a három fogalom gyakran összemosódik, pedig mindegyik más kérdésre ad választ. A különbség megértése megakadályozza, hogy a csapat túl korán vitatkozzon színeken.
- Wireframe: a szerkezet. Szürke dobozok, helyőrző szövegek, semmi szín. Arra való, hogy eldöntsd, mi kerül a képernyőre és milyen sorrendben, például hogy a foglalásnál előbb a szolgáltatást vagy a fodrászt válassza a felhasználó.
- Mockup: a vizuális réteg. Statikus, de már valósághű képernyők színekkel, tipográfiával és valódi tartalommal. Akkor van rá szükség, amikor a szerkezet már stabil, és a márkát, a vizuális hierarchiát kell véglegesíteni.
- Prototípus: a kattintható folyamat. Az interactive prototypes összekötik a képernyőket, így a felhasználó végigkattinthatja a teljes foglalást. Ez az, amit tesztelni lehet, és amit a befektetőknek vagy fejlesztőknek érdemes megmutatni.
Egy ökölszabály: ha a kérdés az, hogy „mi legyen a képernyőn”, wireframe kell.
Ha az, hogy „hogyan néz ki”, mockup.
Ha az, hogy „megérti-e a felhasználó”, prototípus.
Tesztelés és miért tér vissza a folyamat
A folyamat nem egyenes vonal.
Egy jól lefuttatott teszt visszaküldheti a csapatot a user flow-hoz, sőt néha egészen a kutatásig.
Ez nem kudarc, hanem a módszer lényege.
- Adj konkrét feladatot. A usability testing során ne azt kérdezd, „tetszik-e”, hanem kérd meg a résztvevőt: „Foglalj időpontot jövő keddre hajvágásra.”
- Mérd a task completion rate-et. Hány résztvevő fejezte be segítség nélkül a feladatot? Ha ötből kettő elakad, az komoly jelzés.
- Rögzítsd az error rate-et. Számold meg a téves kattintásokat, a visszalépéseket és a rossz mezőkitöltéseket.
- Mérd a feladat idejét. Ha a foglalás átlagosan 3 percig tart a célzott 1 perc helyett, valahol felesleges lépés van.
- Döntsd el, hová lépsz vissza. Vizuális félreértésnél elég a mockupot javítani. Ha viszont kiderül, hogy a felhasználók inkább fodrász alapján foglalnának, nem szolgáltatás alapján, akkor a user flow-t kell újragondolni.
A tervtől a kódig: deliverable-ek és platformok
A legtöbb súrlódás designer és fejlesztő között nem a szép képernyőkön keletkezik.
Hanem azokon, amelyeket senki sem rajzolt meg.
Mi történik, ha nincs szabad időpont?
Ha megszakad a hálózat?
Ha a felhasználónak nincs jogosultsága?
A developer handoff akkor jó, ha a fejlesztőnek nem kell találgatnia. Az alábbi listák azt mutatják meg, mi kell ehhez a gyakorlatban.
Design system és fejlesztésre kész terv
A design systems újrahasznosítható komponensekből, szabályokból és design tokens-ből (szín-, betűméret- és térközértékek nevesített változókként) állnak. Egy fejlesztésre kész specifikáció a következőket tartalmazza:
- Komponenskönyvtár: minden gomb, űrlapmező, kártya és modális ablak egyszer definiálva, minden variánsával együtt.
- Design tokenek: a színek, betűméretek és térközök névvel ellátva, így a kód és a terv ugyanabból az igazságforrásból dolgozik.
- Reszponzív viselkedés: a responsive design szabályai töréspontonként, például mi történik a foglalási naptárral 375 px és 1440 px szélességnél.
- Validációs szabályok: milyen formátumú telefonszám fogadható el, mikor jelenjen meg a hiba (gépelés közben vagy a mező elhagyásakor).
- Jogosultságok: mit lát a vendég, a fodrász és a szalonvezető, és mi történik, ha valaki olyan funkciót próbál elérni, amelyhez nincs hozzáférése.
Komponens állapotok és edge case-ek
Minden komponensnek több élete van, mint az az egy állapot, amit a mockupon látunk. A component states hiánya a leggyakoribb oka annak, hogy a kész termék „félkésznek” tűnik.
- Töltő állapot: mit lát a felhasználó, amíg a szabad időpontok betöltődnek? Skeleton képernyő, spinner vagy részleges tartalom?
- Üres állapot: ha a kiválasztott napon nincs szabad időpont, a képernyő ne legyen üres. Javasolja a legközelebbi szabad napot.
- Hibaállapot: hálózati hiba, lejárt munkamenet vagy foglalási ütközés esetén világos üzenet és egyértelmű következő lépés kell.
- Interakciós állapotok: alapállapot, hover, fókusz, lenyomott és letiltott gombok külön megtervezve.
- Szélsőséges tartalom: mi történik egy 40 karakteres fodrásznévvel vagy egy 200 karakteres megjegyzéssel?
Akadálymentesség valójában
Az accessibility többet jelent a 4,5:1-es kontrasztaránynál.
Az Európai Akadálymentességi Irányelv 2025 júniusa óta számos digitális szolgáltatásra kötelező, így 2026-ban ez már üzleti és jogi kérdés is. A WCAG 2.2 szerint a következőkre kell figyelni:
- Billentyűzetes navigáció: a teljes foglalási folyamat elvégezhető legyen egér nélkül, logikus tabulálási sorrendben.
- Képernyőolvasó-kompatibilitás: az ikonoknak legyen szöveges címkéjük, a dinamikusan megjelenő üzeneteket pedig a felolvasó szoftver is jelezze.
- Látható fókuszjelzés: a felhasználó mindig lássa, melyik elemen áll éppen. Ezt a fókuszkeretet tilos „csúnyasága” miatt eltüntetni.
- Érintési célméret: a WCAG 2.2 AA szintje legalább 24×24 CSS pixelt ír elő, az Apple 44×44 pontot, a Material Design 48×48 dp-t ajánl.
- Szövegnagyítás: az elrendezés ne essen szét 200%-os betűméretnél sem.
- Mozgáscsökkentés: ha a felhasználó az operációs rendszerben kikapcsolta az animációkat, a termék is tartsa ezt tiszteletben.
- Szemantikus struktúra: valódi címsorok, listák és űrlapcímkék, nem csak vizuálisan formázott szövegdobozok.
- Érthető hibaüzenetek: nem „Érvénytelen bemenet”, hanem „A telefonszám 9 számjegyből áll, például 301234567”.
Mobil, web és AI termékek különbségei
Ugyanaz a foglalási funkció másképp viselkedik egy natív appban és egy belső admin felületen. A platform határozza meg, milyen UI/UX döntések számítanak igazán.
- Natív mobilapp: a platform saját mintáit (iOS Human Interface Guidelines, Android Material Design) követi, kihasználja a push értesítéseket, gesztusokat és offline működést. A felhasználó azt várja, hogy „úgy működjön, mint a többi app a telefonján”.
- Cross-platform (például Flutter): egy kódbázis két platformra, ami gyorsabb fejlesztést jelent. A designernek el kell döntenie, mely elemek legyenek egységesek, és hol kell igazodni az iOS vagy Android konvenciókhoz (például vissza-navigáció, dátumválasztó).
- Reszponzív weboldal: a mobil nézet itt általában az elsődleges. A teljesítmény közvetlenül UX kérdés: a Core Web Vitals jó értékei szerint az LCP 2,5 másodperc, az INP 200 ms, a CLS 0,1 alatt legyen.
- SaaS dashboard: sűrű adat, táblázatok, szűrők és ismétlődő munkafolyamatok. A hatékonyság fontosabb a látványnál, a gyakorlott felhasználó billentyűparancsokat és tömeges műveleteket vár.
- Belső vállalati eszköz: a felhasználók nem választhatnak másik terméket, de rossz design mellett lassabban dolgoznak és többet hibáznak. Itt a tanulási idő és a hibaarány csökkentése a fő cél.
Az AI-alapú termékek külön kategóriát alkotnak. Az AI interaction design olyan helyzetekre is tervez, amelyek hagyományos szoftverben nem fordulnak elő:
- Bizalom és átláthatóság: a felhasználó lássa, mi alapján javasolt az AI egy időpontot vagy szolgáltatást.
- Megbízhatósági szint jelzése: ha a rendszer bizonytalan, mondja ki, ahelyett hogy magabiztosnak tűnő, de téves választ adna.
- Emberi kontroll: minden fontos műveletet (foglalás, fizetés, adattörlés) a felhasználó hagyjon jóvá, és legyen lehetőség szerkesztésre.
- Hibából való visszatérés: egyszerű visszavonás, újragenerálás vagy átváltás kézi módra.
- Lassú vagy bizonytalan válasz állapota: folyamatjelzés, fokozatos (streamelt) megjelenítés, és egy „Mégsem” gomb, ha a válasz túl sokáig tart.
Mitől működik jól egy UI/UX design
Egy design akkor jó, ha a számok elmozdulnak.
Nem akkor, ha a Dribbble-en sok lájkot kap.
A különbség elsőre apróságnak tűnik, a gyakorlatban viszont teljesen más döntésekhez vezet.
Mérhető eredmények, nem csak szép képernyők
A design minőségét öt metrikán érdemes mérni.
Az aktiváció megmutatja, hányan jutnak el az első értékes műveletig (a foglalási appnál az első sikeres foglalásig). A conversion rate azt, hogy a látogatók közül hányan hajtják végre a kívánt lépést.
A retention, vagyis a megtartás azt jelzi, visszatérnek-e a felhasználók a második, harmadik foglaláshoz.
A support megkeresések száma sokat elárul: ha a „Hogyan mondhatom le?” kérdés a jegyek harmadát teszi ki, az designhiba.
Végül a CSAT és NPS pontszámok az elégedettséget számszerűsítik.
Ezekben a metrikákban gyakran a szöveg dönt.
A UX writing a gombfeliratokat, validációs üzeneteket, onboarding szövegeket és üres állapotokat tervezi meg.
A „Küldés” helyett a „Foglalás megerősítése” felirat pontosan megmondja, mi fog történni.
Az üres állapotban a „Nincs találat” helyett a „Ezen a napon nincs szabad időpont. Csütörtökön 3 is van” szöveg a lemorzsolódást foglalássá alakítja.
A felhasználók nem a képernyőket használják, hanem a szavakat olvassák. Egy rosszul megfogalmazott gombfelirat többet árt, mint egy rosszul választott szín.
Gyors felkészülési lista projekt előtt
Mielőtt designert vonnál be, válaszolj az alábbi kérdésekre. Fél óra munka, de hetek egyeztetését spórolja meg:
- Üzleti cél: mit kell elérnie a terméknek 6-12 hónapon belül?
- Célcsoport: kik a fő felhasználók, és miben különböznek egymástól?
- Fő feladatok: mely 3-5 feladatot kell a terméknek kiválóan támogatnia?
- Platformok: iOS, Android, web, vagy mindhárom?
- Integrációk: naptár, fizetési rendszer, CRM vagy más külső szolgáltatás?
- Korlátok: határidő, büdzsé, technológiai vagy jogi megkötések.
- Sikermutatók: melyik metrika mutatja meg, hogy működik a termék?
- Szükséges kutatás: mit tudsz már biztosan, és mit csak feltételezel?
A felkészülés után jön a validálás módja.
A heti, kattintható előnézeteken alapuló munka drasztikusan csökkenti a fejlesztés közbeni újratervezést.
A CompletApp például fix terjedelmű, mérföldkövekre bontott megközelítéssel dolgozik: az ügyfél minden héten végigkattinthatja az aktuális állapotot, így a félreértések napok alatt derülnek ki, nem hónapok múlva.
Kevesebb meglepetés, kiszámíthatóbb költség.
Amikor a trend árt a használhatóságnak
A divatos vizuális minták csábítóak.
De nem mindig a felhasználót szolgálják.
A túl minimalista, felirat nélküli ikon-navigáció például elegánsan néz ki, csakhogy a felhasználók egy része nem tudja, mit jelent a három pötty vagy a stilizált kis ikon.
Hasonló a helyzet a halvány szürke szöveggel fehér háttéren, amely sokszor elbukik a kontrasztkövetelményeken.
A nehéz háttérvideók és látványos animációk rontják a betöltési időt és a Core Web Vitals értékeket.
A foglalási app vendégei nem a parallaxért jönnek… hanem egy időpontért.
A szabály egyszerű: minden trendet tesztelj ugyanazokkal a metrikákkal, mint bármely más döntést.
Ha a feladat-teljesítés romlik, a trend megy.
A következő lépés a terméked felé
Ha egyetlen döntési szabályt viszel el ebből a cikkből, legyen ez: ha még nincs validált user flow, ne kezdj kódolni. Ha már van kattintható, tesztelt prototípusod, kezdj el fejlesztőt keresni.
A kettő közötti sorrend felcserélése a legdrágább hiba, amit egy termékcsapat elkövethet.
És a launch nem a vég.
A UI/UX design a termék teljes életciklusát kíséri: az első verzió után jönnek a valódi adatok, a support-jegyek, az új funkciók és az újabb tesztek.
A legjobb termékek folyamatosan finomodnak.
Mit tehetsz még ma?
Írj le 3 fő felhasználói feladatot, amelyet a termékednek támogatnia kell.
Mielőtt bármilyen képernyőt megterveznél.
Ez a lista lesz minden későbbi designdöntés mércéje.
