Low-fi gondolkodás és képernyővázlat

Célok

A lecke végére érted, miért a szerkezeti kérdések vizsgálatára való a low-fi wireframe. A user flow-ból képernyővázlatot tudsz készíteni, a képernyőn jelölni tudod a fő feladatot, az információt és az állapotot, és meg tudod különböztetni a szerkezeti döntést a későbbi vizuális díszítéstől.

Miért nem a látvánnyal kezdünk?

Aki először tervez, hajlamos azonnal szép képernyőket rajzolni. Ez érthető: azt látjuk, és az tetszik a legjobban. A hátránya, hogy a visszajelzés is a látványra irányul. Ha a résztvevő azt mondja, hogy „szép ez a kék”, az semmit nem árul el arról, érti-e a felületet. A wireframe ezt a félrevezetést kerüli: szándékosan egyszerű, hogy a beszélgetés a szerkezetről és a működésről szóljon.

Miért kezdünk alacsony részletességgel?

A low-fidelity (low-fi) terv alacsony részletességű, gyorsan módosítható modell. A wireframe a felület szerkezetét és hierarchiáját mutató, alacsony részletességű képernyővázlat. Low-fi lehet papír, tábla, egyszerű Figma-fájl vagy bármely eszköz, amely gyorsan módosítható. A részletességet a kérdéshez igazítsd: ha azt vizsgálod, mi legyen a képernyők sorrendje, elég lehet néhány doboz és címke; ha azt teszteled, hogy az emberek megértik-e egy hibaüzenet nyelvét, akkor a valósághű szöveg már fontosabb lehet.

A részletesség skálája (a tanult kifejezésekkel):

Szint	Mit mutat?	Mikor jó?
Kézi vázlat	Dobozok, vonalak, címkék	Ötletelés, gyors elrendezés-vita
Low-fi wireframe	Szürke blokkok, valódi címkék, hierarchia	Szerkezet, feladatsor tesztelése
Mid-fi	Pontos elrendezés, valós tartalom, kevés stílus	Tartalom és bizalom vizsgálata
High-fi	Végleges színek, képek, stílusok	Vizuális hatás, bemutató

Ebben a fejezetben low-fi szinten dolgozunk.

A flow-ból képernyő

Ne üres vászonnal kezdj. Vedd elő a user flow-t, és minden fontos állapothoz kérdezd meg:

• Mit kell a felhasználónak itt tudnia?
• Mit kell eldöntenie?
• Mit tehet (milyen műveletek közül választhat)?
• Miből látja a következményt?

Egy időpontválasztó képernyőnek például nem csak naptárt kell mutatnia. A döntéshez fontos lehet a helyszín, az időtartam, az ár, a férőhely és a korábbi választás megváltoztatásának módja is.

Rajzold ki a normál út mellett az üres, betöltő vagy hibaállapotot is. Nem kell minden állapotot teljesen kidolgozni, de a flow kritikus pontjain jelezd, mi történne. A vázlat célja, hogy a csapat és a tesztelő ugyanarról a rendszerviselkedésről beszéljen.

Egy képernyő felépítése

Egy wireframe-en általában a következő rétegek látszanak:

1. Cím / kontextus: hol vagyok?
2. Fő információ: ami a döntéshez kell.
3. Elsődleges művelet: a képernyő fő feladatát támogató legfontosabb művelet.
4. Másodlagos lehetőségek: kisebb hangsúlyú alternatívák.
5. Állapot: betöltés, hiba, siker jelzése, ha releváns.

Mit jelölj egy wireframe-en?

Az elsődleges művelet a képernyő fő feladatát támogató, legfontosabb felhasználói művelet. Az annotáció a vázlathoz kapcsolt rövid magyarázat egy viselkedésről vagy feltételezésről. Hasznos, ha egy vázlaton egyértelmű a képernyő címe, a fő információ, az elsődleges művelet, a másodlagos lehetőségek és az állapot. Komplex elemnél rövid annotációban írd le a feltételezést: például „csak a szabad időpontok választhatók”, „a hibaüzenet beküldés után jelenik meg”, vagy „a korábbi adat megmarad visszalépéskor”. Ez megakadályozza, hogy a képernyő kinézetéből mindenki mást olvasson ki.

Mit ne tegyél a wireframe-be?

• Ne használj véglegesnek látszó színeket, fotókat és illusztrációkat.
• Ne válassz betűtípust díszítésből; egy semleges, olvasható betű elég.
• Ne dolgozz „Lorem ipsum” szöveggel azokon a helyeken, ahol a szöveg a feladat része (címke, gomb, hibaüzenet). Ott használj valódi szöveget.
• Ne rajzold meg az összes képernyőt egyszerre; a fő feladat kritikus állapotait készítsd el és próbáld ki.

Végigvezetett példa: a Mai program első wireframe-je

A Mai program csapata a fő feladatot rajzolja: „ma esti program kiválasztása”. Az első vázlat a találati lista előtt rögtön részletes térképet és sok szűrőt mutat. Teszteléskor kiderül, hogy a résztvevők először csak azt akarják látni, mi van ma, mennyibe kerül és hova kell menni. A következő low-fi változatban a lista kerül előre, a térkép másodlagos nézet lesz, a kulcsadatok (idő, ár, nyelv, jelentkezés) pedig minden kártyán megjelennek. A változtatás nem vizuális ízlésből, hanem a döntési sorrendből következik.

Az annotáció a kártyánál: „Az ár és a jelentkezési feltétel mindig látható, rövidítés nélkül; ha az adat hiányzik, ‘Ár nem ismert’ jelenik meg.”

Gyakori tévhitek

Állítás	Pontosítás
„A wireframe legyen csúnya.”	Nem a csúnyaság a cél, hanem hogy a részletek ne takarják el a szerkezeti kérdést.
„Előbb minden képernyőt meg kell rajzolni.”	Először a fő feladat kritikus állapotait készítsd el és próbáld ki.
„A low-fi nem tesztelhető.”	Sok navigációs, tartalmi és hierarchiai kérdéshez épp a low-fi a legjobb eszköz.
„A wireframe a végső képernyők vázlata, csak színek nélkül.”	A wireframe szerkezeti modell; a végső megjelenés más döntéseket is hoz.

Röviden

• A wireframe szándékosan egyszerű, hogy a szerkezetről és a működésről szóljon a visszajelzés.
• A low-fi terv gyorsan módosítható; a részletességet a vizsgált kérdéshez igazítsd.
• A user flow minden fontos állapotához tartozzon képernyővázlat, a kritikus kivételekkel együtt.
• Az annotáció rögzíti a viselkedést és a feltételezést, hogy mindenki ugyanazt olvassa ki.

Ellenőrző kérdések

1. Melyik user flow-állapotból hiányzik még a képernyővázlatod?
2. Mi az elsődleges feladat minden vázlatodon?
3. Milyen feltételezést kell annotációban rögzítened?
4. Mely részlet terelné el most a figyelmet a szerkezeti kérdésről?