Egy átláthatatlan alkalmazás diagnosztizálásához vizsgálja meg annak képernyőit, vezérlőelemeit és válaszait, miközben valaki megpróbál elvégezni egy, az alkalmazás által támogatott feladatot. Figyelje meg az első pontot, ahol a következő művelet bizonytalanná válik. Hasonlítsa össze a személy várakozását azzal, amit az alkalmazás tesz és jelez. A sikertelen mentés vagy egy hiányzó funkció más javítást igényel, mint egy nem egyértelmű címke vagy útvonal.
Képzeljen el valakit, aki egy már létező foglalást próbál módosítani. Több menüt megnyit, visszatér a kezdőképernyőre, majd megkérdez egy kollégát. Ez a folyamat egy megfigyelés kiindulópontja. Önmagában nem magyarázhatja meg, hogy az illető később eltávolítja-e az alkalmazást, vagy melyik képernyőt kell újratervezni.
Miért veszítik el az emberek a következő lépést?
Az emberek érthetik a célt, mégis elvéthetnek egy nem egyértelmű műveletet vagy választ. Az első látható eltérést keressük a végrehajtani kívánt feladat és a megjelenő képernyő között. Hagyja nyitva a magyarázatot a művelet ellenőrzéséig. Ami navigációs problémának tűnik, lehet sikertelen kérés vagy a termék által nem támogatott eredmény is.
A szövegezés más műveletre utal. A személy a Folytatás elemre koppintva újabb áttekintő képernyőt várhat, miközben az alkalmazás azonnal elküld egy kérést. Az Apple gombokra vonatkozó útmutatója a cél egyértelművé tételét javasolja. Mielőtt másik címkét választana, hasonlítsa össze a várakozást a tényleges hatással.
Az eredmény bizonytalan marad. Valaki újra koppint, mert nem tudja eldönteni, hogy az alkalmazás elfogadta-e a kérést. Vizsgálja meg, mi lett ténylegesen mentve, és mit jelzett a képernyő. A hiányzó megerősítés és a sikertelen művelet eltérő javítást igényel.
Az adatbeviteli útmutatás a hiba után érkezik. Ellenőrizze, hogy a mező elmagyarázza-e, milyen értékre van szüksége.
Webes tartalom esetében a W3C címkékre vagy utasításokra vonatkozó kritériuma címkéket vagy utasításokat követel meg, amikor a tartalom adatbevitelt igényel. Ezt a hivatkozást az alkalmazáson belüli webes képernyőkhöz használja. A natív alkalmazásokhoz külön platformszintű felülvizsgálat szükséges.
Az útvonal elveszíti a környezetét. Valaki visszatér egy részletező képernyőről, de nem találja meg ismét a módosított elemet. Rögzítse ezt a kiindulópontot, a választott műveletet és az eredményül kapott képernyőt. Az első zavaros átmenetet olyan pontosan írja le, hogy reprodukálható legyen.
Hogyan diagnosztizáljon egy átláthatatlan alkalmazást?
Kezdje egy támogatott eredménnyel és egy összehasonlítható kezdőállapottal. Használjon tesztfiókot és biztonságos tesztadatokat azokhoz a műveletekhez, amelyek küldenek, terhelnek, törölnek vagy más személyt érintenek. Fogalmazza meg a célt anélkül, hogy megnevezné az oda vezető menüt vagy vezérlőelemet. Azt szeretné megtudni, hogy mit talál meg és ért meg a személy, mielőtt magyarázattal segítené.
- Határozza meg a teljesítést. Egy foglalás módosításánál a kívánt eredmény egy elküldött kérés vagy egy megerősített új foglalás? Ellenőrizze, hogy ez a verzió és fiók melyik eredményt támogatja.
- Rögzítse a kezdőállapotot. Jegyezze fel az alkalmazás verzióját, az eszközt, a nyelvet, az engedélyeket és azt, hogy a foglalás már létezik-e. Egy rendszergazdai fiók más útvonalat jeleníthet meg, mint egy ügyfél fiókja.
- Figyelje meg a vezérlőelem megnevezése nélkül. Kérje meg a személyt, hogy próbálja elérni a célt. Rögzítse a választott képernyőt, az elolvasott címkét és a személy várakozását. Ha segít, jegyezze fel a segítséget. A későbbi teljesítés nem törli azt.
- Külön ellenőrizze az eredményt. Hasonlítsa össze a látható választ a mentett foglalással. Nyissa meg újra a tesztfiókban, vagy ellenőrizze a szolgáltató tesztrekordját. Egy koppintás vagy sikeresnek látszó képernyő nem bizonyítja, hogy a kívánt frissítés megtörtént.
Ha egyedül vizsgálja az alkalmazást, rögzítse, amit reprodukálni tud, és tegye láthatóvá ezt a korlátozást. A termékről meglévő tudása megváltoztatja a feladatot. Egy későbbi megfigyelés, amelyben a terméket nem ismerő személy vesz részt, más bizonyítékot szolgáltat.
Dolgozza fel ezt a kitalált foglalási feladatot
Képzeljen el egy kitalált órafoglaló alkalmazást, amelyben valaki másik alkalmat kérhet. A szolgáltatónak el kell fogadnia a kérést, mielőtt a foglalás megváltozik. Az alábbi jegyzetek bemutatják, hogyan vizsgálható meg egy félreértés. Ehhez a példához nem használtunk működő alkalmazást, fiókot vagy résztvevőt, és nem teszteltük a javasolt szövegezést.
| Megfigyelés | Megjegyzés |
|---|---|
| Kívánt feladat | Egy meglévő órafoglalás áthelyezése másik alkalomra. |
| Művelet és pontos címke | A személy a Foglalás módosítása elemre koppint; a gomb egy kérést küld. |
| Várt eredmény | A személy úgy gondolja, hogy az új alkalom már le van foglalva. |
| Tényleges állapot | Az eredeti foglalás marad érvényben, amíg a kérés elfogadásra vár. |
| Javasolt ellenőrzés | Próbálja ki a Módosítás kérése címkét és egy üzenetet, amely szerint a kérés elküldve. |
A megfigyelt eltérés a művelet jelentésére vonatkozik. Egy eltérő címke olyan hipotézis, amelyet a tényleges művelettel összevetve kell tesztelni. Ha a kérés soha nem jut el a szolgáltatóhoz, vizsgálja meg a sikertelen műveletet is. Ha az azonnali megerősítés elengedhetetlen a termékhez, az külön termékdöntés, nem pedig valami, amit egy gomb címkéje biztosíthat.
Az értelmezés előtt írja le a megfigyelést. A “Megnyitotta a foglalást, a Foglalás módosítása elemre koppintott, és megerősítést várt” viselkedést ír le ebben a kitalált gyakorlatban. “A felület rossz” kihagyja azt a kérdést, amelyet még meg kell válaszolnia.
A megfigyelést megválaszoló legkisebb változtatást végezze el
Olyan javítást válasszon, amely kezeli a rögzített eltérést, és megőrzi a kívánt műveletet. Ha a szövegezés, az utasítás vagy a visszajelzés bizonytalan, kezdje ezekkel. A navigációs szerkezet módosításához vagy egy szélesebb körű újratervezéshez a feladaton alapuló indok szükséges. Tartsa láthatóan a működési hibákat, hogy egy világosabb magyarázat ne rejtse el a továbbra is sikertelen műveletet.
-
Próbáljon ki egy célzott tervet. A kitalált foglaláshoz mutasson be egy javasolt műveletcímkét és az abból eredő állapotot egy kattintható tervben. Alkalmazásokhoz készült UX-ellenőrzéseink és prototípusaink ezt a feladattól a prototípusig vezető folyamatot követik. Hasonlítsa össze, hogy a személy mit vár a koppintás előtt, és milyen állapotot ismer fel utána. Ne írja le a javasolt címkét bizonyított javulásként.
-
Ellenőrizzen egy hibautat. A W3C webes tartalomra vonatkozó hibaazonosítási kritériuma megköveteli, hogy egy automatikusan észlelt beviteli hiba azonosítsa az érintett elemet, és szövegesen leírja a hibát. A színes körvonal önmagában nem adja meg ezt a magyarázatot. A natív vezérlőelemek és a teljes akadálymentességi felülvizsgálat saját platformellenőrzéseket igényelnek.
-
Ellenőrizze a képernyőn és a kisegítő technológiával adott választ. Webes tartalom esetében a W3C állapotüzenetekre vonatkozó kritériuma azt tárgyalja, hogyan tehetők a meghatározott állapotváltozások elérhetővé a kisegítő technológia számára anélkül, hogy a fókusz elmozdulna az aktuális vezérlőelemről. Ellenőrizze, mi jelenik meg a képernyőn, és mit érzékelnek a kisegítő eszközök. A képernyőolvasó például olyan szoftver, amely hangosan fel tudja olvasni a felület tartalmát. Ez a kiválasztott kritérium nem tanúsítja az alkalmazást, nem határoz meg válaszidőcélt, és nem javítja ki a lassú műveletet.
-
Kövesse a webes átmenetet. Ha ugyanannak a fióknak vagy foglalásnak az útvonala egy weboldalon folytatódik, ezt az átmenetet is foglalja bele a tesztbe. A webhely- és webalkalmazás-fejlesztésnek ezen a határon át is meg kell őriznie a feladat szövegezését és a valós állapotot.
Mit ellenőrizzen a változtatás után?
Ismételje meg ugyanazt a kívánt feladatot összehasonlítható állapotból, és rögzítse, mi történt. Az eredmény mellett tartsa láthatóan az alkalmazás verzióját, az eszközt, a nyelvet és a segítséget. Egy hasznos összehasonlítás az Ön által megfigyelt feladatra vonatkozik: megtalálta-e a személy a műveletet, megértette-e annak hatását, és felismerte-e a tényleges eredményt. Minden tágabb üzleti következtetést hagyjon nyitva addig, amíg nincs rá bizonyítéka.
A teljesítést és a segítséget együtt rögzítse, továbbá az első rossz irányt, a személy által nem értelmezhető beviteli hibákat, valamint azt, hogy összetévesztett-e egy kérést egy megerősítéssel. Ismételje meg a releváns ellenőrzéseket az éppen vizsgált nyelvvel és akadálymentességi beállítással. Vizsgálja meg a hosszabb címkéket és az adott beállításon keresztül elérhető információkat, ahelyett hogy azt feltételezné, az angol képernyő minden verziót képvisel.
Ha már rögzíti az alkalmazás műveleteit, például egy foglalásmódosítási kérés elindulását vagy a szolgáltatóhoz érkezését, ellenőrizze, hogy a rekordok megfelelnek-e ezeknek a tényleges állapotoknak. Ugyanezen útvonal mellett kövesse a támogatási kérdések változásait. Az alkalmazásletöltések hiánya külön ügyfélszerzési probléma; a letöltések nélküli alkalmazásról szóló útmutatónk még azelőtt kezdődik, hogy valaki megnyitná a terméket.
A sikeres ismétlés leírhatja ezt a megfigyelést. Nem állapíthatja meg, hogy az emberek miért távolítják el az alkalmazást, és a megtartás változását sem tulajdoníthatja a javításnak. Rögzítse a következő megoldatlan kérdést az ellenőrzéséért felelős személlyel együtt.
Hogyan segítünk
A támogatott feladattal, az első nem egyértelmű átmenettel és a javítás kiválasztásához szükséges bizonyítékokkal kezdünk. Ezekből prototípust készíthetünk, ellenőrizhetjük a megvalósított útvonalat, és bevonhatjuk annak webes megfelelőjét. Hozza el a feladat leírását és az elakadás pontját egy projektmegbeszélésre. Távolítsa el az ügyfelek nevét és más személyes adatokat minden megosztott példából.
