Kun haluat selvittää epäselvän sovelluksen ongelmaa, tarkastele sen näkymiä, käyttöliittymäelementtejä ja reaktioita samalla, kun joku yrittää suorittaa sovelluksen tukemaa tehtävää. Etsi ensimmäinen kohta, jossa seuraava toiminto muuttuu epäselväksi. Vertaa henkilön odotusta siihen, mitä sovellus tekee ja ilmoittaa. Epäonnistunut tallennus tai puuttuva ominaisuus tarvitsee eri korjauksen kuin epäselvä teksti tai reitti.
Kuvittele, että joku yrittää muuttaa olemassa olevaa varausta. Hän avaa useita valikoita, palaa aloitusnäkymään ja kysyy työtoverilta. Tämä tapahtumaketju on havainnoinnin lähtökohta. Se ei yksin selitä, poistaako hän sovelluksen myöhemmin tai mikä näkymä pitäisi suunnitella uudelleen.
Miksi seuraava vaihe jää ihmisiltä löytämättä?
Ihmiset voivat ymmärtää tavoitteen mutta silti ohittaa epäselvän toiminnon tai reaktion. Etsimme ensimmäistä näkyvää ristiriitaa heidän aikomansa tehtävän ja kohtaamansa näkymän välillä. Älä lukitse selitystä ennen toiminnon tarkistamista. Navigointiongelmalta näyttävä tilanne voi olla myös epäonnistunut pyyntö tai lopputulos, jota tuote ei tue.
Sanamuoto viittaa toiseen toimintoon. Henkilö voi odottaa uutta tarkistusnäkymää napautettuaan Jatka, vaikka sovellus lähettää pyynnön heti. Applen painikeohjeistus suosittelee ilmaisemaan tarkoituksen selkeästi. Vertaa odotusta todelliseen vaikutukseen ennen korvaavan tekstin valitsemista.
Lopputulos jää epävarmaksi. Joku napauttaa uudelleen, koska hän ei tiedä, hyväksyikö sovellus pyynnön. Tarkista, mitä todella tallennettiin ja mitä näkymä ilmoitti. Puuttuva vahvistus ja epäonnistunut toiminto tarvitsevat eri korjaukset.
Syöteohje tulee virheen jälkeen. Tarkista, selittääkö kenttä tarvitsemansa arvon.
W3C:n verkkosisältöä koskeva labels-or-instructions-kriteeri edellyttää selitteitä tai ohjeita, kun sisältö vaatii syötettä. Käytä tätä viitettä sovelluksen sisäisiin verkkonäkymiin. Natiivisovellukset tarvitsevat erillisen alustakohtaisen tarkistuksen.
Reitti menettää asiayhteytensä. Henkilö palaa tietonäkymästä eikä löydä enää kohdetta, jota oli muuttamassa. Kirjaa lähtökohta, valittu toiminto ja sen jälkeinen näkymä. Kuvaa ensimmäinen epäselvä siirtymä niin täsmällisesti, että sen voi toistaa.
Miten diagnosoit epäselvän sovelluksen?
Aloita tuetusta lopputuloksesta ja vertailukelpoisesta lähtötilasta. Käytä testitiliä ja turvallista testidataa toiminnoissa, jotka lähettävät, veloittavat, poistavat tai vaikuttavat toiseen henkilöön. Kirjoita tavoite nimeämättä siihen johtavaa valikkoa tai käyttöliittymäelementtiä. Tarkoitus on selvittää, mitä henkilö löytää ja ymmärtää ennen kuin annat selityksen.
- Määritä valmistuminen. Onko varauksen muutoksen tarkoitettu lopputulos lähetetty pyyntö vai vahvistettu uusi varaus? Tarkista, kumpaa lopputulosta tämä versio ja tili tukevat.
- Kirjaa lähtötila. Merkitse sovellusversio, laite, kieli, käyttöoikeudet ja se, onko varaus jo olemassa. Ylläpitäjän tilillä voi näkyä eri reitti kuin asiakkaan tilillä.
- Havainnoi nimeämättä käyttöliittymäelementtiä. Pyydä henkilöä yrittämään tavoitteen saavuttamista. Kirjaa hänen valitsemansa näkymä, lukemansa teksti ja odotuksensa. Jos autat, merkitse apu muistiin. Myöhempi valmistuminen ei poista sitä.
- Tarkista lopputulos erikseen. Vertaa näkyvää reaktiota tallennettuun varaukseen. Avaa se uudelleen testitilillä tai tarkista palveluntarjoajan testitietue. Napautus tai onnistumiselta näyttävä näkymä ei osoita, että tarkoitettu päivitys tapahtui.
Jos tarkastat sovelluksen yksin, kirjaa toistettavissa olevat asiat ja pidä rajoitus näkyvänä. Tuotetuntemuksesi muuttaa tehtävää. Myöhempi havainnointi tuotetta tuntemattoman henkilön kanssa tuottaa erilaista näyttöä.
Käy läpi tämä kuvitteellinen varaustehtävä
Ajattele keksittyä tuntivaraussovellusta, jossa henkilö voi pyytää toista tuntia. Palveluntarjoajan on hyväksyttävä pyyntö ennen varauksen muuttumista. Alla olevat muistiinpanot havainnollistavat väärinkäsityksen tutkimista. Tässä esimerkissä ei ole käytetty toimivaa sovellusta, tiliä tai osallistujaa, eikä ehdotettua sanamuotoa ole testattu.
| Havainto | Muistiinpano |
|---|---|
| Aiottu tehtävä | Siirrä olemassa oleva tuntivaraus toiselle tunnille. |
| Toiminto ja tarkka teksti | Henkilö napauttaa Muuta varausta. Painike lähettää pyynnön. |
| Odotettu tulos | Henkilö uskoo, että uusi tunti on jo varattu. |
| Todellinen tila | Alkuperäinen varaus säilyy, kunnes pyyntö hyväksytään. |
| Ehdotettu tarkistus | Kokeile tekstiä Pyydä muutosta ja viestiä pyynnön lähettämisestä. |
Havaittu ristiriita koskee toiminnon merkitystä. Eri teksti on hypoteesi, jota on testattava todellista toimintoa vasten. Jos pyyntö ei koskaan saavu palveluntarjoajalle, tutki myös epäonnistunutta toimintoa. Jos välitön vahvistus on tuotteelle välttämätön, se on erillinen tuotepäätös eikä asia, jonka painikkeen teksti voi toteuttaa.
Kirjoita havainto ennen tulkintaa. “Avasi varauksen, napautti Muuta varausta ja odotti vahvistusta” kuvaa käyttäytymistä tässä kuvitteellisessa harjoituksessa. “Käyttöliittymä on huono” ohittaa kysymyksen, johon sinun on vielä vastattava.
Tee pienin muutos, joka vastaa havaintoon
Valitse korjaus, joka kohdistuu kirjattuun ristiriitaan ja säilyttää tarkoitetun toiminnon. Aloita sanamuodosta, ohjeista tai palautteesta, jos epävarmuus koskee niitä. Navigointirakenteen muutos tai laajempi uudistus tarvitsee tehtävään perustuvan syyn. Pidä toiminnalliset viat näkyvinä, jotta selkeämpi selitys ei peitä yhä epäonnistuvaa toimintoa.
-
Kokeile rajattua luonnosta. Näytä kuvitteellista varausta varten ehdotettu toimintoteksti ja sen jälkeinen tila napsautettavassa luonnoksessa. Sovellusten UX-auditointimme ja prototyyppimme noudattavat tätä etenemistä tehtävästä prototyyppiin. Vertaa henkilön odotusta ennen napautusta tilaan, jonka hän tunnistaa sen jälkeen. Älä kuvaa ehdotettua tekstiä todennettuna parannuksena.
-
Tarkista virhepolku. W3C:n verkkosisältöä koskeva error-identification-kriteeri edellyttää, että automaattisesti havaittu syötevirhe yksilöi virheellisen kohdan ja kuvaa virheen tekstinä. Pelkkä värillinen reunus jättää tämän selityksen puuttumaan. Natiivielementit ja kattava saavutettavuusarviointi edellyttävät omia alustakohtaisia tarkistuksiaan.
-
Tarkista reaktio näkymässä ja avustavalla teknologialla. W3C:n verkkosisältöä koskeva status-message-kriteeri käsittelee määriteltyjen tilamuutosten välittämistä avustavalle teknologialle siirtämättä kohdistusta pois nykyisestä käyttöliittymäelementistä. Tarkista, mitä näkymässä näkyy ja mitä apuvälineet voivat havaita. Esimerkiksi ruudunlukija on ohjelmisto, joka voi lukea käyttöliittymän sisältöä ääneen. Tämä yksittäinen kriteeri ei sertifioi sovellusta, aseta vasteaikatavoitetta eikä korjaa hidasta toimintoa.
-
Seuraa siirtymää verkkoon. Kun saman tilin tai varauksen reitti jatkuu verkkosivulle, sisällytä siirtymä testiin. Verkkosivustojen ja verkkosovellusten kehityksen pitäisi säilyttää tehtävän sanamuoto ja todellinen tila tämän rajan yli.
Mitä muutoksen jälkeen pitäisi tarkistaa?
Toista sama aiottu tehtävä vertailukelpoisesta tilasta ja kirjaa tapahtumat. Pidä sovellusversio, laite, kieli ja annettu apu näkyvillä tuloksen yhteydessä. Hyödyllinen vertailu koskee havainnoimaasi tehtävää: löysikö henkilö toiminnon, ymmärsikö hän sen vaikutuksen ja tunnistiko hän todellisen lopputuloksen. Jätä laajemmat liiketoimintapäätelmät avoimiksi, kunnes niistä on näyttöä.
Kirjaa valmistuminen ja apu yhdessä, ensimmäinen väärä käännös, syötevirheet, joita henkilö ei osannut tulkita, sekä se, sekoittiko hän pyynnön vahvistukseen. Toista olennaiset tarkistukset tarkasteltavalla kielellä ja saavutettavuusasetuksilla. Tarkasta pidemmät tekstit ja asetusten kautta saatavat tiedot sen sijaan, että olettaisit englanninkielisen näkymän edustavan kaikkia versioita.
Jos jo tallennat sovelluksen toimintoja, kuten varauksen muutospyynnön alkamisen tai saapumisen palveluntarjoajalle, tarkista, että tietueet vastaavat näitä todellisia tiloja. Tarkastele tukikysymysten muutoksia saman reitin rinnalla. Sovelluksen latausten puuttuminen on erillinen käyttäjähankinnan ongelma. Oppaamme sovelluksesta, joka ei saa latauksia alkaa ajasta ennen tuotteen avaamista.
Onnistunut uusintakierros voi kuvata kyseisen havainnon. Se ei voi osoittaa, miksi ihmiset poistavat sovelluksen, eikä liittää käyttäjien säilymisen muutosta korjaukseen. Kirjaa seuraava ratkaisematon kysymys ja sen tarkistamisesta vastaava henkilö.
Miten voimme auttaa
Aloitamme tuetusta tehtävästä, ensimmäisestä epäselvästä siirtymästä ja korjauksen valitsemiseen tarvittavasta näytöstä. Voimme muuttaa tämän prototyypiksi, tarkistaa toteutetun reitin ja sisällyttää sen verkkovastineen. Tuo tehtävän kuvaus ja pysähtymiskohta projektikeskusteluun. Poista jakamistasi esimerkeistä asiakkaiden nimet ja muut henkilötiedot.
