Fejlesztők számára készített javítási lista elkészítése

Javítási lista fejlesztőknek

A javítási lista fejlesztőknek akkor hasznos, amikor egy weboldalon már látszanak a gondok, de a tulajdonos nem általános véleményeket akar hallani, hanem pontos teendőket szeretne. Ilyenkor nem elég annyi, hogy valami zavaros vagy lassú. Kell egy olyan anyag, amelyből a fejlesztő rögtön látja, mi hibás, mi sürgős, és mi várhat. A magyar és az angol nyelvű UX audit anyagokban is ugyanazok a visszatérő témák jelennek meg. Navigáció, visszajelzés, űrlapok, mobil használat, következetesség, hibaüzenetek, túlterhelt képernyők és a javítások sorrendje. Budapest környékén sok magánmegbízó csak akkor jut el idáig, amikor már túl sok pénz ment el apró tűzoltásra.

Szerintem a jó javítási lista fejlesztőknek nem hosszú és nem okoskodó. Inkább pontos. Leírja, hogy hol akad el a látogató, miért gond ez, és mit kell átírni vagy átrendezni. Sok ember ott hibázik, hogy képernyőképeket kér piros jelöléssel, de nem kér mellé prioritást. Pedig a fejlesztőnek nem csak az fontos, hol a hiba, hanem az is, hogy melyik javítás hoz rögtön eredményt. A Qjob.hu oldalon ezért én olyan szakembert keresnék, aki nem csak auditál, hanem fejlesztői szemmel is tud írni.

Mit tartalmaz a fejlesztői hibajegyzék

Egy használható hibajegyzék több részből áll. Először kell egy rövid leírás a problémáról. Utána a helye, például főoldal, kapcsolatfelvételi űrlap vagy mobil menü. Ezután jön a hatás. Kevesebb kattintás, félbehagyott kitöltés, bizonytalanság, rossz olvashatóság. És csak ezután érdemes leírni a javasolt javítást. Én személy szerint szeretem, ha minden hiba mellé odakerül a sürgősség is. Kritikus, fontos vagy ráérő. Enélkül a teendőlista könnyen szétesik.

A külföldi audit útmutatókban gyakran külön blokkot kapnak az üres állapotok, a hibaüzenetek és a fókuszállapotok. Ez jó irány. Sok magyar oldalon ezek hiányoznak, pedig pont ezek mutatják meg, hogy a felület gondolkodott-e a valós használatról. Volt egy eset, amikor a megbízó azt mondta, az oldala szép, csak kevés a megkeresés. A javítási jegyzékből gyorsan kiderült, hogy a hiba nem az arculatban volt. A legfontosabb gomb három különböző felirattal szerepelt három oldalon. A fejlesztő ezt fél nap alatt javította, és utána az érdeklődések száma érezhetően nőtt. Nem csoda történt. Csak végre ugyanazt jelentette ugyanaz a gomb.

És fontos az is, hogy a fejlesztői lista ne keverje össze a kívánságot a hibával. A túl sok ötlet sokszor lassít. A teendőlista akkor jó, ha külön kezeli a valódi használhatósági hibákat és a későbbi fejlesztési ötleteket. Ezt sokan elmulasztják, és utána a fejlesztő nem tudja, mihez nyúljon először.

Gyakori gondok és javítási sorrend

A legtöbb oldalon ugyanazok a hibák térnek vissza. Zavaros menü. Gyenge vizuális sorrend. Túl hosszú űrlap. Bizonytalan visszajelzés kattintás után. Mobilon nehezen érhető elemek. És ott van a túl sok szöveg is. Sokan azt hiszik, minél több mindent írnak ki, annál biztosabban meggyőzik a látogatót. A valóság sokszor az ellenkezője. A látogató elveszíti a fonalat. Én jobban bízom a tiszta szerkezetben és a rövid, érthető utasításokban.

Egy jó javítási sorrend általában a kritikus útvonalról indul. Első képernyő, fő gomb, kapcsolatfelvétel, űrlap, mobil nézet. Csak utána jönnek a finomabb esztétikai kérdések. Szerintem ez azért fontos, mert sok tulajdonos fordítva kezd. Előbb színeket cserél, ikonokat keres, apró díszítéseket módosít, miközben az érdeklődő még mindig nem tudja, hol kell kattintania. Olcsóbbnak tűnik a felszínhez nyúlni, de végül többe kerül.

Sok hibajegyzék ott romlik el, hogy nem írja le a kiváltó helyzetet. Pedig nem ugyanaz, ha valaki új látogatóként érkezik, vagy ha már olvasott három aloldalt. A használhatósági szakember akkor dolgozik jól, ha figyeli a teljes útvonalat. Az első benyomást, a görgetést, a döntési pontot és a lezárást is. A fejlesztőnek ebből lesz valóban használható javítási anyaga.

Javítási lista árak

A javítási lista fejlesztőknek ára több tényezőtől függ. Számít, hány oldalt kell átnézni, készül-e részletes hibajegyzék, van-e képernyőképes jelölés, külön vizsgálják-e a mobil és az asztali nézetet, valamint kap-e a megbízó javítási sorrendet is. Az én tapasztalatom az, hogy a túl olcsó ajánlat általában rövid és felszínes. 15.000 forint alatt ritkán készül olyan anyag, amelyből a fejlesztő tényleg önállóan tud dolgozni. De a magas ár önmagában nem erény. Sokszor pont a közepes árú, jól strukturált anyag a leghasznosabb.

Olcsóbban persze lehet találni gyors áttekintést. De őszintén szólva én óvatos vagyok vele. A nagyon alacsony ár sokszor azt jelenti, hogy nincs priorizálás, nincs hatásleírás, és a javítási jegyzék inkább csak megjegyzésekből áll. A fejlesztőnek viszont döntési anyag kell, nem homályos benyomás.

Ezek reális sávok magánszakemberek munkájára. Drágábban is lehet találni ajánlatot, de szerintem a lényeg nem az összeg, hanem az átadhatóság. Ha a fejlesztő első olvasásra érti, mit kell csinálnia, akkor az anyag jó eséllyel megérte az árát.

Milyen szakembert érdemes választani

Fejlesztői javítási lista készítéséhez nem elég valaki, aki szépen beszél a felhasználói élményről. Olyan UX szakértő vagy használhatósági szakember kell, aki tömören fogalmaz, tud súlyosságot adni, és nem keveri össze a problémát a véleménnyel. Én mindig azt nézném meg először, hogy a szakember hogyan mutat be egy korábbi hibajegyzéket. Érthető-e. Van-e benne döntési sorrend. És ki tudja-e mondani, hogy melyik hiba valóban kritikus.

Sokan elkövetik azt a hibát, hogy csak portfólió alapján választanak. Ez kevés. Egy mutatós felület még nem jelenti azt, hogy az illető jó fejlesztői anyagot tud készíteni. Nekem az a szakember szimpatikus, aki kérdez a célról, a látogatók típusáról, a forgalom fő forrásáról és arról, hogy ki fogja végrehajtani a javításokat. Mert nem mindegy, hogy a fejlesztő tapasztalt, vagy inkább csak egyszerűbb oldalakat kezel.

Volt már olyan helyzet is, amikor a megbízó három külön listát kapott három embertől. Az egyik tele volt idegen szavakkal. A másik túl rövid volt. A harmadik viszont egyszerűen fogalmazott, és minden hibához odatette a várható hatást. A fejlesztő végül csak az utóbbiból tudott rendesen dolgozni. Ezért mondom, hogy a jó hibajegyzék nem feltűnően okos, hanem használható.

Fejlesztői teendőlista Budapest és környéke

Budapest esetében a helyi szolgáltatói oldalaknál különösen fontos, hogy a területi információk világosak legyenek. Sok felhasználó gyorsan azt akarja látni, hogy a szolgáltatás elérhető-e a XI. kerületben, Zuglóban, Óbudán vagy a budai agglomerációban. Ha ez el van rejtve, az ugyanúgy felhasználói hiba, mint egy rossz gombfelirat. A fejlesztői teendőlista ezért helyi oldalaknál gyakran tartalmaz területi blokkokra, kapcsolatfelvételi részekre és mobil első képernyőre vonatkozó javításokat is.

Budapest környékén sok oldal mobilról kapja a látogatók nagy részét. Ilyenkor a kattintható telefonszám, a rövid űrlap és a látható időpontkérés fontosabb, mint egy látványos felső kép. Szerintem ezt sok tulajdonos még mindig alábecsüli. Pedig a helyi érdeklődő nem akar sokáig keresgélni. Tudni akarja, hogy az adott szakember merre dolgozik, hogyan lehet írni neki, és mennyi idő alatt kap választ.

És itt jön a valódi haszon. A javítási lista fejlesztőknek nem csak hibát sorol. Segít abban is, hogy a helyi érdeklődő ne vesszen el az oldalon. Ha a kerületek, a kiszállási terület, a gombok és az űrlap logikusan kerülnek a helyükre, az oldal nyugodtabb lesz. Nem hangosabb. Nem díszesebb. Csak tisztább. Én ezt többre tartom, mint egy új külsőt, amely mögött ugyanazok a régi gondok maradnak.