A bejegyzésben az Under The Hood: UI/UX QA SCS blog hír fordítását találod, amely 2026 július 11-én jelent meg.
Ma betekintést nyerhettek az Euro Truck Simulator 2 és az American Truck Simulator fejlesztésének kulisszái mögé, hogy felfedezzük a folyamat egy újabb fontos részét, amely segít formálni az úti élményt. Ezúttal a felhasználói felület/felhasználói élmény minőségbiztosítására (UI/UX QA) összpontosítunk, és annak szerepére az intuitív, élvezetes és kifinomult felületek létrehozásában játékosaink számára.
Hogy végigvezessük ezen a lenyűgöző területen, szeretnénk bemutatni Petrt és Jant a UI/UX QA csapatunkból. Elvisznek egy munkanapra, hogy elmagyarázzák, hogy mi a feladatuk, és megosztják veled, hogy hogyan segítenek abban, hogy minden menü, gomb és interakció tökéletesen működjön, mielőtt a képernyőre kerülne.
„Szia! Petr vagyok, a konzol UI/UX minőségbiztosítási vezetőjeként dolgozom. Kollégáimmal együtt segítettünk két csapatot összehozni, amelyek most kulcsszerepet játszanak abban, hogy játékaink jól működjenek és nagyszerű felhasználói élményt nyújtsanak.
Mi felelünk mind az Euro Truck Simulator 2, mind az American Truck Simulator játékokért minden platformon, beleértve a hagyományos PC-t, a Steam Decket, a VR-t, a PlayStationt és az Xbox Series X/S-t. Magukon a játékokon kívül olyan tesztelési projektekben is aktívan részt veszünk, mint a Driving Academy, a Coaches és a Road Trip.
A munkám főként a koordinációra, a tervezésre és a tesztelési eredmények elemzésére összpontosít. Szorosan együttműködöm más csapatokkal a hibák vagy UX problémák mielőbbi azonosítása és megoldása érdekében. Célom, hogy úgy szervezzem meg a folyamatainkat, hogy az egész csapat hatékonyan tudjon dolgozni és felesleges nyomás nélkül tudjon koncentrálni minden új patch vagy DLC megjelenése előtt.
Emellett aktívan tesztelek mindent, amin a csapatom dolgozik. Nemcsak hogy őszintén élvezem a tesztelést, hanem nagyon fontosnak is tartom. A teljes folyamatban való közvetlen részvétel lehetővé teszi számomra, hogy jobban beazonosítsam azokat a területeket, amelyeknél továbbfejlődhetünk, és csapatként haladhatunk előre.
Mindig jelen vagyok, hogy támogassam a csapatomat, ha valamiben elbizonytalanodnak, vagy tanácsra van szükségük, és tudatosan törekszem a pozitív, barátságos légkör fenntartására, ahol mindenki élvezi a közös munkát.”
„Szia, Jan vagyok, senior UI/UX tesztelő, elsősorban játéktesztelésre szakosodva. 31 éves vagyok, és két éve dolgozom az SCS Software-nél. Eredetileg junior tesztelőként csatlakoztam a céghez, konkrét szakterület nélkül, de miután beilleszkedtem a csapatba és megismertem a fejlesztési folyamatunkat, gyorsan felfedeztem a felhasználói élmény iránti szenvedélyemet.
Petr támogatásával és útmutatásával, aki akkoriban már végzős volt, segítettem létrehozni a játéktesztelési folyamatunkat, és azóta is annak finomításán dolgozom.”
De mi is az a felhasználói felület és felhasználói élmény minőségbiztosítás?
„Mielőtt egy új funkció bekerülne a játékainkba, annak hosszú úton kell keresztülmennie. És a UI/UX (felhasználói felület/felhasználói élmény) is ott van az út mentén. Legyen szó akár egy új funkcióról, akár egy meglévő újratervezéséről, minden az elemzéssel és a párbeszéddel kezdődik köztünk (minőségbiztosítási osztály) és a játékdizájn osztály (Game Design – GD) között. Az újratervezéseknél először fel kell mérnünk a jelenlegi állapotot, azt, hogy mi működik, és hol van szükség változtatásokra, az új funkciók és az újratervezések esetében pedig át kell gondolnunk, hogy hová szeretnénk eljutni. Ezekre a kérdésekre adott válaszok fogják meghatározni az összes jövőbeni döntést.”
Hogyan néz ki egy tipikus UI/UX tesztelési folyamat, és mennyire szorosan működsz együtt más csapatokkal?
„Általánosságban elmondható, hogy igyekszünk a lehető minél előbb belefolyni egy funkció fejlesztésének folyamatába, és a lehető legszorosabban együttműködni a fejlesztési osztállyal (GD), így a funkció következő szakaszának is részesei vagyunk, ahol visszajelzést adunk a tervről. Ez azt jelenti, hogy átnézzük a tervdokumentumot, és megpróbálunk előre gondolkodni, ezért olyan kérdéseket teszünk fel, mint: „Intuitív lesz ez? Világos, hogy ez egy gomb? Nem felejtettünk ki semmit? Mi a helyzet az akadálymentesítéssel? Olvasható lesz a szöveg egy kisebb képernyőn?” és még sok más. A fejlesztési osztállyal folytatott oda-vissza egyeztetés után eljutunk egy olyan tervhez, amit aztán egy programozó megvalósíthat.
Az első játszható prototípus elkészítése az a pont, ahol egyszerre két széken kell ülnünk. Még mindig látnunk kell a nagy képet – ismernünk kell a dizájnt, látnunk kell, hogyan illeszkedik egymáshoz az összes elem, tudnunk kell, hogy egyes döntéseket miért úgy hoztak meg, ahogy. De most már úgy is tekinthetünk a játékra, mint egy játékos, aki először látja a funkciót. Olyan játékossá kell válnunk, aki most kezdi, és még soha nem játszott más játékkal. Vagy egy hardcore játékossá, aki sok játékkal játszott már, de kamionos szimulátorral még soha. Vagy egy valós kamionossá, aki a pihenőhelyein kézikonzolon játssza a játékainkat. A játékainkkal nagyon széles közönség játszik, és a dizájnnak mindannyiuk számára működőképesnek és intuitívnak kell lennie.
Ebben a szakaszban további problémákat azonosítunk, módosításokat javasolunk, és lehetséges megoldásokat keresünk a GD csapattal és a funkción dolgozó programozókkal együtt. Miután kellően magabiztosak vagyunk az elért állapottal kapcsolatban, itt az ideje a validációnak a következő szakaszban.
A funkció útjának következő fontos része a belső játéktesztelés. Ez egy nagyszerű módja annak, hogy friss nézőpontokat kapjunk a vállalat különböző részeiről érkező kollégáktól, akik nem látták a tervdokumentációkat, és ideális esetben semmit sem tudnak a funkcióról. Mielőtt elkezdenénk tesztelni, összefoglaljuk a kérdéseket, amelyekre választ szeretnénk kapni: „Intuitív ez a képernyő? Jól vezérli az összes kiegészítőt? Az X hozzáadása okozott-e bármilyen felesleges súrlódást?” Ezen kérdések alapján részletes forgatókönyveket készítünk a válaszadók számára, amelyek arra késztetik őket, hogy a szokásos játékmenet ciklusát szimulálva foglalkozzanak az (újra)tervezett funkcióval. Ezután meghívjuk a válaszadókat a Játékteszt Laborunkba (Playtest Lab), ahol végigvezetjük őket a forgatókönyveken, megfigyeljük a viselkedésüket, reakcióikat, jegyzetelünk és kérdéseket teszünk fel. Szemkövetést is alkalmazunk, amely megmutatja, mire fókuszálnak a játékosok, megmutatva, hogy mely elemekre irányítják a szemüket először, és melyek maradnak teljesen észrevétlenül.
A teszt végeztével a válaszadók egy kérdőívet is kitöltenek, amely lehetővé teszi számukra, hogy tovább gondolkodjanak a funkción, további megjegyzéseket fűzzenek hozzá, és esetleg saját ötletekkel álljanak elő.
Mindez rengeteg feldolgozandó adatot eredményez. Ehhez az alkalmazott kutatásból származó gyakorlatokat használjuk, így kvalitatív kódolással kezdünk, majd tematikus elemzéssel és gyakoriságszámlálással. Közérthetően fogalmazva, átnézzük az összes nyers állítást és megfigyelt viselkedést, és különböző kategóriákba soroljuk azokat aszerint, hogy milyen gyakran említették/figyelték meg azokat. Ez segít azonosítani az ismétlődő mintákat, és tágabb témákhoz/problémákhoz rendelni azokat.
Ezután elkészítjük a végső jelentést, amely összefoglalja a válaszadók viselkedését, reakcióit, véleményét, azonosítja a mögöttes problémákat, és lehetséges megoldásokat javasol.
A következő lépések a játékteszt eredményeitől függenek. Ha olyan mélyreható problémákat találunk, amelyek nagy változtatásokat igényelnek a tervben, akkor vissza kell térnünk a tervezőasztalhoz, és meg kell ismételnünk az előző pontokat, ami egy újabb játékteszthez vezet, hogy megerősítsük, hogy a problémákat kielégítően kezelték. Jó friss példa erre az újratervezett Mikroalvás / Pihenő funkció, amely a fáradtságot két külön működési módra osztotta (Fáradtság és Kötelező pihenőidő szimulálása). A játéktesztelés során azt tapasztaltuk, hogy ez az új felosztás és annak ábrázolása nagyon zavaró volt a játékosok számára, és a funkciót teljesen újra kellett tervezni, nagy sikerrel (legalábbis reméljük).
Ha viszont csak felszínes problémákat azonosítunk, amelyek némi csiszolást igényelnek, akkor a GD osztály foglalkozik ezekkel, és mi továbbléphetünk a funkció végső tesztelésére.
A végső tesztelés során főként az FQA-ra (TB: Functionality Quality Assurance [fanksanaliti kvoliti esúrensz] – avagy Funkcionális Minőségbiztosítás) koncentrálunk – a terv nagyrészt elkészült, és most azon dolgozunk, hogy minden a tervek szerint működjön. Amint ez megtörtént, a funkció beolvasztható a fő ágba, ahol az Integrációs QA osztály veszi át az irányítást, biztosítva, hogy maga a funkció a tervezett állapotában élje túl az összevonást, és ne legyen hatással semmi másra a folyamat során, de ez már egy másik fejezet témája.”
Mi tetszik a legjobban a UI/UX-en való munkában?
Petr: „Mit élvezek a legjobban? Ez egy nehéz kérdés. Röviden, szinte mindent! A csapatunkban mindenki szenvedélyesen rajong mindenféle műfajú játékért, így hihetetlenül kifizetődő lehetőségünk adódik, hogy saját ötleteinkkel és javaslatainkkal járuljunk hozzá az Euro Truck Simulator 2-höz és az American Truck Simulatorhoz.
Az SCS-nél gyakran a saját utunkat járjuk, ami különösen élvezetessé teszi a munkát. Ugyanakkor minden döntés középpontjában a játékosok állnak. Új játékmeneti elemek fejlesztésekor a tervezők könnyen akaratlanul is a „csőlátás” csapdájába eshetnek. A mi feladatunk, hogy megkérdőjelezzük ezt a perspektívát, és friss szemléletet alkalmazzunk. Gondolunk a tapasztalt kamionosainkra, de soha nem feledkezünk meg azokról a játékosokról, akik most kezdik a pályafutásukat. A játék kezelőfelületének sok különböző perspektívából való vizsgálata munkánk kulcsfontosságú része és egyben az egyik legkreatívabb aspektusa is.
Mindent megteszünk annak érdekében, hogy játékainkat a lehető legközvetlenebbé tegyük, miközben gondoskodunk arról, hogy továbbra is ugyanolyan szórakoztatóak maradjanak.”
Jan: „Tetszik, ahogy ötvözöd a technikai és az emberi szempontokat. A felhasználói élmény többnyire egy ember és egy gép közötti interakció, és összhangba kell hozni mindkettőt.
Az első projektem, amivel előálltam és levezényeltem, a Grafika (Graphics Settings) képernyőkép-megjelenítése volt, hogy a játékosok jobban láthassák a játékuk vizuális megjelenítésének beállításakor végrehajtott változtatásokat, és ez tökéletesen példázza, mire gondolok – érdekel, hogyan működnek a dolgok a háttérben, de az is, hogy a játékos hogyan érzékeli és érzékeli azokat.”
Milyen üzenetet szeretnél megosztani a közösségünkkel, és mennyire értékesek a játékosok visszajelzései a felhasználói élmény javításában?
„A játékosok visszajelzései hihetetlenül fontosak számunkra, és állandó inspirációt jelentenek. Őszintén örülünk, hogy egyre több kezdeményezés épül a visszajelzéseitek köré itt az SCS-nél. Szeretnélek biztosítani benneteket, hogy valóban figyelmesen elolvassuk a hozzászólásaitokat, ötleteiteket és javaslataitokat, nemcsak a UI/UX csapatunk, hanem az egész stúdió.
Egyértelmű, hogy mindazok, akik velünk kapcsolatban állnak, mennyire törődnek a játékainkkal, és mi is pontosan ugyanígy érzünk. Imádjuk az Euro Truck Simulator 2-t és az American Truck Simulatort, és szeretnénk mindkettőt egyre jobbá és jobbá tenni. Őszintén szeretnénk tudni, hogy mi tetszik nektek, mit szeretnétek hozzáadni, és mit gondoltok, min lehetne még javítani. Már most hihetetlenül sok visszajelzést kaptunk. Bárcsak láthatnátok a terjedelmes dokumentumokat, amelyekben gondosan összegyűjtjük és rendszerezzük az összes ötleteteket és kéréseteket.
Sajnos nem tudunk minden javaslatot megvalósítani. Ennek számos oka lehet, amelyek nem azonnal nyilvánvalóak, például a grafikus motor korlátai, a korlátozott belső erőforrások, a játékrendszereink technikai korlátai, a licencszerződések és egyebek miatt. De kérjük, továbbra is keressetek minket! Visszajelzéseitek sosem maradnak észrevétlenek. Nektek köszönhetjük, hogy folytathatjuk ezt az utat, és együtt, még jobbá tehetjük az élményt.
Köszönjük mindenkinek, aki velünk járja ezt az izgalmas utat!”
VÉGE.
Kattints a megosztáshoz, e-mailben elküldéshez vagy a nyomtatáshoz.
Facebook poszt
