Chi fa la UX in un progetto di mischia?

Il designer dell'interazione

UX! = UI Hai bisogno di un designer esperto di interazioni per offrire una buona esperienza utente, contrariamente a quanto si crede comunemente che sia non un programmatore. Per tutti voi programmatori che pensano di poter fare UX (che include me) lasciatemi dire questo. Essere bravi in interaction design richiede almeno tanto tempo quanto essere bravo a programmare. Quanto tempo hai dedicato al puro design dell'interazione?

Nella fase iniziale è responsabilità degli interaction designer di:

1. Estrarre gli obiettivi effettivi della soluzione dal proprietario del prodotto
2. Definisci i personaggi che useranno la soluzione.
3. Scrivi scenari che sono storie su come verrà utilizzata la soluzione.
4. Compilare un documento di progettazione che lasci poco spazio all'ambiguità dal punto di vista UX

Durante il progetto è compito dei designer di interazione assicurarsi che tali linee guida siano seguite e affrontare eventuali ulteriori problemi che si presenteranno (e lo faranno).

Molti programmatori prenderanno in considerazione questo approccio, sono sicuro che poiché tutti pensano che siano l'eccezione che può progettare interfacce "meravigliose", probabilmente no. D'altra parte un buon interaction designer - relazione con il programmatore è spesso molto carino per il programmatore e non deve lottare contro una "specifica stupida". Sfortunatamente i buoni designer di interazione sono difficili da trovare nella mia esperienza, ma sono là fuori.

Come sempre consiglio vivamente i libri di Alan Coopers sull'argomento ("About Face" e "The Inmates stanno gestendo l'asilo")

Suggerisco di organizzare il lavoro del ragazzo UX allo stesso modo del resto del team. Dovrebbe essere considerato un membro di uguale livello della squadra, partecipare agli standup e comunicare a stretto contatto con i programmatori.

Idealmente, i mock-up dovrebbero essere fatti almeno uno sprint in anticipo, ma per le caratteristiche più piccole potrebbe avere senso considerare la possibilità di creare mock-up come sottotabella di una storia pianificata per l'iterazione corrente.

Come sempre con agilità, usa il buon senso, sperimenta approcci diversi e atteniti a quello che funziona bene per la tua situazione specifica.

Secondo me questo è un caso particolare che deve essere gestito in modo speciale. Lo Scrum Master non parteciperà sicuramente a questo - non è affatto il suo ruolo. Il team è di solito un gruppo di sviluppatori e molti di loro non hanno esperienza con UX e sarà inutile perdere tempo a costringerli a farlo. Assumerai un esperto di UX e l'esperto non farà parte del team - il team dovrebbe essere interfunzionale e l'esperto di UX probabilmente non sarà uno sviluppatore. Anche l'esperto di UX non sarà sul progetto per tutta la sua durata. L'esperto di UX lavorerà con il proprietario del prodotto uno sprint in avanti per preparare mock-up e wireframes per la ripresa di user story in modo che il team sappia cosa dovrà essere fatto nel prossimo sprint - i mock-up saranno disponibili durante la riunione di pianificazione. Non ci dovrebbero essere troppi rifiuti (tranne rare occasioni in cui i requisiti del cliente cambieranno molto) perché il proprietario del prodotto sa quali sono le storie utente più prioritarie che verranno fatte nel prossimo sprint.

Modifica:

Ho fatto ulteriori ricerche perché sapevo di aver letto qualcosa da qualche parte e alla fine l'ho trovato in Avere successo con Agile: sviluppo software Utilizzo di Scrum di Mike Cohn . Mike discute esattamente il ruolo del progettista di UX nel team. La sua descrizione iniziale è simile alla mia e considera il suo naturale cambiamento quando la compagnia cambia il metodo di sviluppo da cascata a Scrum, ma in seguito la conclude come metodo non raccomandato. Il motivo è che se i progettisti di UX non fanno parte del team possono pensare a se stessi come al team separato e non devono condividere l'impegno del team di sviluppo.

Nonostante questa risposta di @Adam Byrtek sembra quella giusta. Fai diventare UX parte del team e fagli cooperare con gli sviluppatori sugli user story attualmente implementati. Non ci vorrà tutto il tempo del ragazzo UX, quindi collaborerà anche con il proprietario del prodotto o il cliente per preparare simulazioni e wireframe per la realizzazione di uno o due sprint.

Sono iscritto al alertbox di Jakob Nielsen (principalmente per le sue critiche a fastidiose pratiche di web design) e ricordo di aver letto recentemente alcuni articoli sull'argomento (anche se difficilmente ho una minima comprensione dell'intero processo di sviluppo agile), forse sarebbero di qualsiasi utilità per te:

• Progetti di esperienza utente agile
• Progetti di sviluppo e usabilità agili

Per "Scrum da manuale":

Prima di tutto, Scrum Masters non collabora con i proprietari dei prodotti - beh, in nessun altro senso se non che l'intero team, compresi SM e PO, collabora per creare il sistema.

In secondo luogo, i team Scrum dovrebbero essere omogenei con i membri del team interfunzionale. Quindi non avresti un "UX Guy".

Inoltre, probabilmente non costruisci l'UX uno Sprint prima del codice funzionale. Le caratteristiche vengono consegnate completamente all'interno di un singolo Sprint. Se l'UX associato a una funzione è troppo complesso da consegnare insieme al codice funzionale in un singolo Sprint, allora si incide l'intera caratteristica su qualcosa che può essere fatto, compresi gli elementi UX, in un singolo Sprint.

Chi fa UX su un progetto a cascata? Chi sviluppa lo sviluppo di mainframe su un progetto XP?

La metodologia del progetto non ha importanza. Ogni progetto tecnologico richiede determinati ruoli specializzati. A volte, un progetto può andare via senza un "interaction designer" completamente autorizzato e legato (qualunque cosa significhi). A volte hai bisogno di qualcuno specializzato. Ma lo stesso si potrebbe dire per ogni altro ruolo.

Quindi sulla seconda domanda su come fornire un'esperienza utente di alta qualità utilizzando agile. L'abbiamo gestito nell'ultimo progetto di mischia in cui ero coinvolto coinvolgendo presto e spesso l'analista di business e il cliente. Inoltre, avevamo uno sviluppatore che aveva un occhio particolarmente buono per UX. Tendeva a fare piccole modifiche alle UI a cui gli sviluppatori stavano lavorando dopo che avevano commesso dei commit.

Non abbiamo consegnato l'UX perfetto alla fine di ogni sprint. Le demo hanno generalmente esposto un problema o due da una prospettiva UX. Ma abbiamo fissato quelli per il prossimo sprint (se ne valessero la pena per il cliente) e quando abbiamo rilasciato la produzione avevamo una UX molto solida.

Se per UX si intende il progettista dell'interfaccia utente, sono solo un altro ruolo o risorsa per il team. Il design dell'interfaccia utente, come qualsiasi progetto, taglia un progetto. C'è una quantità ragionevole di lavoro di architettura / progettazione che dovrebbe essere fatto in anticipo e c'è una quantità che può essere fatta man mano che si procede.

Va notato che le attività di progettazione dell'interfaccia utente spesso non rientrano nello stesso ambito di uno sprint di sviluppo. Nella progettazione di un componente dell'interfaccia utente, il progetto potrebbe richiedere numerosi sprint da implementare.

In pratica, tendo a trovare i progettisti UI / UX che hanno bisogno di un tempo di consegna ragionevole per gestire aspetti che devono essere coerenti attraverso la soluzione. Mi piace pensarlo come un'architettura software. La progettazione di componenti specifici può spesso essere eseguita in sprint prima dell'implementazione, ma io tendo a scoprire che una volta che i progettisti hanno iniziato, possono superare l'implementazione. Gli sprint successivi tendono ad essere buoni posti per implementare / esplorare il look & feel così come ottenere feedback di usabilità quando la soluzione inizia a prendere forma. I risultati di questi esercizi successivi sono riportati nella pianificazione del prossimo sprint.