Hogyan örüljünk a felhasználóknak, ha jelentõs frissítést adunk ki az alkalmazáshoz

Boldog Ügyfél

A termékfejlesztésben benne rejlik a feszültség a fejlesztés és a stabilitás között. Egyrészt a felhasználók új funkciókra, funkcionalitásra és talán még új megjelenésre számítanak; másrészt a változások visszaüthetnek, ha az ismert interfészek hirtelen eltűnnek. Ez a feszültség akkor a legnagyobb, ha egy terméket drámai módon változtatnak meg - olyannyira, hogy akár új terméknek is lehetne nevezni.

At CaseFleet ezekből a tanulságokból néhányat keményen megtanultunk, bár a fejlődésünk nagyon korai szakaszában. Kezdetben alkalmazásunk navigációja az oldal tetején található ikonok sorában található:

Casefleet navigáció

E választás esztétikai értéke ellenére kissé korlátozottnak éreztük a rendelkezésre álló hely mennyiségét, különösen akkor, amikor felhasználóink ​​kisebb képernyőkön vagy mobileszközökön nézték az alkalmazást. Egy nap az egyik fejlesztőnk hétfő reggel érkezett dolgozni egy be nem jelentett hétvégi projekt gyümölcseivel: az elrendezés változásának koncepciójának bizonyítéka. A változás lényege, hogy a navigációt a képernyő tetején lévő sorból a bal oldali oszlopba mozgatja:

Casefleet bal navigáció

Csapatunk úgy gondolta, hogy a design fantasztikusan néz ki, és néhány utolsó simítás hozzáadása után azon a héten kiadtuk a felhasználóinknak, arra számítva, hogy el lesznek ragadtatva. Tévedtünk.

Míg egy maroknyi felhasználó azonnal elfogadta a változást, jelentős részük egyáltalán nem volt boldog, és arról számolt be, hogy nehézségei vannak az alkalmazás körüli mozgásban. A legnagyobb panaszuk azonban nem az volt, hogy nem tetszett nekik az új elrendezés, hanem az, hogy ez elrugaszkodott.

Tanulságok: A Done Right változtatása

A következő alkalommal, amikor megváltoztattuk az alkalmazást, sokkal más folyamatot használtunk. A legfontosabb meglátásunk az volt, hogy a felhasználók szeretik irányítani a sorsukat. Amikor fizetnek az alkalmazásodért, okkal teszik ezt, és nem akarják, hogy kincses funkcióikat elvegyék tőlük.

Miután elkészítettük az újonnan tervezett kezelőfelületünket, nem egyszerűen kiadtuk. Ehelyett írtunk róla egy blogbejegyzést, és képernyőképeket osztottunk meg felhasználóinkkal.

Casefleet Design Change Email

Ezután hozzáadtunk egy gombot az alkalmazás üdvözlő képernyőjéhez nagy címsorral, néhány gondosan kidolgozott példánnyal és egy nagy narancssárga gombbal, amely a felhasználókat az új verzió kipróbálására hívja. Megjegyeztük azt is, hogy visszaállhattak az eredeti verzióra, ha akarták (amúgy is egy ideig).

Miután a felhasználók az új verzióban voltak, a visszaállításhoz szükséges lépések több kattintással elérhetőbbek voltak a felhasználó profilbeállításaiban. Nem akartuk elrejteni a gombot a visszatéréshez, de azt sem gondoltuk, hogy hasznos lenne, ha az emberek többször egymás után váltanának, ami csábító lehet, ha a gomb azonnal látható. Valójában csak egy felhasználó fordult vissza az egy hónapos feliratkozási időszak alatt. Sőt, mire átfordítottuk a kapcsolót és kötelezővé tettük az új verziót, szinte az összes legaktívabb felhasználónk átállt, és nagyszerű visszajelzést adott nekünk az új verzióról.

Az átálláshoz biztosított alkalmazáson belüli ösztönzők mellett számos e-mailt küldtünk, amelyekben pontosan tájékoztattuk a felhasználókat arról, hogy mikor állandósul az új verzió módosítása. Senkit nem sikerült elkapni, és senki sem panaszkodott. Valójában a legtöbb felhasználó rendkívül elégedett volt az új megjelenéssel.

Érdemes kihívások

Ennek ellenére fontos megjegyezni, hogy egy frissítés ilyen módon történő kiadása nem ingyenes. Fejlesztői csapatának ugyanazon kódbázis két külön verzióját kell fenntartania, és összetett problémákat is meg kell oldania a verziók végfelhasználóknak történő elküldésével kapcsolatban. Fejlesztői és minőségbiztosítási csapata kimerül a folyamat végére, de valószínűleg egyet fog érteni abban, hogy az idő és az erőforrások befektetése okos volt. A hiperversenyű szoftverpiacokon meg kell örülnie a felhasználóknak, és nincs gyorsabb módja annak, hogy boldogtalanná tegye őket, mint hirtelen megváltoztatni a kezelőfelületet.

2 Comments

  1. 1

    Általában az új alkalmazás frissítésekor meg kell győződnünk arról, hogy a régi továbbra is aktív módban van, amíg az emberek nem frissítik azt újabb verzióra. Bármilyen rossz tapasztalat arra kényszeríti a felhasználót, hogy lemondjon a szolgáltatásairól. Nagyon fontos az üzleti élet számára, hogy tudatában legyen ennek a tudatosságnak, mielőtt új alkalmazást indítana.

    Ezenkívül kérje meg az embereket, hogy adjanak visszajelzést. Az új bevezetés az az idő, amikor az emberek szívesen megosztják gondolataikat az alkalmazásról. Ha valami újat gondolnak, akkor megosztják veled. Új lehetőséget teremt a fejlesztőnek, hogy felvegye azt a funkciót, amelyet az emberek javasolnak.

    Köszönöm

  2. 2

    Amikor e-mailt küldünk ügyfelünknek a webhely jelentős változásairól. Fenntartjuk, hogy a régi webhelyet is elérjék, ha akarják. Ez kényelmessé teszi őket a böngészés közben. Néhány felhasználónak nem biztos, hogy tetszik az új dizájn, így az ilyen felhasználók könnyen áttérhetnek a régebbi verzióra.

Mit gondolsz?

Ez az oldal Akismet-et használ a levélszemét csökkentése érdekében. Ismerje meg, hogyan dolgozik a megjegyzésed.