Agile UX: Cum să încorporați UX și Design de produs în Agile

DevOps este adesea definit ca procesele, operațiunile, metodologiile, instrumentele și cultura din jurul dezvoltării software și sistemelor unei companii.

Dar ingineria nu funcționează în vid. Planurile, ideile, modelele și conceptele provin de la specialiști în design de produs care decid aspectele, fluxurile și interactivitatea. Acestea sunt persoane și echipe care nu fac parte din inginerie, care împărtășesc obiectivele și rezultatele dorite ale DevOps.

DevOps este mult mai mult decât modul în care dezvoltatorii se conectează la IT, modul în care este gestionată infrastructura și modul în care cadrele pot fi îmbunătățite. Este vorba despre recunoașterea câte echipe sunt cu adevărat implicate în procesul de dezvoltare a software-ului, cât de împletite sunt rolurile și munca lor și găsirea unor modalități mai bune de a vă asigura că toată lumea este la masă.

Dezvoltatorii și arhitecții de inginerie doresc să fie implicați atunci când echipele de produs și creative proiectează software-ul sau sistemul. Dar unde este asta în definiția actuală a DevOps? Echipele de produs, UX și creative doresc să rămână implicate în timpul proceselor de inginerie, dar atât de multe metodologii le exclud. Acestea sunt silozuri vechi pe care trebuie să le dărâm.

Clienții dvs. văd doar experiența dvs. de utilizator (UX). Ei nu văd câți dezvoltatori ai avut sau dacă ai fost Agile sau Lean. Nu au idee ce instrumente DevOps sunt folosite. UX-ul companiei tale este produsul și te poate face sau te poate distruge. Se întreabă cine a construit această bucată de gunoi. Cu atâta concurență și oameni fericiți să dezinstaleze o aplicație sau să părăsească un site web, vei avea o a doua șansă cu clientul care te-a abandonat?

Agile se antrenează rar în UX sau lucrează cu specialiști UX

Multe echipe de inginerie consideră adesea că UX este izolat și dificil de colaborat. UX nu pare Lean și multe variante de Agile exclud detalii despre cum să lucrați cu UX. Unele abordări Agile sugerează în mod specific că un proprietar de produs care descrie o caracteristică este „destul de bun”.

SAFe Agile face greșeala de a decide că cea mai bună modalitate de a rezolva UX siloing este excluderea lor completă. SAFe „împuternicește echipele Agile” să-și facă propriul „Lean UX”. Pe măsură ce mai multe companii înțeleg valoarea încorporării specialiștilor UX și a unui proces UX complet, SAFe merge în direcția greșită.

Absența explicării UX și a proceselor acestora din instruirea și cărțile Agile a determinat echipele din întreaga lume să excludă sau să minimizeze implicarea designerilor de produse specialiști.

• Când îți imaginezi în mod incorect că UX doar desenează casete pe pagini, este ușor să presupui că „pot face treaba asta”. Așa cum mulți audienți la American Idol sunt siguri că sunt cel mai bun cântăreț de pe planetă, majoritatea managerilor de produs și inginerilor se autoevaluează ca fiind grozavi la UX. Acest lucru înseamnă în mod normal că ei cred că sunt grozavi la amenajarea ecranelor. Dar, deoarece acest articol explică ceea ce se întâmplă cu adevărat în munca UX, veți vedea cum un specialist UX nu ar vedea un dezvoltator care realizează wireframes ca pe cineva căruia ar trebui să i se ofere sarcini UX.
• Cărțile de pe Scrum sugerează că, dacă un specialist UX devine un blocaj, ar trebui să pregătească roluri non-UX pentru a-și face treaba. Acest tip de decizie este rareori sugerat cu privire la alte roluri în dezvoltarea de software; Nimeni nu și-ar dori ca un dezvoltator neinstruit sau fără experiență să facă codarea, chiar și după un bootcamp sau a citit o carte despre programare. Nu am sugera niciodată că, dacă un dezvoltator devine un blocaj, ea ar trebui să-l antreneze pe managerul de proiect să facă ceva codare.
• Managerii de angajare care cred în mod incorect că UX este un loc de muncă artistic (UI) angajează artiști pentru a face munca UX. Nu există o suprapunere educațională între o diplomă în UX și în UI. Talentele naturale nu se suprapun adesea; cineva grozav la UX ar putea fi un artist sărac și invers. Angajarea pentru „UX/UI” vă oferă adesea un artist grozav cu experiență, expertiză, proces sau educație minimă UX.

Celor care se uită doar la concluzia de jos le-ar plăcea să reducă bugetul dând sarcini UX persoanelor cărora le-ar putea lipsi educația UX, experiența, expertiza, abilitățile sau talentul natural. Dar acest lucru este miop și poate duce la o productivitate, eficiență, cultură, produs și satisfacție scăzută a clienților.

Importanța încorporării specialiștilor experți UX în Agile

La sfârșitul anului 2018, firma de consultanță în management McKinsey & Company a publicat „The Business Value of Design”, un raport despre cercetările efectuate cu peste 300 de companii.

Ei au descoperit că „Designul este singurul mod în care companiile pot ieși în evidență din mulțime”. Când concurenții au seturi de caracteristici apropiate, ce îi face să se deosebească? Designul este uneori considerat doar ca aspectul estetic sau ceea ce face ca acest lucru să semene cu marca noastră. Dar atunci când este folosit cu „UX”, designul înseamnă arhitectura caracteristicilor și deciziile luate cu privire la ecrane, pași, fluxuri, machete, procese, organizare și meniuri.

UX face parte din procesul de îmbunătățire continuă, căutând mereu să înțeleagă mai bine utilizatorii și să selecteze și să proiecteze caracteristicile și produsul care se potrivesc cel mai bine nevoilor acestora, să le rezolve punctele de durere și să le aducă inovații semnificative.

McKinsey a mai raportat că „Companiile trebuie să îmbrățișeze designul în mod holistic și la începutul procesului, mai degrabă decât să-l vadă ca pe un mic instrument care se potrivește mai târziu”. Echipele care presupun că atenția acordată experienței utilizatorului este ceva ce poate fi minimizat, exclus sau făcut după lansarea produsului, adoptă o abordare greșită.

McKinsey a colectat date cantitative și a descoperit că firmele care au adoptat designul UX au generat cu 32% mai multe venituri și cu 56% mai multe randamente pentru acționari într-o perioadă de 5 ani. Declararea companiei dvs. ca fiind „centrată pe utilizator” nu este suficientă. Trebuie să mergeți pe drum prin integrarea practicienilor și proceselor UX, de la planificare și portofoliu până la dezvoltare și QA.

Procese de dezvoltare software cu și fără UX

Dacă compania dvs. nu include specialiști UX în procesul de proiectare și dezvoltare software, procesul dvs. cel mai probabil arată ca imaginea de mai jos.

Un client, manager de produs, CEO sau cineva cu viziune spune ingineriei ce vor. Engineering îl construiește, îl testează și îl primește pe un server de procesare sau de producție. Persoana cu viziunea o vede apoi și, nu știi, nu este fericită. Vor ceva diferit sau s-au răzgândit.

Ingineria trebuie apoi să se întoarcă la început, să afle ce vrea această persoană acum, să construiască, să testeze și să își încrucișeze degetele că acesta este farmecul.

Dacă aveți experți UX în echipă, procesul este destul de diferit. Acea persoană cu viziune vine la UX cu ideile, datele și punctele dureroase ale clienților. UX parcurge sarcinile din procesul său de proiectare centrat pe utilizator și apoi testează aceste concepte înainte ca inginerie să scrie o linie de cod. Acest lucru asigură că produsul sau caracteristica pe care ne gândim să le construim este executarea corectă a ideii potrivite pentru clienții noștri țintă.

Testarea ar putea scoate la iveală unele defecte, ceea ce permite UX să repete și adesea să testeze din nou. După procesul UX, aveți un design complet verificat, gata de a fi livrat la inginerie.

Dacă cineva se răzgândește pe parcurs, acea persoană vorbește cu UX în loc să o introducă ca o cerere de schimbare către dezvoltatori. UX rulează interferențe în timpul procesului lor și nimic nu este trimis la inginerie fără ca UX să fie implicat în proiecte, decizii și testare pe clienți reali sau arhetipali.

Schimbările de părere în acest moment nu sunt dezastre, deoarece costul ca cineva să se răzgândească în acest moment este minim. Ingineriei nu au primit planurile, nu au început și nu au nimic de reconstruit. UX repetă design-urile lor și poate testa utilizatorii pentru a se asigura că ideile se potrivesc bine și puternic cu baza de clienți. Schimbările de gândire consumă timp, dar impactul general asupra bugetului este mic.

UX are un proces formalizat

Design-ul centrat pe utilizator (UCD) este un proces formalizat care include sarcini care direcționează specialiștii UX să cerceteze, să proiecteze, să prototipeze, să testeze pe utilizatori reali sau arhetipali și apoi să repete pe baza învățăturilor din testare.

Concentrându-ne pe câteva dintre aceste domenii, începem cu cerințe și discuții timpurii despre caracteristici și proiecte. Când UX primește pentru prima dată cerințe și alte informații despre proiect, este important să începeți colaborarea imediat. UX NU ar trebui să afle mai târziu că au proiectat ceva ce nu poate fi construit.

Începeți prin a aduce angajați sau manageri UX atunci când managerii de produs sau de proiect decid caracteristicile și prioritizarea. Un proiect fără valoare pentru utilizator poate fi eliminat, economisind timp și bani nespus. Aici intră în joc maximizarea cantității de muncă neefectuată. Produsul și Inginerie ar trebui să sprijine UX atunci când creează mai puțină muncă pentru Inginerie prin reducerea sau eliminarea funcțiilor sau a proiectelor întregi. Cu toate acestea, prea des, proiectele au atașat ego-ul, iar colegii de echipă exclud adesea UX din aceste conversații timpurii, astfel încât proiectul să fie finanțat.

Cercetarea este o parte importantă a ceea ce face UX. Nu este centrat pe utilizator fără implicarea utilizatorilor. Statisticile și datele cantitative sunt grozave, dar nu există un substitut pentru intervievarea utilizatorilor, înțelegerea lor profundă și obținerea de date calitative. UX vrea să știe de ce și nu doar ce.

Cercetarea UX îi aduce și colegii de echipă pe aceeași pagină, unificând pe toată lumea în jurul personajelor, arhetipurilor clienților țintă. Pe baza interviurilor cu utilizatorii, cumulăm ceea ce învățăm și reducem pe toată lumea la 6 sau mai puține persoane. Ce îi motivează? Ce să facă au nevoie? Unde sunt oportunitățile pentru compania, produsul sau serviciul nostru?

Cea mai bună utilizare a personajelor ar fi includerea lor peste tot. Produsul imaginează caracteristici bazate pe persoane (și date bune). Design-uri UX bazate pe personaje. Testele QA în timp ce vă imaginați că sunt aceste persoane. Marketingul le poate adăuga detalii demografice și de altă natură, dar și ei ar trebui să ia în considerare modul în care vocea mărcii, rețelele sociale și publicitatea vorbesc persoanei.

Personajele îi ajută pe lucrătorii non-UX să scape de „Ei bine, îmi place așa” sau „CEO-ului îi place așa”. Proiectăm pentru acești clienți țintă și dacă tu sau CEO-ul nu te încadrezi în personaje, atunci UX nu este influențat de ego sau de preferințele personale. UX trebuie să rămână concentrat pe client.

Arhitectura informației are de-a face cu ierarhii, structură și taxonomii. Aceasta ar putea fi navigarea pe site sau ar putea fi modul în care produsele sunt clasificate într-o bază de date de comerț electronic. Dorim să ne asigurăm că clienții vor găsi cu ușurință produse după categorii, metadate și filtre.

Designul de interacțiune , uneori numit și design de experiență, este ceea ce se gândesc majoritatea oamenilor când își imaginează UX. Acestea sunt wireframes-urile și prototipurile, planurile de design și concepte. Acestea ar afișa fluxuri de proces, machete, meniuri, interacțiuni, căi, opțiuni și multe altele.

Prototipurile UX sunt ca niște wireframes aduse la viață. Sunt modele digitale interactive, pe care se poate face clic. Nu trebuie să scriem cod; avem software care ne ajută să le creăm rapid. Companiile care caută prototipuri mai realiste folosesc Axure, deoarece are o logică condiționată, variabile, gesturi de glisare pe mobil, glisare și plasare și tot felul de declanșatoare de evenimente. Puteți crea prototipuri pentru aproape orice tip de dispozitiv.

Prototiparea UX se face pentru:

• Brainstorming
• Colabora
• Repeta
• Explorați soluții
• Prezent pentru investitori (pentru startup-uri)
• Testați prototipul pentru a vedea dacă soluția se conectează bine cu publicul (publicile) țintă.
• Oferiți un model interactiv dezvoltatorilor sau altor colegi de echipă, care este adesea preferat față de paginile de documentație (și niciun model pe care se poate face clic).

Acum se trece la testarea utilizatorilor , numită și testare de utilizare, care are loc în timpul procesului UX și înainte ca inginerie să scrie o linie de cod. Trebuie să testați concepte și design pentru a vă asigura că ideea și execuția sunt fantastice pentru clienții țintă.

Testarea utilizatorilor va scoate la lumină orice defecte, oferind UX șansa de a repeta ideile, ceea ce este ieftin în acest moment, deoarece inginerie nu are nimic de construit sau reconstruit.

Există 5 motive cheie pentru care UX rulează teste înainte de a le livra la inginerie:

1. Utilizarea optimă a timpului și resurselor ingineriei. Dacă doriți ca participanții la testare să vadă un produs finit creat de ingineri, trebuie să îl construiți și să îl testați pentru erori. Dacă testarea UX scoate la lumină modificările necesare, dezvoltatorii ar trebui să reconstruiască, iar QA ar trebui să testeze din nou. Dacă testarea UX a arătat un eșec mai mare al conceptului, acest lucru ar putea însemna că timpul de inginerie a fost complet pierdut, deoarece acesta nu este un cod care va ajunge nicăieri. Conceptul ar trebui să fie regândit, reproiectat și proaspăt testat.
2. Repetați în culise. Când companiile doar îl construiesc, îl expediază, îl repetă și îl construiesc și îl livrează din nou, asta înseamnă că clienții văd o varietate de versiuni. Ei văd lucrările în desfășurare și urmăresc cum se face cârnații. Aceasta este adesea o experiență frustrantă și confuză, care solicită clienților să continue să reînvețe un sistem care evoluează. Este mai bine să repeți în culise în procesul UX și să fie clar cu testerii că este o versiune prototip sau demonstrativă.
3. Monitorizare si masurare. Dacă un nou concept este lansat live, cercetătorii UX nu au o modalitate bună de a urmări oamenii cum îl folosesc, de a le pune întrebări și de a obține tipul de feedback de care UX are nevoie pentru a determina dacă ceva este gata sau are nevoie de o altă iterație. UX vrea întotdeauna să știe de ce, calitativ, și nu doar ce sau câte. Cum cheltuiesc utilizatorii, se convertesc, se implică etc.? Evitarea testării UX adecvate face mai dificilă diagnosticarea și remedierea problemelor sau punctelor dureroase ale clienților.
4. Testarea UX se plătește de la sine. Testarea UX nu este o cheltuială uriașă. Unele instrumente de testare terță parte doresc sub 100 USD per participant la testare, unele necesită un angajament anual minim de mii de dolari. Acestea nu sunt cheltuieli uriașe, având în vedere bugetul general al companiei pentru procesul de dezvoltare a software-ului și importanța feedback-ului de testare timpurie. Rundele de testare a utilizatorilor costă aproape întotdeauna mai puțin și se mișcă mai repede decât îi face pe programatori să construiască ceva ce ar putea fi nevoie să anulăm sau să construim din nou.
5. Testarea utilizatorului rezolvă argumentele. Dacă compania dvs. nu permite specialiștilor UX să ia decizia finală cu privire la modul în care este proiectat produsul, atunci s-ar putea să găsiți UX în conflict cu produsul, inginerie sau o parte interesată atunci când există idei diferite despre ceea ce ar trebui să fie construit și lansat către client. Sau ce se întâmplă dacă UX are două idei puternice și se întreabă care se conectează mai bine cu clienții? Soluția aici este testarea utilizatorului.

UX poate prototipa conceptele. Cel mai bine este să reduceți concurența la cele mai bune două modele, mai ales dacă puteți găsi deja compromisuri între idei și membrii echipei. Aceasta înseamnă că nu testăm ceea ce dorește UX vs ceea ce îi place produsului vs ceea ce îi place șefului de inginerie vs ceea ce maestrul scrum consideră că sună a o idee bună vs ceea ce îi place partenerului de viață al CEO.

Testarea utilizatorilor permite clienților să vorbească și vă ajută să găsiți direcția potrivită pentru caracteristici sau produs. Rezolvă argumentele prin furnizarea echipelor de date cantitative și calitative care le spun tuturor care idee ar putea aduce cea mai mare satisfacție clienților.

Nu este un design centrat pe utilizator fără implicarea utilizatorului. Aceasta înseamnă că cercetăm și testăm cu clienți reali sau arhetipici, mai degrabă decât să ghicim, să presupunem sau „doar să-l expediem”. Trebuie să ne asigurăm că ceea ce „doar livrăm” a fost verificat prin testarea utilizatorilor și este o execuție excelentă a unei idei grozave.

Ce se întâmplă când UX este ocolit sau redus?

Skype a anunțat recent că reproiectarea sa din 2017, care urmărea să-l facă mai asemănător Snapchat, a fost un eșec. Utilizatorii nu au vrut, nu au avut nevoie sau nu le-au plăcut noile funcții. Reacția a fost suficient de mare încât Skype a făcut un anunț în 2018 că va reproiecta Skype din nou. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Experții UX ar fi știut, în multe etape ale procesului lor, că aceste caracteristici ar fi probabil să fie nedorite sau să eșueze. Cercetările cu utilizatorii țintă ar fi putut dezvălui rapid că nu au vrut ca Skype să devină Snapchat. Uciderea proiectului sau pivotarea în acest moment timpuriu ar fi putut economisi Skype milioane de dolari plus presa proastă și înstrăinarea clienților.

Chiar dacă cercetarea UX ar fi fost ocolită, testarea unui prototip UX pe utilizatori ar fi clarificat faptul că clienții nu au vrut ca Skype să meargă în această direcție. Cu UX încă în mișcare prin procesul său, ingineria nu a scris încă o linie de cod. Acest lucru ar fi putut economisi timp, bani și resurse umane extraordinare, celebrând simplitatea și ingineria muncii nu trebuia să facă.

Proces agil UX

Amintiți-vă de principiile manifestului Agile. Prioritatea dumneavoastră cea mai mare este satisfacția clienților prin construirea de software valoros. Oferiți angajaților (UX) mediul și sprijinul de care au nevoie, având încredere în ei pentru a duce treaba la bun sfârșit. Maximizați cantitatea de muncă neexecută . Atenția continuă acordată designului bun sporește agilitatea.

Proiectele care avansează trebuie să ofere UX o pistă uriașă, astfel încât să poată începe cercetarea, proiectarea și testarea corespunzătoare. Nu invitați UX la întâlnirea de lansare și surprindeți-i cu cererea ca wireframes-urile finale să fie livrate în câteva zile. Asta nu este UX.

Nu priviți asta ca fiind Big Design Up Front (BDUF), care este un termen conceput pentru a face oamenii să se înfioreze și să declare că acesta este ceva de care trebuie să scăpăm. Când un proiect sau o caracteristică este mare sau nouă, este necesar ca UX să parcurgă majoritatea, dacă nu toate, procesele de proiectare centrate pe utilizator. Pentru UX, cea mai mică piesă posibilă pentru o caracteristică mai mare este fluxul de lucru sau procesul utilizatorului. Dacă proiectăm și testăm ceva mai mic, riscăm să nu obținem imaginea de ansamblu a experienței reale a utilizatorului.

De exemplu, dacă proiectăm un flux în care utilizatorii se înregistrează și cumpără, nu putem doar să proiectăm câmpuri de selectare a parolelor și să le trimitem la inginerie. Dacă UX ar funcționa în bucăți mici, când ar fi testat întregul proces? Nu putem cunoaște reacția utilizatorului la întregul flux fără a testa întregul flux... ceea ce înseamnă că întregul flux trebuie proiectat înainte de a trece la testarea de utilizare.

Acolo unde caracteristicile, poveștile sau corecțiile sunt mici, practicienii UX pot face un subset al procesului de proiectare centrat pe utilizator și pot lucra mai rapid. UX va merge întotdeauna cât de repede poate, dar un mare specialist UX va face tot ce poate pentru a evita sacrificarea calității muncii depuse. În bătălia rapid vs bun, UX va alege întotdeauna bine peste rapid... și ar trebui și tu.

Bugetele și calendarele sunt ceea ce împiedică UX să primească feedback rapid și să repete. Practicienii UX își doresc întotdeauna feedback și șansa de a îmbunătăți produsul, urmărind să proiecteze ceea ce funcționează cu adevărat pentru clienți. Aducerea practicienilor UX încă de la gestionarea și planificarea portofoliului permite UX să estimeze timpul și bugetul de care vor avea nevoie; acestea nu ar trebui să fie ulterior surprize sau cauze de conflict.

Un practician UX face parte din echipa Agile

Încorporați-vă UX Designer în echipa Agile. Invitați-i să lanseze planificare, stand-up, retro și fiecare întâlnire în care ar putea fi discutată UX. Permiteți UX să-și estimeze timpul în timpul planificării lansării, astfel încât să nu existe surprize cu privire la timpul pe care sarcinile UX le vor necesita. Nu lua decizii fără ele. Dacă colegul tău de echipă UX a ratat întâlnirea, așteaptă până când îi poți găsi personal, prin chat, e-mail sau prin orice metodă folosită de compania ta.

Atribuiți întrebări, ambiguități sau erori coechipierului dvs. UX în JIRA sau în orice sistem de urmărire a erorilor pe care îl utilizați. Asigurați-vă că problemele UX sunt în același sistem ca și alte probleme; nu aruncați problemele UX într-o placă Trello dacă utilizați VersionOne pentru orice altceva.

După ce UX a avut o pistă lungă, dacă a fost necesar pentru această caracteristică sau produs, o bună practică este ca UX să fie cu 2 sau mai multe Sprinturi înaintea ingineriei. UX poate să sprinteze împreună cu tine. Obțineți o mulțime de povești despre tehnologie sau remedierea datoriilor tehnologice în stoc. În acest fel, dacă procesul creativ și ciclic al UX întârzie sau necesită mai multe sprinturi, dezvoltatorii pot fi cu adevărat agili. În loc să aștepte UX, ei pot trece la niște fructe low-hanging pe care produsul sau inginerie le-au prioritizat.

Luați în considerare, de asemenea, resursele, alocarea și personalul. În funcție de dimensiunea proiectului, atribuiți nu mai mult de 3 proiecte unui designer UX. Dacă aveți cercetători UX experți, separați, care efectuează și teste și analize, atribuiți un cercetător la cel mult 3 designeri UX. Dacă practicianul tău UX este ceea ce este cunoscut sub numele de T-formă, ceea ce înseamnă că este, de asemenea, calificat și excelent la cercetare, testare și alte sub-specialități UX, atunci asigură-te că nu este accidental un blocaj, fiind repartizat la prea multe proiecte.

Măsurarea rezultatelor

Fără satisfacția clienților, este posibil să nu aveți clienți. Puteți utiliza valorile privind satisfacția clienților pentru a determina modul în care îmbunătățirea proceselor prin integrarea UX a adus schimbări pozitive.

• Mai puține reclamații
• Recenzii mai bune pentru aplicații
• Evaluări mai mari ale aplicațiilor
• Mai puține bilete de asistență
• Mai puține apeluri la call center
• Semantică mai pozitivă a postărilor sociale
• Mai multe instalări de aplicații, mai puține dezinstalări
• Creșterea AOV (valoarea medie a comenzii).
• Rată de conversie mai mare

De asemenea, puteți măsura obiectivele DevOps dorite, cum ar fi timpul de comercializare și timpul dintre remedieri. Cât timp durează poveștile, proiectele și epopeele pentru a ajunge pe piață înainte și după revoluția ta UX? Este posibil ca estimările de timp ale dezvoltatorilor să fie mai precise atunci când au finalizat design-urile UX pe care să își bazeze estimările față de lucrul din povești sau orice faci acum.

Dacă UX oferă planuri și acestea sunt urmate, sperăm că ingineria are mai puțină muncă prin reducerea schimbărilor și reconstrucțiilor surpriză. Design UX mai devreme, mai puține remedieri mai târziu.

Agile UX este o investiție care se plătește mai mult decât pentru sine

Mulți manageri de proiect văd UX ca pe o linie bugetară care poate fi eliminată sau redusă, iar managerii de angajare sunt entuziasmați de ideea de a combina sarcinile UX cu un alt rol. Cu toate acestea, tot mai multe companii învață că nu există niciun substitut pentru investiția într-un proces UX adecvat, întreprins de specialiști UX instruiți și cu experiență.

Eric Ries, autorul cărții The Lean Startup , întreabă: „Dar dacă ne-am trezi să construim ceva pe care nimeni nu și-l dorea? În acest caz, ce a contat dacă am făcut-o la timp și la buget?” Chiar dacă organizația dvs. nu utilizează metodologia Lean, avertismentul rămâne valabil. Rezultatele dorite de DevOps reflectă acest lucru atunci când ne propunem să construim ceea ce este potrivit pentru client, să îmbunătățim satisfacția clienților și să dezvoltăm funcții cu valoare ridicată pentru clienți.

Cunoașterea clientului, implicarea clientului în proces și construirea pentru adevăratele lor nevoi și preferințe este în cele din urmă mai importantă decât termenele, bugetele, cadrele și instrumentele. Aveți încredere că, dacă construiți execuțiile corecte ale ideilor potrivite, veniturile vor fi acolo.