UX Agile: come incorporare UX e Product Design in Agile

Pubblicato: 2022-03-11

DevOps è spesso definito come i processi, le operazioni, le metodologie, gli strumenti e la cultura che circondano lo sviluppo di software e sistemi di un'azienda.

Ma l'ingegneria non opera nel vuoto. Progetti, idee, progetti e concetti provengono da specialisti del design del prodotto che decidono layout, flussi e interattività. Si tratta di individui e team non ingegneristici che condividono gli obiettivi e i risultati desiderati di DevOps.

Diagramma di copertura del processo UX Agile.

DevOps è molto più di come gli sviluppatori si connettono all'IT, come viene gestita l'infrastruttura e come i framework possono essere migliorati. Si tratta di riconoscere quanti team sono veramente coinvolti nel processo di sviluppo del software, quanto sono intrecciati i loro ruoli e il loro lavoro e trovare modi migliori per assicurarsi che tutti siano al tavolo.

Gli sviluppatori e gli architetti ingegneristici vogliono essere coinvolti quando i team creativi e di prodotto progettano il software o il sistema. Ma dov'è nell'attuale definizione di DevOps? I team di prodotto, UX e creativi vogliono rimanere coinvolti durante i processi di progettazione, ma così tante metodologie li escludono. Questi sono vecchi silos che dobbiamo abbattere.

I tuoi clienti vedono solo la tua esperienza utente (UX). Non vedono quanti sviluppatori avevi o se eri Agile o Lean. Non hanno idea di quali strumenti DevOps vengano utilizzati. L'esperienza utente della tua azienda è il prodotto e può crearti o distruggerti. Si chiedono chi abbia costruito questo pezzo di spazzatura. Con così tanta concorrenza e persone felici di disinstallare un'app o lasciare un sito Web, avrai una seconda possibilità con il cliente che ti ha abbandonato?

Agile si allena raramente su UX o lavorando con specialisti UX

Molti team di ingegneri spesso trovano che l'esperienza utente sia isolata e con cui è difficile collaborare. L'UX non sembra Lean e molte versioni di Agile escludono specifiche su come lavorare con l'UX. Alcuni approcci Agile suggeriscono specificamente che il proprietario di un prodotto che descrive una funzionalità sia "abbastanza buono".

SAFe Agile commette l'errore di decidere che il modo migliore per risolvere il siloing UX è escluderli completamente. SAFe "consente ai team Agile" di fare la propria "Lean UX". Poiché sempre più aziende comprendono il valore dell'incorporazione di specialisti UX e un processo UX completo, SAFe sta andando nella direzione sbagliata.

L'assenza di spiegazioni sull'UX e sui loro processi dalla formazione e dai libri Agile ha portato i team di tutto il mondo a escludere o ridurre al minimo il coinvolgimento di designer di prodotti specializzati.

  • Quando immagini erroneamente che l'esperienza utente disegna solo riquadri sulle pagine, è facile presumere che "posso fare quel lavoro". Come tanti partecipanti all'audizione di American Idol sono sicuri di essere il miglior cantante del pianeta, la maggior parte dei product manager e degli ingegneri si auto-valuta come bravi a UX. Questo normalmente significa che credono di essere bravi a disporre gli schermi. Ma poiché questo articolo spiega cosa c'entra davvero nel lavoro di UX, vedrai come uno specialista di UX non vedrebbe uno sviluppatore che crea wireframe come qualcuno a cui dovrebbero essere assegnati compiti di UX.
  • I libri su Scrum suggeriscono che se uno specialista UX diventa un collo di bottiglia, dovrebbe addestrare ruoli non UX per svolgere il suo lavoro. Questo tipo di decisione è raramente suggerito per altri ruoli nello sviluppo del software; nessuno vorrebbe che uno sviluppatore inesperto o inesperto esegua la codifica, anche dopo un bootcamp o dopo aver letto un libro sulla programmazione. Non suggeriremmo mai che se uno sviluppatore diventa un collo di bottiglia, dovrebbe addestrare il project manager a fare un po' di programmazione.
  • I responsabili delle assunzioni che credono erroneamente che l'UX sia un lavoro artistico (UI) assumono artisti per fare un lavoro di UX. Non vi è alcuna sovrapposizione educativa tra una laurea in UX e in UI. I talenti naturali spesso non si sovrappongono; qualcuno di grande in UX potrebbe essere un artista scadente e viceversa. Assumere per "UX/UI" spesso ti offre un grande artista con esperienza, competenza, processo o istruzione UX minimi.

Coloro che guardano solo alla linea di fondo vorrebbero tagliare il budget dando compiti di UX a persone che potrebbero non avere istruzione, esperienza, competenza, abilità o talento naturale sulla UX. Ma questo è miope e può portare a scarsa produttività, efficienza, cultura, prodotto e soddisfazione del cliente.

L'importanza di incorporare specialisti esperti in UX in Agile

Alla fine del 2018, la società di consulenza gestionale McKinsey & Company ha pubblicato "The Business Value of Design", un rapporto sulla ricerca effettuata con oltre 300 aziende.

Hanno scoperto che "il design è l'unico modo in cui le aziende possono distinguersi dalla massa". Quando i concorrenti hanno set di funzionalità ravvicinati, cosa li distingue? Il design a volte è pensato solo come l'estetica o ciò che lo rende simile al nostro marchio. Ma quando viene utilizzato con "UX", design indica l'architettura delle funzionalità e le decisioni prese su schermate, passaggi, flussi, layout, processi, organizzazione e menu.

L'esperienza utente fa parte del processo di miglioramento continuo, cercando sempre di comprendere meglio gli utenti e selezionare e progettare le funzionalità e il prodotto che meglio soddisfano le loro esigenze, risolvono i loro punti deboli e apportano loro un'innovazione significativa.

McKinsey ha anche riferito che "Le aziende devono abbracciare il design in modo olistico e all'inizio del processo piuttosto che vederlo come un piccolo strumento che si adatta in seguito". I team che presuppongono che l'attenzione all'esperienza dell'utente sia qualcosa che può essere ridotta al minimo, esclusa o eseguita dopo il rilascio del prodotto stanno adottando l'approccio sbagliato.

McKinsey ha raccolto dati quantitativi e ha scoperto che le aziende che hanno abbracciato la progettazione UX hanno generato il 32% in più di entrate e il 56% in più di rendimenti per gli azionisti in un periodo di 5 anni. Dichiarare la tua azienda come "incentrata sull'utente" non è sufficiente. Devi seguire il percorso integrando professionisti e processi di UX dalla pianificazione e portfolio fino allo sviluppo e al QA.

Processi di sviluppo software con e senza UX

Se la tua azienda non include specialisti UX nel processo di progettazione e sviluppo del software, molto probabilmente il tuo processo sarà simile all'immagine qui sotto.

Processo di progettazione e sviluppo del software senza specialisti UX.

Processo di progettazione e sviluppo del software senza specialisti UX.

Un cliente, un product manager, un CEO o qualcuno con la visione dice all'ingegneria cosa vogliono. Engineering lo costruisce, lo testa e lo ottiene su un server di staging o di produzione. La persona con la visione poi la vede e, non lo sai, non è felice. Vogliono qualcosa di diverso o hanno cambiato idea.

L'ingegneria deve quindi tornare all'inizio, scoprire cosa vuole questa persona ora, costruire, testare e incrociare le dita che questo è il fascino.

Processo di progettazione e sviluppo del software con UX coinvolta.

Processo di progettazione e sviluppo del software con UX coinvolta.

Se hai esperti di UX nel team, il processo è abbastanza diverso. Quella persona con la visione arriva alla UX con le idee, i dati e i punti deboli dei clienti. UX scorre le attività nel suo processo di progettazione incentrato sull'utente e quindi verifica questi concetti prima che l'ingegneria scriva una riga di codice. Ciò garantisce che il prodotto o la caratteristica che stiamo considerando di costruire sia la corretta esecuzione dell'idea giusta per i nostri clienti target.

I test potrebbero portare alla luce alcuni difetti, il che consente all'UX di iterare e spesso testare di nuovo. Dopo il processo di UX, hai un design completamente controllato pronto per essere consegnato all'ingegneria.

Se qualcuno cambia idea lungo la strada, quella persona parla con UX invece di inserirla come richiesta di modifica agli sviluppatori. L'esperienza utente esegue interferenze durante il processo e nulla viene inviato all'ingegneria senza che l'esperienza utente sia coinvolta in progetti, decisioni e test su clienti reali o archetipici.

I cambi di idea a questo punto non sono disastri poiché il costo per qualcuno di cambiare idea a questo punto è minimo. All'ingegneria non sono stati consegnati i progetti, non sono stati avviati e non hanno nulla da ricostruire. L'esperienza utente esegue iterazioni sui loro progetti e può eseguire test sugli utenti per garantire che le idee corrispondano a una buona e forte corrispondenza con la base di clienti. I cambiamenti di opinione consumano tempo, ma l'impatto complessivo sul budget è minimo.

UX ha un processo formalizzato

La progettazione incentrata sull'utente (UCD) è un processo formalizzato che include attività che indirizzano gli specialisti di UX alla ricerca, progettazione, prototipazione, test su utenti reali o archetipici e quindi iterati in base agli apprendimenti dai test.

Progettazione incentrata sull'utente (UCD) e visualizzazione Agile UX.

Concentrandoci su alcune di queste aree, iniziamo con i requisiti e le prime discussioni su funzionalità e progetti. Quando UX ottiene per la prima volta requisiti e altre informazioni sul progetto, è importante iniziare subito a collaborare. UX NON dovrebbe scoprire in seguito di aver progettato qualcosa che non può essere costruito.

Inizia coinvolgendo lavoratori o manager UX quando i product manager o i project manager stanno decidendo le caratteristiche e la definizione delle priorità. Un progetto senza valore per l'utente può essere rimosso, risparmiando tempo e denaro indicibili. È qui che entra in gioco la massimizzazione della quantità di lavoro non svolto. Il prodotto e l'ingegneria dovrebbero supportare l'esperienza utente quando creano meno lavoro per l'ingegneria riducendo o rimuovendo funzionalità o interi progetti. Tuttavia, troppo spesso, i progetti sono attaccati dall'ego e i compagni di squadra spesso escludono l'UX da queste prime conversazioni in modo che il progetto venga finanziato.

La ricerca è una parte importante di ciò che fa UX. Non è incentrato sull'utente senza coinvolgere gli utenti. Le statistiche e i dati quantitativi sono ottimi, ma non c'è sostituto per intervistare gli utenti, comprenderli a fondo e ottenere dati qualitativi. UX vuole sapere il perché e non solo il cosa.

La ricerca UX porta anche i compagni di squadra sulla stessa pagina unendo tutti attorno alle persone, archetipi di clienti target. Sulla base delle interviste con gli utenti, aggreghiamo ciò che impariamo e riduciamo tutti a 6 o meno persone. Cosa li motiva? Di cosa hanno bisogno? Dove sono le opportunità per la nostra azienda, prodotto o servizio?

UX Agile: illustrazione di diversi personaggi

Il miglior uso delle persone sarebbe includerle ovunque. Il prodotto immagina le caratteristiche basate su persone (e dati validi). Progettazioni UX basate sulle persone. Test di qualità immaginando che siano queste persone. Il marketing può aggiungere i loro dati demografici e altri dettagli, ma anche loro dovrebbero considerare come la voce del marchio, i social media e la pubblicità parlano alle persone.

Le persone aiutano i lavoratori non UX ad allontanarsi da "Beh, mi piace in questo modo" o "Al CEO piace in questo modo". Stiamo progettando per questi clienti target e se tu o il CEO non rientrate nelle persone, l'UX non è influenzato dall'ego o dalle preferenze personali. La UX deve rimanere focalizzata sul cliente.

L'architettura dell'informazione ha a che fare con le gerarchie, la struttura e le tassonomie. Potrebbe essere la navigazione del sito o il modo in cui i prodotti sono classificati in un database di eCommerce. Vogliamo assicurarci che i clienti trovino facilmente i prodotti per categorie, metadati e filtri.

Il design dell'interazione , a volte chiamato anche design dell'esperienza, è ciò a cui la maggior parte delle persone pensa quando immagina l'UX. Questi sono i wireframe e i prototipi, i progetti di progetti e concetti. Questi mostrerebbero flussi di processo, layout, menu, interazioni, percorsi, scelte e molto altro ancora.

I prototipi UX sono come wireframe portati in vita. Sono modelli digitali interattivi cliccabili. Non dobbiamo scrivere codice; abbiamo un software che ci aiuta a crearli rapidamente. Le aziende alla ricerca di prototipi più realistici utilizzano Axure poiché ha logica condizionale, variabili, gesti di scorrimento mobile, trascinamento e rilascio e tutti i tipi di trigger di eventi. Puoi creare prototipi per qualsiasi tipo di dispositivo.

La prototipazione UX viene eseguita per:

  • Brainstorm
  • Collaborare
  • Iterare
  • Esplora le soluzioni
  • Presentazione agli investitori (per le startup)
  • Testare il prototipo per vedere se la soluzione si collega bene con il pubblico di destinazione.
  • Fornisci un modello interattivo a sviluppatori o altri compagni di squadra, che spesso è preferito alle pagine di documentazione (e nessun modello cliccabile).

Ora si passa al test dell'utente , chiamato anche test di usabilità, che avviene durante il processo di UX e prima che l'ingegneria scriva una riga di codice. Devi testare concetti e progetti per assicurarti che l'idea e l'esecuzione siano fantastiche per i clienti target.

I test degli utenti metteranno in luce eventuali difetti, dando alla UX la possibilità di ripetere le idee, il che è poco costoso a questo punto poiché non c'è nulla da costruire o ricostruire per l'ingegneria.

Ci sono 5 ragioni principali per cui UX esegue i test prima di consegnare all'ingegneria:

  1. Uso ottimale del tempo e delle risorse dell'ingegneria. Se vuoi che i partecipanti al test vedano un prodotto finito creato dagli ingegneri, devi costruirlo e testarlo per i bug. Se il test UX porta alla luce le modifiche necessarie, gli sviluppatori dovrebbero ricostruire e il QA dovrebbe ripetere il test. Se i test UX hanno mostrato un fallimento più ampio del concetto, ciò potrebbe significare che il tempo dell'ingegneria è stato completamente sprecato poiché questo non è un codice che finirà da nessuna parte. Il concetto dovrebbe essere ripensato, riprogettato e appena testato.
  2. Itera dietro le quinte. Quando le aziende lo costruiscono, lo spediscono, lo ripetono e lo costruiscono e lo spediscono di nuovo, significa che i clienti vedono una varietà di versioni. Stanno vedendo i lavori in corso e osservando la preparazione della salsiccia. Questa è spesso un'esperienza frustrante e confusa che richiede ai clienti di continuare ad apprendere di nuovo un sistema in evoluzione. È meglio scorrere dietro le quinte nel processo UX ed essere chiari con i tester che si tratta di un prototipo o di una versione dimostrativa.
  3. Monitoraggio e misurazione. Se un nuovo concetto viene rilasciato dal vivo, i ricercatori UX non hanno un buon modo per guardare le persone usarlo, porre loro domande e ottenere il tipo di feedback di cui l'UX ha bisogno per determinare se qualcosa è pronto o necessita di un'altra iterazione. UX vuole sempre sapere il perché, il qualitativo e non solo il cosa o il quanti. In che modo gli utenti spendono, convertono, coinvolgono, ecc? Evitare i test UX adeguati rende più difficile diagnosticare e risolvere problemi o punti deboli dei clienti.
  4. Il test UX si ripaga da solo. Il test UX non è una spesa enorme. Alcuni strumenti di test di terze parti richiedono meno di $ 100 per partecipante al test, altri richiedono un impegno annuale minimo di migliaia di dollari. Non si tratta di spese enormi, considerato il budget complessivo dell'azienda per il processo di sviluppo del software e l'importanza di un feedback tempestivo sui test. I cicli di test degli utenti costano quasi sempre meno e si muovono più velocemente rispetto a far costruire ai programmatori qualcosa che potremmo dover annullare o ricostruire di nuovo.
  5. Il test dell'utente risolve gli argomenti. Se la tua azienda non consente agli specialisti dell'esperienza utente di prendere la decisione finale su come progettare il prodotto, potresti trovare l'esperienza utente in conflitto con il prodotto, l'ingegneria o uno stakeholder quando ci sono idee diverse su ciò che dovrebbe essere costruito e rilasciato al cliente. O se UX avesse due idee forti e si chiedessero quale si connette meglio con i clienti? La soluzione qui è il test degli utenti.

UX può prototipare i concetti. È meglio ridurre la concorrenza ai due migliori design, soprattutto se riesci già a trovare compromessi tra idee e membri del team. Ciò significa che non stiamo testando ciò che vuole l'UX rispetto a ciò che piace al prodotto rispetto a ciò che piace al capo dell'ingegneria rispetto a ciò che lo Scrum Master pensa suona come una buona idea rispetto a ciò che piace al compagno di vita del CEO.

I test utente consentono ai clienti di parlare e ti aiutano a trovare la giusta direzione per le funzionalità o il prodotto. Risolve le discussioni fornendo ai team dati quantitativi e qualitativi concreti che dicono a tutti quale idea è in grado di portare la massima soddisfazione del cliente.

Non è un design incentrato sull'utente senza coinvolgere l'utente. Ciò significa che cerchiamo e testiamo con clienti reali o archetipici piuttosto che indovinare, supporre o "spedire semplicemente". Dobbiamo assicurarci che ciò che "spediamo" sia stato verificato attraverso i test degli utenti e sia un'eccellente esecuzione di una grande idea.

Cosa succede quando la UX viene aggirata o ridotta?

Skype ha recentemente annunciato che la sua riprogettazione del 2017, che mirava a renderlo più simile a Snapchat, è stata un fallimento. Gli utenti non volevano, non avevano bisogno o apprezzavano le nuove funzionalità. Il contraccolpo è stato abbastanza grande che Skype ha annunciato nel 2018 che avrebbe riprogettato nuovamente Skype. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Best practices UX agile: illustrazione di una riprogettazione di Skype mal eseguita.

La riprogettazione di Skype 2017

Gli esperti di UX avrebbero saputo in molte fasi del loro processo che queste funzionalità potevano essere indesiderate o non funzionare correttamente. La ricerca con gli utenti target potrebbe aver rapidamente rivelato che non volevano che Skype diventasse Snapchat. Uccidere il progetto o cambiare rotta a questo punto avrebbe potuto far risparmiare a Skype milioni di dollari, oltre a cattiva stampa e alienazione dei clienti.

Anche se la ricerca UX fosse stata aggirata, testare un prototipo UX sugli utenti avrebbe chiarito che i clienti non volevano che Skype andasse in questa direzione. Con UX ancora in fase di elaborazione, l'ingegneria non ha ancora scritto una riga di codice. Ciò avrebbe potuto far risparmiare tempo, denaro e risorse umane enormi, celebrando la semplicità e il lavoro che l'ingegneria non doveva fare.

Processo UX agile

Ricorda i principi del manifesto Agile. La tua massima priorità è la soddisfazione del cliente attraverso la creazione di software di valore. Offri ai lavoratori (UX) l'ambiente e il supporto di cui hanno bisogno, fidandoti di loro per portare a termine il lavoro. Massimizzare la quantità di lavoro non svolto. L'attenzione continua al buon design migliora l'agilità.

I progetti che stanno andando avanti devono dare all'UX una grande pista in modo che possano iniziare la ricerca, la progettazione e i test appropriati. Non invitare UX alla tua riunione di lancio e sorprenderli con la richiesta che i wireframe finali debbano essere consegnati in pochi giorni. Non è UX.

Non considerare questo come Big Design Up Front (BDUF), che è un termine progettato per far rabbrividire le persone e dichiarare che questo è qualcosa da cui dobbiamo allontanarci. Quando un progetto o una funzionalità è grande o nuova, è necessario che l'esperienza utente scorra la maggior parte, se non tutto, il processo di progettazione centrato sull'utente. Per UX, la parte più piccola possibile per una funzionalità più ampia è il flusso di lavoro o il processo dell'utente. Se progettiamo e testiamo qualcosa di più piccolo, corriamo il rischio di non ottenere il quadro generale della vera esperienza dell'utente.

Ad esempio, se stiamo progettando un flusso in cui gli utenti si registrano e acquistano, non possiamo semplicemente progettare campi di selezione della password e inviarli all'ingegneria. Se l'UX funzionasse in piccoli pezzi, quando verrebbe testato l'intero processo? Non possiamo conoscere la reazione dell'utente all'intero flusso senza testare l'intero flusso... il che significa che l'intero flusso deve essere progettato prima di passare ai test di usabilità.

Laddove le funzionalità, le storie o le correzioni sono piccole, i professionisti dell'esperienza utente possono eseguire un sottoinsieme del processo di progettazione incentrato sull'utente e lavorare più rapidamente. L'UX andrà sempre il più veloce possibile, ma un grande specialista di UX farà tutto il possibile per evitare di sacrificare la qualità del lavoro svolto. Nella battaglia veloce vs buono, l'esperienza utente sceglierà sempre il buono rispetto al veloce... e dovresti farlo anche tu.

Budget e scadenze sono ciò che impedisce all'UX di ricevere feedback e iterare rapidamente. I professionisti della UX vogliono sempre un feedback e la possibilità di migliorare il prodotto, con l'obiettivo di progettare ciò che funziona davvero per i clienti. Coinvolgere i professionisti dell'UX già nella gestione e pianificazione del portafoglio consente all'UX di stimare il tempo e il budget di cui avranno bisogno; queste non dovrebbero poi essere sorprese o cause di conflitto.

Un UX Practitioner fa parte dell'Agile Team

Incorpora il tuo UX Designer nel team Agile. Invitali a pubblicare pianificazione, stand-up, retro e ogni riunione in cui si potrebbe discutere di UX. Consenti a UX di stimare il proprio tempo durante la pianificazione del rilascio in modo che non ci siano sorprese sui tempi richiesti dalle attività UX. Non prendere decisioni senza di loro. Se il tuo compagno di squadra UX ha perso la riunione, aspetta di trovarlo di persona, tramite chat, e-mail o qualsiasi metodo utilizzato dalla tua azienda.

Assegna domande, ambiguità o bug al tuo compagno di squadra UX in JIRA o in qualsiasi sistema di tracciamento dei bug che utilizzi. Assicurati che i problemi di UX siano nello stesso sistema degli altri problemi; non eliminare i problemi di UX in una scheda Trello se stai utilizzando VersionOne per tutto il resto.

Dopo che l'UX ha avuto la sua lunga pista, se è stato richiesto per questa funzionalità o prodotto, una best practice è che l'UX sia 2 o più Sprint prima dell'ingegneria. UX può correre insieme a te. Ricevi un sacco di storie di tecnologia o di riparazione del debito tecnologico nell'arretrato. In questo modo, se il processo creativo e ciclico di UX è in ritardo o richiede più sprint, gli sviluppatori possono essere davvero agili. Invece di attendere l'esperienza utente, possono passare a dei frutti a bassa pendenza a cui il prodotto o l'ingegneria hanno dato la priorità.

Considera anche le risorse, l'allocazione e il personale. A seconda delle dimensioni del progetto, assegnare non più di 3 progetti a un designer UX. Se hai ricercatori UX esperti separati, che fanno anche test e analisi, assegna un ricercatore a non più di 3 designer UX. Se il tuo professionista UX è noto come a forma di T, il che significa che è anche qualificato ed eccellente nella ricerca, nei test e in altre sottospecialità UX, assicurati che non sia accidentalmente un collo di bottiglia essendo assegnato a troppi progetti.

Misurare i risultati

Senza la soddisfazione del cliente, potresti non avere clienti. Puoi utilizzare le metriche di soddisfazione del cliente per determinare in che modo il miglioramento dei tuoi processi attraverso l'integrazione dell'esperienza utente ha apportato cambiamenti positivi.

  • Meno reclami
  • Recensioni delle app migliori
  • Valutazioni delle app più elevate
  • Meno ticket di supporto
  • Meno chiamate al call center
  • Semantica più positiva dei post sui social
  • Più installazioni di app, meno disinstallazioni
  • Aumento dell'AOV (valore medio dell'ordine).
  • Tasso di conversione più alto

Illustrazione degli obiettivi DevOps

Gli obiettivi e i risultati di DevOps sono misurabili.

Puoi anche misurare gli obiettivi DevOps desiderati come il tempo di commercializzazione e il tempo tra le correzioni. Quanto tempo impiegano storie, progetti ed epiche per arrivare sul mercato prima e dopo la tua rivoluzione UX? È probabile che le stime del tempo degli sviluppatori siano più accurate quando hanno finalizzato i progetti UX su cui basare le loro stime rispetto al lavoro dalle storie o qualsiasi cosa tu stia facendo ora.

Se l'esperienza utente fornisce progetti e quelli vengono seguiti, speriamo che l'ingegneria abbia meno lavoro riducendo le modifiche a sorpresa e le ricostruzioni. Migliore progettazione dell'esperienza utente prima, meno correzioni dopo.

Agile UX è un investimento che si ripaga di più

Molti project manager vedono l'UX come una linea di budget che può essere rimossa o ridotta e i responsabili delle assunzioni sono entusiasti all'idea di combinare le attività UX con un altro ruolo. Tuttavia, sempre più aziende stanno imparando che non c'è sostituto per investire in un adeguato processo UX intrapreso da specialisti UX formati ed esperti.

Eric Ries, autore di The Lean Startup , chiede: “E se ci trovassimo a costruire qualcosa che nessuno voleva? In tal caso, cosa importava se lo facessimo in tempo e rispettando il budget? Anche se la tua organizzazione non utilizza la metodologia Lean, l'avviso resta valido. I risultati desiderati da DevOps fanno eco a questo quando miriamo a costruire la cosa giusta per il cliente, migliorare la soddisfazione del cliente e sviluppare funzionalità con un elevato valore per il cliente.

Conoscere il cliente, coinvolgerlo nel processo e costruire per le sue reali esigenze e preferenze è in definitiva più importante di tempistiche, budget, strutture e strumenti. Fidati del fatto che se crei le giuste esecuzioni delle giuste idee, le entrate ci saranno.