Cum să lansați funcții noi fără a răni utilizatorii fideli

„Fii agil; eliberare devreme; eliberați des.” Știm burghiul. Dar este înțelept din punct de vedere strategic să continuați să lansați funcții des? Mai ales odată ce un produs pe care îl construiți atinge o anumită dimensiune, probabil că nu doriți să riscați integritatea aplicației dvs. cu fiecare nouă lansare minoră.

Cel mai rău lucru care se poate întâmpla cu produsul dvs. este că utilizatorii fideli, clienții care au folosit acea mică funcție în mod constant de-a lungul anilor, brusc nu o pot folosi în același mod convenabil. Schimbarea ar putea da mai multă putere utilizatorilor, dar experiența devine mai puțin simplă. Frustrarea și anxietatea intră în rețelele sociale rapid și brusc, iar presiunea asupra asistenței clienților pentru a răspunde în mod semnificativ și în timp crește cu fiecare minut. Desigur, nu dorim să lansăm noi funcții doar pentru a ne da seama că de fapt rănesc utilizatorii fideli.

Citiți suplimentare despre SmashingMag: Link

• Cum am început să lansăm funcții de două ori mai repede
• Lista de verificare a lansării site-ului web – 15 verificări esențiale înainte de a începe
• O abordare centrată pe utilizator a designului web pentru dispozitive mobile
• Cum să lansați orice

Putem preveni acest lucru fiind mai strategici atunci când lansăm versiuni noi ale produselor noastre. În acest articol, vom analiza o strategie pentru proiectanții de produse și inginerii front-end pentru a testa și implementa în detaliu o funcție înainte de a o lansa pentru întreaga bază de utilizatori și cum să evităm problemele UX să apară pe drum.

Înainte de a aborda o strategie reală de testare, să facem un pas înapoi și să examinăm concepțiile greșite comune cu privire la modul în care este proiectată, construită și, în cele din urmă, implementată o nouă funcție.

Concepții greșite pentru funcții noi

Ori de câte ori este proiectată o nouă caracteristică pentru un produs existent, accentul principal este de obicei asupra modului în care ar trebui să fie integrată în interfața existentă. Pentru a obține coerență, noi, designerii, vom analiza adesea modelele existente și vom aplica limbajul de design stabilit pentru a face noua caracteristică să se afle bine în interfața de utilizare. Cu toate acestea, problemele apar adesea nu pentru că componentele nu funcționează împreună vizual, ci mai degrabă pentru că se dovedesc a fi confuze sau ambigue atunci când sunt combinate în moduri neașteptate .

Poate că copia interfeței este ambiguă în zonele înrudite, dar îndepărtate ale site-ului web, sau rezultatul a două caracteristici care sunt utilizate activ în același timp are sens din perspectivă tehnică, dar nu se potrivește cu așteptările utilizatorilor sau are implicații majore de performanță și dăunează UX. .

De fapt, în design, aceste numeroase combinații sunt atât de dificil de anticipat și de revizuit. O modalitate de a aborda problema în timpul procesului de proiectare este luarea în considerare a valorii aberante - cazuri de utilizare în care este mai probabil ca lucrurile să meargă prost. Cum ar arăta un profil de utilizator dacă numele utilizatorului este foarte lung? O privire de ansamblu asupra e-mailurilor fără răspuns este încă evidentă atunci când sunt folosite o duzină de etichete în căsuța de e-mail? Ar avea sens un filtru nou pentru utilizatorii care tocmai s-au înscris și au doar câteva e-mailuri în căsuța de e-mail?

Proiectarea valorilor aberante: stiva de interfețe cu utilizatorul

Cum anume putem proiecta valorile aberante odată ce le-am identificat? O strategie bună este studierea diferitelor stări ale interfeței cu utilizatorul. „Stiva de interfețe cu utilizatorul”, o idee introdusă de Scott Hurff, este versatilă și complicată, iar atunci când ne proiectăm interfețele, de obicei nu este suficient să cream o machetă perfectă a pixelilor în Photoshop, Sketch sau HTML și CSS - trebuie să luăm în considerare diverse cazuri și stări de margine: starea necompletată, starea de încărcare, starea parțială, starea de eroare și starea ideală. Acestea nu sunt atât de simple pe cât am putea crede.

Starea necompletată nu trebuie să fie neapărat goală – am putea folosi lucrători de servicii pentru a oferi o experiență offline mai bună vizitatorilor obișnuiți. Starea parțială nu trebuie să fie întreruptă - am putea îmbunătăți experiența cu imagini rupte și JavaScript rupt prin îmbunătățirea progresivă.

Starea ideală poate diferi semnificativ de modelele noastre „rezultat perfect” – datorită preferințelor personalizate ale utilizatorului și alegerii browserului utilizatorului; este posibil ca unele conținuturi și fonturi web să nu fie afișate din cauza configurației unui browser, de exemplu.

Deci, peisajul este, ca întotdeauna, complex, contorsionat și imprevizibil și nu putem face ca riscul ca lucrurile să meargă prost să fie neglijabil, dar asta nu înseamnă că nu putem minimiza riscul în mod eficient. Explorând valorile aberante și întreaga stivă de interfețe cu utilizatorul de la început, putem preveni problemele comune de UX în faza incipientă de proiectare. Totuși, nu devine mai ușor din punct de vedere tehnic.

Efectul fluture în desfășurare

Chiar și modificările minore tind să ducă la reacții în lanț, introducând bug-uri în zone și situații care par a fi absolut fără legătură. Motivul principal pentru aceasta este cantitatea mare de variabile care influențează experiența utilizatorului, dar care sunt în afara controlului nostru. Cunoaștem modurile noastre cu browserele, dar asta nu înseamnă că știm mai multe despre contextul în care un utilizator alege să vadă site-ul web pe care l-am creat atât de neobosit și amănunțit.

Acum, în timp ce modificări minore, cum ar fi căptușeala unui buton sau o zonă de text îmbunătățită progresiv, ar putea să nu pară mare lucru, avem tendința să subestimăm impactul acestor mici modificări sau caracteristici strălucitoare la scară largă. De fiecare dată când luăm o decizie de proiectare sau dezvoltare, schimbarea respectivă are un anumit efect asupra sistemului complex pe care îl construim, mai ales pentru că componentele pe care le construim nu există niciodată izolat.

Realitatea este că nu construim niciodată un buton și nici nu scriem niciodată o nouă funcție JavaScript - butoanele și funcțiile aparțin unei familii de componente sau biblioteci și toate funcționează într-o anumită setare și sunt inevitabil conectate la alte părți ale sistemului după proprietățile lor sau prin sfera lor de aplicare sau după numele lor sau după convențiile nescrise ale echipei.

Aceste conexiuni „tăcute,” cu greu vizibile sunt motivul pentru care lansarea funcțiilor este dificilă și pentru care prezicerea consecințelor de amploare ale unei schimbări se dovedește adesea a fi un exercițiu de vedere aprofundată. De aceea, este o idee bună să evitați dependențele inutile pe cât posibil, fie că este vorba de CSS sau JavaScript - nu vă vor ajuta cu întreținerea sau depanarea, mai ales dacă vă bazați pe o bibliotecă pe care nu o înțelegeți pe deplin. .

Din fericire, pentru a înțelege mai bine impactul unei schimbări, putem folosi resurse precum instrumentele de dezvoltare ale unui browser. Putem măsura acoperirea unui selector sau a unei funcții JavaScript și, uneori, ar putea fi o idee bună să revenim la acesta în timpul dezvoltării pentru a menține domeniul de aplicare al modificării cât mai local și minim posibil.

Acest lucru este util, dar este și doar o parte a poveștii. Facem presupuneri, conștient și inconștient, pe baza propriei noastre experiențe cu interfața și propriile noastre obiceiuri – uitând adesea că presupunerile pot (și, prin urmare, vor ) varia semnificativ de la utilizator la utilizator. Majoritatea aplicațiilor au o singură interfață, dar această interfață sau configurațiile sale pot avea zeci de stări - cu vizualizări care se schimbă în funcție de setările și preferințele utilizatorului.

Gândiți-vă la tablouri de bord cu carduri care pot fi personalizate (software de analiză), clienți de e-mail cu vizualizări „compacte”, „comode” și „detaliate” (Gmail), o interfață de rezervare care se schimbă pentru clienții autentificați și pentru oaspeți, o experiență de lectură pentru persoanele care folosesc un blocant de anunțuri sau un filtru antivirus agresiv. Efectul fluture are un impact asupra mai mult decât baza codului; toți acești factori externi cântăresc și ei, iar testarea împotriva lor - spre deosebire de testele unitare sau QA în general - este foarte dificilă, deoarece de multe ori nici măcar nu știm cu ce să testăm.

Validare caracteristică și maxim local

Putem folosi diagnostice și valori pentru a determina ce modificări trebuie făcute, dar doar urmărind datele, s-ar putea să ajungeți să stagneți la ceea ce avem tendința de a numi un „maxim local”, o stare a interfeței cu un design suficient de bun, dar care îi lipsește cu desăvârșire inovația, deoarece urmează întotdeauna iterații previzibile, logice. Când lucrăm la un proiect și explorăm datele, avem tendința de a grupa caracteristicile în următoarele patru compartimente:

• Caracteristici sparte. . Caracteristici care par a fi stricate sau ineficiente - evident, trebuie să le reparăm;
• Caracteristici neutilizate. . Caracteristici care funcționează conform intenției, dar sunt rareori utilizate - adesea un semn că fie ar trebui eliminate, fie au nevoie disperată de inovare;
• Caracteristici de utilizare neașteptată. . Caracteristici care sunt utilizate într-un mod extrem de diferit de ceea ce au imaginat inițial creatorii lor – un bun candidat pentru rafinament lentă și continuă;
• Caracteristici cal de bătaie. . Funcții care sunt foarte utilizate și par să funcționeze conform planului - caz în care ne întrebăm dacă există vreo modalitate de a-și îmbunătăți în continuare UX-ul prin explorarea atât a procesului iterativ lent, cât și a conceptelor inovatoare complet diferite în paralel.

Primele două găleți sunt esențiale pentru menținerea unei interfețe funcționale și utilizabile, în timp ce ultimele două sunt esențiale pentru menținerea utilizatorilor implicați și încântați. În mod ideal, vrem să atingem ambele obiective în același timp, dar restricțiile de timp, buget și echipă au mâna de sus.

Totuși, odată ce o nouă iterație sau o idee nouă este aleasă, poate fi tentant să treceți imediat la proiectarea sau construirea noii caracteristici. Dar înainte de a ne gândi la modul în care o caracteristică s-ar potrivi într-o interfață existentă, este o strategie bună să validați ideea mai întâi - cu un prototip rapid și cu o cercetare a utilizatorului. O modalitate obișnuită de a realiza acest lucru este utilizarea unui proces iterativ rapid, cum ar fi sprintul de design al Google Ventures. Repetând în câteva zile, puteți identifica cum ar trebui implementată noua caracteristică și/sau dacă este utilă așa cum v-ați imaginat-o inițial.

Cu sprinturile de design, expunem ideea cercetării de utilizare devreme. În metodologia Google Ventures, ai testa un design cu cinci utilizatori pe zi; apoi, veți repeta și treceți printr-o altă rundă de testare a noului design. Motivul pentru care sunt implicați toți aceiași utilizatori este că, dacă testați un design diferit cu fiecare utilizator în acea zi, nu veți avea date valide pentru a ști ce elemente ar trebui să se schimbe. Aveți nevoie de câțiva utilizatori pentru a valida o iterație de design.

În sprinturile noastre aplicăm un model ușor diferit. Când începem să lucrăm la o nouă caracteristică, odată ce primul prototip timpuriu este construit, aducem designerii, dezvoltatorii și echipa UX împreună în aceeași cameră, invităm utilizatorii reali să testeze și apoi să repete într-un program strâns. În prima zi, primii testeri (două-trei persoane) ar putea fi programați pentru un interviu de 30 de minute la ora 9:00, al doilea grup la 11:00, următorul la 14:00 și ultimul. unul în jurul orei 16:00. Între interviurile cu utilizatorii, avem „ferestre de timp deschise”, când repetăm ​​de fapt designul și prototipul până când la un moment dat avem ceva viabil.

Motivul pentru aceasta este că, de la început, dorim să explorăm rapid direcții complet diferite, uneori chiar opuse; odată ce adunăm feedback pe diferite interfețe, putem converge către ceea ce se simte ca interfața „maxim absolut” . În acest fel, putem obține feedback foarte variat cu privire la iterații de design foarte diverse. Feedback-ul se bazează în principal pe trei factori: hărți termice care înregistrează clicurile utilizatorilor, timpul de care au nevoie utilizatorii pentru a finaliza o sarcină și cât de încântătoare este experiența pentru ei. Mai târziu în cursul săptămânii, continuăm să lucrăm în mod constant cu un număr mai mare de utilizatori, la fel ca Google, validând permanent noul design pe măsură ce mergem.

Până acum e bine, dar uneori o nouă caracteristică aparent inovatoare se ciocnește de o caracteristică existentă, iar amândouă în aceeași interfață ar aglomera designul. În acest caz, examinăm dacă una dintre opțiuni ar putea fi considerată o extensie a celeilalte. Dacă ar putea fi, atunci începem prin a-i reitera funcționalitatea și designul. Atunci trebuie să alegem reproiectarea radicală sau schimbarea incrementală. Acesta din urmă este mai puțin riscant și va păstra un model de interacțiune familiar pentru utilizatori, în timp ce primul este necesar dacă modificările critice sunt imposibil de realizat altfel sau dacă câștigurile din schimbările incrementale ar fi prea puține.

În ambele cazuri, este esențial să se concentreze asupra întregii experiențe de utilizare a produsului, mai degrabă decât pe valoarea unei singure caracteristici din acel produs. Și odată ce ați ales funcția și ați proiectat și construit primul prototip, este timpul să testați.

Cele opt niveluri de testare

Ei bine, atunci, cum putem preveni efectiv erorile și eșecurile să se strecoare într-un mediu real? Câte verificări, recenzii și teste rulăm înainte ca o funcție să fie implementată? Și în ce secvență rulăm aceste teste? Cu alte cuvinte, cum ar arăta strategia finală pentru lansarea funcțiilor?

Una dintre cele mai bune strategii pentru lansarea funcțiilor a fost propusă de Andrew Sumin, șeful de dezvoltare la Mail.ru, un important furnizor de e-mail din Rusia. Strategia nu s-ar aplica fiecărui proiect, dar este o abordare rezonabilă și cuprinzătoare pentru companiile care deservesc produse mijlocii și mari pentru mii de clienți.

Să ne uităm la strategie în detaliu și să acoperim cei opt pași ai lansării unei funcții, acoperind procesul de dezvoltare a produsului al Mail.ru:

1. testați cu dezvoltatorii,
2. testare cu utilizatori reali într-un mediu controlat,
3. testare cu utilizatori la nivel de companie,
4. testați cu testere beta,
5. testați cu utilizatorii care se înscriu manual,
6. testarea divizată și verificarea reținerii,
7. eliberați încet și treptat,
8. măsura consecințele.

În cazul Mail.ru, cea mai importantă caracteristică de păstrat intactă indiferent de ce compune un mesaj (evident). Aceasta este cea mai folosită piesă a interfeței, iar a permite acesteia să fie indisponibilă sau să funcționeze incorect chiar și pentru câteva secunde ar fi absolut exclus. Deci, ce se întâmplă dacă am dori să extindem funcționalitatea unei zone de text, poate adăugând câteva funcții inteligente de completare automată, sau un contor sau o previzualizare laterală?

1. Testați cu dezvoltatorii

Cu cât trece mai mult timp în dezvoltare, cu atât devine mai costisitoare rezolvarea unei probleme. Din nou, gândiți-vă la cât de conectate sunt toate deciziile în dezvoltarea produsului; cu cât produsul este mai rafinat, cu atât mai multe decizii trebuie revenite, costând timp și resurse. Deci, identificarea și rezolvarea problemelor din timp, atât din perspectiva afacerii, cât și din perspectiva designului și dezvoltării.

Totuși, nu puteți depana o idee, așa că testarea inițială ar trebui să aibă loc în timpul producției, pe primele prototipuri. Primii testeri de la Mail.ru sunt, deci, dezvoltatorii care scriu efectiv codul. Compania își încurajează angajații să folosească produsul pentru comunicarea internă (și chiar comunicarea privată); deci, dezvoltatorii ar putea fi considerați utilizatori hardcore ai produsului.

Primul pas este destul de evident: proiectați și construiți caracteristica, apoi testați-o, revizuiți și lansați-o pe serverul de staging. Aici intervine testarea QA, cu instrumente cuprinzătoare și rulanți de sarcini care încearcă să blocheze funcția și interfața, potențial automatizate cu instrumente de testare a maimuțelor, cum ar fi Gremlins.js.

Rezultatele sunt monitorizate și apoi transmise înapoi în bucla de feedback pentru următoarea iterație a caracteristicii. La un moment dat, dezvoltatorii se vor simți destul de încrezători cu build: schimbarea pare să funcționeze conform așteptărilor, iar cerințele au fost îndeplinite. Atunci începe testarea utilizatorilor reali.

2. Testați cu utilizatori reali într-un mediu controlat

Când primul prototip de lucru este terminat, caracteristica este testată cu utilizatorii reali în interviuri. Clienții sunt invitați să finalizeze sarcini și, pe măsură ce o fac, echipa UX monitorizează punctele fără fund și problemele care apar și le abordează la fața locului.

Cu toate acestea, nu numai că noua caracteristică este testată; Scopul testului de utilizare este de a se asigura că noua caracteristică nu afectează componentele critice ale interfeței, motiv pentru care utilizatorii îndeplinesc sarcini de rutină, cum ar fi scrierea unui mesaj și deschiderea, răspunsul la e-mailurile și răsfoirea e-mailurilor în căsuța lor de e-mail. Dacă atât noua caracteristică, cât și caracteristicile vechi sunt bine înțelese, procesul poate continua.

3. Testați cu utilizatori la nivel de companie

În mod evident, feedback-ul de la testul de utilizare îi determină pe dezvoltatori să introducă modificări, care apoi furnizează înapoi către testerii de utilizare, mergând înainte și înapoi până când rezultatul pare să aibă valoare pentru un public mai larg. Următorul pas, așadar, este ca caracteristica să fie evidențiată în cadrul companiei: este trimis un e-mail la nivelul întregii companii, încurajând toți colegii să verifice funcția și să trimită rapoarte, erori și sugestii într-un tracker.

Cu testare, nu există o diferență deosebit de mare între utilizatorii din departamentele „la distanță” din cadrul companiei și utilizatorii din sălbăticie. Nici măcar utilizatorii interni nu știu la ce schimbări să se aștepte sau știu exact ce face o funcție sau cum ar trebui să funcționeze sau să arate. Singura diferență principală este că colegilor li se poate solicita să trimită rapid feedback sau să lase un comentariu. Atunci sunt introduse formularele de vot. Testerii nu pot doar să se joace cu funcția, ci și să adauge un comentariu și să o voteze sau să o voteze negativ. Votul trebuie să fie cântărit în raport cu strategia de produs și cerințele de afaceri, dar dacă utilizatorii găsesc în mod clar o funcție inutilă sau utilă, aceasta este o modalitate simplă și eficientă de a colecta feedback și de a testa dacă produsul funcționează conform așteptărilor.

4. Testați cu testere beta

Dacă o caracteristică a trecut de o verificare tehnică, o verificare a utilizării și o revizuire în cadrul companiei, următorul pas logic este să o prezinți unor segmente ale publicului. Cu toate acestea, în loc să o lanseze la un segment aleatoriu de utilizatori, echipa trimite o funcție pentru examinare printre testerii beta - utilizatorii care au ales să participe la teste și să trimită feedback pentru funcțiile experimentale. Aceștia pot vota în contra sau în favoarea unei funcții, precum și pot raporta erori și comite fragmente de cod.

Dar cum alegi beta-testerele adecvate? Ei bine, dacă doriți să încurajați testerii să spargă interfața, s-ar putea să vă concentrați pe utilizatorii fideli avansați cu abilități tehnice - utilizatori care ar putea oferi detalii tehnice despre o eroare dacă este necesar și utilizatori care cunosc suficient de bine interfața existentă pentru a fi capabil să anticipeze problemele pe care le-ar putea avea alți utilizatori.

Cu toate acestea, aveți nevoie de criterii pentru a determina dacă un utilizator este suficient de avansat pentru a fi un tester beta. În cazul unui client de e-mail, ar putea fi cineva care folosește Chrome sau Firefox (adică știe cum să-și schimbe browserul implicit), care a creat mai mult de trei foldere în inbox și care a instalat și aplicația mobilă.

5. Testați cu utilizatorii care se înscriu manual

Până în acest moment, testele au implicat un număr gestionabil de utilizatori, configurații și rapoarte de testare. Cu toate acestea, diversitatea utilizatorilor, sistemelor și configurațiilor din sălbăticie, inclusiv sistemul de operare, browserul, pluginurile, setările de rețea, software-ul antivirus și alte aplicații instalate local, poate fi puțin mai descurajantă la scară.

În cazul Mail.ru, următorul pas este lansarea funcției într-o interfață live, în spatele unui steag, și trimiterea unui e-mail către acest segment mai mare de utilizatori activi, prezentând noua caracteristică și invitându-i să o activeze pe propriul propriu în interfață, de obicei cu un buton strălucitor „Actualizare”. Pentru a măsura valoarea caracteristicii pentru utilizatorii reali, echipa folosește din nou un sistem de vot, cu câteva solicitări ici și colo, practic întrebând utilizatorii dacă găsesc funcția utilă sau utilă. Observați că diferența dintre acest nivel și nivelul anterior este că înscrierea manuală implică un public mult mai larg - dintre care mulți nu sunt deloc tehnici, spre deosebire de testerii beta.

Deci, timpul și coordonarea contează . Probabil că nu ați alege o zi aleatorie pentru a trimite e-mailul utilizatorilor activi, deoarece veți dori ca echipa de asistență pentru clienți și dezvoltatorii să fie disponibili atunci când fluxul de rapoarte de erori începe să sosească. De aceea e-mailul este trimis la începutul săptămânii, când toți (sau majoritatea) dezvoltatorilor sunt disponibili și echipa de asistență este pregătită să treacă la acțiune, fiind informată și conectată activ cu dezvoltatorii prin Skype sau Slack. Într-o companie mai mică, ați putea chiar să îi puneți pe dezvoltatori să stea câteva ore la birourile de asistență pentru a ajunge mai rapid la miezul unei probleme, vorbind direct cu clienții.

6. Split-Test and Check Retention

În pașii de până acum, cu excepția testării de utilizare, toți testerii au folosit noua funcție în mod voluntar. Cu toate acestea, dacă activați funcția în mod implicit, dintr-o dată utilizatorii vor trebui să o folosească, iar acesta este un tip foarte diferit de grup, unul pe care nu l-am testat deloc.

Pentru a vă asigura că nu rupeți obiceiurile utilizatorilor pasivi, puteți să testați împărțit cu trei segmente mici de utilizatori și să măsurați retenția . La urma urmei, vrei să te asiguri că o nouă versiune funcționează cel puțin la fel de bine ca cea anterioară. Identificați cea mai importantă activitate din interfață și măsurați nu numai cât timp petrec utilizatorii înainte și după lansare, ci și cât timp trece până se întorc. În cazul Mail.ru, reținerea implică utilizatorii să își verifice e-mailul și să compună un mesaj. Cu cât un utilizator revine mai des, cu atât este mai mare retenția, ceea ce este un indicator al unei UX mai bune.

Fiecare segment are o vizualizare ușor diferită , ceea ce ne permite să testăm mai târziu cum să afișăm noua caracteristică tuturor utilizatorilor. Pentru primul segment, adăugăm noua caracteristică și oferim un tutorial despre cum să o folosești. Pentru al doilea segment, doar adăugăm noua caracteristică. Pentru al treilea segment, am putea lăsa caracteristica așa cum este. Pentru toate aceste segmente, am putea implementa modificarea în același timp, să selectăm un interval de timp rezonabil pentru a rula testul, să măsuram retenția și apoi să comparăm rezultatele. Cu cât reținerea unui segment este mai mare, cu atât este mai probabil ca designul să fie promovat pentru toți utilizatorii mai târziu.

7. Eliberați încet și treptat

Dacă o caracteristică a ajuns până în acest punct, atunci probabil că deja funcționează bine pentru un segment mare de public. Acesta este momentul în care îl puteți implementa treptat pentru toți utilizatorii - cu o solicitare de vot pentru a aduna feedback. Dacă feedback-ul este în mare parte pozitiv, puteți continua să lansați funcția și va deveni în cele din urmă o parte integrantă a interfeței. În caz contrar, veți evalua feedback-ul și veți reveni la laborator pentru următoarea iterație.

Totuși, lansarea funcției nu este suficientă: trebuie comunicată utilizatorilor. O modalitate obișnuită de a face acest lucru este prin e-mail și rețelele sociale. Totuși, un tutorial rapid care explică valoarea funcției în scenarii din viața reală ar putea fi de asemenea util. De asemenea, nu uitați să integrați o casetă de sugestii pentru a aduna imediat feedback.

8. Măsurați consecințele

Odată ce funcția a fost lansată, putem monitoriza modul în care funcționează și putem încerca diferite metode pentru a atrage atenția asupra acesteia, astfel încât utilizatorii să-și poată îndeplini sarcinile mai eficient. Puteți urmări cele mai frecvente sarcini sau cele mai vizitate pagini și apoi afișați o mică notă în linie care recomandă o modalitate puțin mai inteligentă și mai rapidă pentru ca utilizatorul să își atingă obiectivul și apoi să măsurați dacă utilizatorul preferă această nouă caracteristică sau metoda obișnuită.

Nu uitați să aduceți feedback-ul înapoi întregii echipe, nu doar dezvoltatorilor sau designerilor, astfel încât aceștia să fie motivați și implicați și să vedeți cum oamenii folosesc o funcție care inițial nu era altceva decât o idee brută. Nimic nu este mai motivant decât să vezi oameni fericiți și încântați folosind o aplicație exact așa cum ai imaginat-o sau în moduri complet diferite. De asemenea, va contribui la creșterea caracteristicilor ulterioare ale echipei.

Procesul de revizuire pare complex și minuțios, dar uneori doar timpul și o rețea largă pentru testarea utilizatorilor vor descoperi o problemă. De exemplu, dacă o modificare afectează imaginea de ansamblu a mesajelor primite, niciun test unitar nu ar putea descoperi dificultățile pe care le pot întâmpina utilizatorii de software de asistență. Într-o interfață de e-mail, ce doriți ca dispozitivul de accesibilitate să citească mai întâi: data, expeditorul, linia de subiect sau mesajul în sine? Modul în care rearanjați coloanele din prezentarea generală poate schimba modul în care utilizatorii aleg să acceseze informațiile; deci, să le permită să dezactiveze noua caracteristică ar fi, de asemenea, critică.

Concluzie

Deci, cum arată o strategie de lansare? Puteți începe prin a explora graficul dependențelor pentru a înțelege cât de extinsă ar putea fi schimbarea dvs. Apoi, puteți testa funcția cu dezvoltatori și cu utilizatori reali într-un mediu controlat. Apoi, le-ați putea cere colegilor să revizuiască funcția, înainte de a o trimite unui grup selectat de testeri beta. În cele din urmă, puteți face funcția disponibilă ca opțiune pentru utilizatori. Și, înainte de a activa funcția pentru toată lumea, puteți rula un test de împărțire pentru a afla care este cea mai bună modalitate de a introduce funcția și apoi măsurați ratele de retenție pentru sarcinile critice.

Evident, implementarea nu este un proces liniar . Pe parcursul procesului, s-ar putea să fie nevoie să faceți doi pași înapoi pentru a face un pas înainte - până când veți avea în sfârșit un candidat pentru eliberare. Fluxul de lucru descris mai sus poate părea destul de lent și nu deosebit de agil, dar minimizați drastic riscul ca utilizatorii să se confrunte brusc cu o problemă neașteptată și, ca urmare, să aibă o experiență inferioară. În unele situații, s-ar putea să merite foarte bine.