Induljon ki a vásárló feladatából
Az Android azt javasolja, hogy akkor kérjünk hozzáférést, amikor az adott funkciónak szüksége van rá; az Apple pedig azt, hogy az értesítési kérések célját a használati helyzet tegye érthetővé. Alkalmazzuk ezeket az elveket egy képzeletbeli budapesti pékségre, amely személyes átvételhez készít alkalmazást. Vásárlóinak üzletet kell választaniuk, kenyeret rendelniük, és tudniuk kell, mikor vehetik át a rendelést.
A pékség a kézi üzletválasztó lista mellett felajánlhatná a közeli üzlet gyors megkeresését. A rendelés elfogadása után pedig értesítést kínálhatna arról, amikor az elkészül. Ez két különböző előny. Mindkettőhöz írjon külön magyarázatot, a vásárlási folyamat többi részével egyező nyelvezettel.
Elutasítás után is működjön az alkalmazás
Ennél a pékségnél a helyadatok megtagadása után is elérhetőnek kell maradnia az üzletlistának, a címekkel és a nyitvatartással együtt. Az értesítések elutasítása után is rendelkezésre kell állnia az átvétel módját bemutató rendelési képernyőnek. Egyik döntés sem törölheti a kosarat, és nem kényszerítheti ismét regisztrációra a vásárlót.
Kérje meg a fejlesztőcsapatot, hogy az ellenőrzés során mindkét útvonalat mutassa be. A gondosan megfogalmazott engedélykérés önmagában kevés, ha a következő képernyő üres. Az ügyfélszolgálat munkatársai is kapják meg ugyanezt a bemutatót: tudniuk kell elmagyarázni, hol található a rendelés, anélkül, hogy feltételeznék az értesítés megjelenését.
Az első változat terjedelmét igazítsa az igényekhez
Egy két üzlettel működő pékségnek elegendő lehet a kézi üzletválasztás. Az automatikus javaslatok kényelmesebbé teszik a használatot, de fejlesztési munkát és további karbantartandó helyzeteket is jelentenek. Mielőtt térképes integrációkra költene, vagy a gyorskeresést a megjelenés határidejéhez kötné, döntse el, hogy gyakori problémát old-e meg.
Ebben a példában az átvételi hely megtalálása nem indokolja a vásárló korábbi mozgásadatainak megőrzését. Rögzítse, hogy a helyadat feldolgozása az eszközön történik-e, vagy szerverre küldik; azt is, hogy mit őriznek meg, és miért. Az elkészült rendelésről szóló értesítés sem válhat észrevétlenül reklámcélú feliratkozássá. Ezeket a felhasználói beállításokat külön határozza meg a fejlesztési leírásban.
Az ígéret feleljen meg a tényleges működésnek
A pékségnek el kell döntenie, ki jelöli késznek a rendelést, és mi történik, ha a munkatársak ezt elfelejtik. Az értesítési funkció nem oldja meg a tisztázatlan konyhai folyamatokat. Állapodjanak meg abban, melyik rendelési állapotban bízhatnak a vásárlók, és az átvételi útmutató maradjon elérhető az alkalmazásban.
Kerülje az olyan szöveget, amely minden értesítés észlelését ígéri. Az Apple dokumentációja ismerteti a módosítható értesítési beállításokat; az Androidé a visszavont engedélyek kezelését. A csapat magyarázza el a tényleges működést minden támogatott platformon. Az egységes látványterv ne fedje el a rendszer párbeszédablakai vagy az elérhető beállítások közötti különbségeket.
Használjon rövid átvételi ellenőrzőlistát
Megjelenés előtt ellenőrizze a folyamatot a támogatni kívánt telefonokon és nyelveken. Minden hibához rendeljen felelőst, és a következő kiadáshoz őrizzen meg egy rövid felvételt a kijavított folyamatról.
- Induljon friss telepítésből, és ellenőrizze az engedélyezést és az elutasítást is.
- Módosítsa az engedélyeket az eszköz beállításaiban, térjen vissza, és ellenőrizze az üzlet- és rendelési képernyőket.
- Győződjön meg arról, hogy a kézi választás és a rendelés részletei továbbra is könnyen megtalálhatók.
- Ellenőrizze, hogy a lefordított magyarázatok ugyanazt az előnyt és az elutasításkor használható megoldást írják-e le.
- Szimulálja a rendelés elkészülését, és ellenőrizze a vásárlók és a munkatársak által látható felületeket.