11 cose che ho imparato durante il mio primo anno di lavoro come UX/UI Designer in una software house

In realtà è passato più di un anno da quando ho iniziato il mio primo lavoro come UX/UI Designer presso una software house. Mentre alcune persone pensano che non sia il posto migliore per iniziare la tua esperienza UX/UI a causa della varietà di progetti e dell'indipendenza richiesta, non ho avuto molti problemi con esso. Lavoravo come assistente di architettura per uno studio piuttosto grande e come "freelance" per un'organizzazione studentesca di pubbliche relazioni e grafica.

Tuttavia, non è stato tutto sole e arcobaleni . Mi ci sono voluti meno di quattro mesi tra la decisione di cambiare il marchio e l'inizio del mio primo lavoro e, di conseguenza, non sono riuscito a imparare e comprendere ogni area necessaria per la posizione. In generale, ai giovani non viene insegnato molto sull'importanza della cooperazione tra diversi team nelle aziende, principalmente la parte commerciale e di vendita del progetto.

Ecco alcuni problemi che ho riscontrato durante il mio primo anno nella progettazione di UX/UI:

1.MVP e KPI

Questi erano concetti quasi completamente estranei che ho incontrato mentre lavoravo al mio primo progetto. Certo, era un progetto interno, ma il lavoro è stato casuale e ho potuto chiedere a tutti i partecipanti al progetto varie questioni. È stato allora che ho conosciuto gli analisti aziendali e il loro ruolo nel progetto. Ho imparato a conoscere il lato commerciale dei prodotti, che, come si è scoperto, ne è la parte più essenziale nelle software house. Avendo esperienza in un settore precedente, MVP e KPI potrebbero essere esistiti nascosti sotto altri nomi, ma la loro determinazione pratica durante i workshop con i clienti è stata ciò che ho sperimentato qui.

2. Requisiti aziendali, raccolta dei requisiti, conferma degli stessi con il cliente, effettuazione delle conferme

Secondo me, questa è la parte più essenziale del lavoro di un designer di prodotti. In azienda, ero parzialmente o totalmente responsabile della raccolta dei requisiti e della loro conferma con il cliente, a volte in collaborazione con un analista aziendale che penetrava delicatamente nella struttura del cliente e raccoglieva i requisiti aziendali. In questa fase, è essenziale conoscere il settore e i processi del cliente, spiegare al cliente perché lo stiamo facendo (se non lo sa) e, in realtà, raccogliere costantemente queste informazioni sul prodotto che si sta progettando. L'ho fatto scrivendo le storie degli utenti, i criteri di accettazione e i potenziali rischi. Per il cliente, l'aspetto visivo del prodotto che ordina da noi è già importante in questa fase, quindi la forma più attraente per raccogliere tali requisiti è realizzare mockup mid-fi, ad es. mockup con contenuti parzialmente proposti. È importante ricordare che questa è una delle tante proposte che possono essere presentate, quindi non vale la pena affezionarsi a una tale versione del progetto. In questa fase, devi anche tenere presente la chiarezza del flusso di informazioni, stabilendo come i requisiti vengono raccolti e confermati dal cliente. Se non si chiude questa fase, non è possibile procedere con lo sviluppo a causa dei potenziali rischi, come la modifica delle decisioni prese o l'aggiunta di nuovi requisiti, che influiscono sulla pianificazione del progetto. Succede anche che creiamo un prodotto, raccogliamo requisiti, forse siamo già nella fase di accettazione della documentazione o addirittura di sviluppo, e improvvisamente l'azienda (cioè gli utenti) dichiara di non comprendere il processo.

3. Stima del tempo: sottovalutazione o sovrastima

Il fatto è che la maggior parte del tempo viene speso per creare prototipi, personalizzare librerie esistenti o crearne di personalizzate e scrivere documentazione. Spesso è molto difficile per i designer alle prime armi stimare il tempo che dedicheranno a questo, e in qualche modo devono farlo. Diverse volte ho sottovalutato il tempo dedicato a un determinato compito, e una volta l'ho persino sopravvalutato, ma a mio avviso questa abilità viene con l'esperienza. È bene avere un certo margine di tempo in una situazione del genere: è sempre meglio consegnare qualcosa più velocemente che in ritardo.

4. Il timone, la vela e la nave: fiducia in se stessi

Finora, nella mia esperienza, ho dovuto prendere il controllo solo di piccoli aspetti dei progetti, come il coordinamento delle installazioni nei soffitti delle camere d'albergo e dei corridoi o le cosiddette parti Back of House. Come designer di UX/UI, dopo essere stato assegnato ufficialmente al mio primo progetto, ero molto più responsabile del prodotto, poiché ero l'unico designer del team di progetto. Da un lato, questo è stato nobilitante per me, ma dall'altro è stata una grande responsabilità e fiducia complessiva da parte dell'azienda. Fino ad ora non so se mi andava bene, forse era troppo presto per essere interamente responsabile del prodotto come persona con poca esperienza nel settore. È stato un bel test per me, ma per quanto ne so, sia il cliente che il team erano contenti di me, quindi immagino di essere riuscito a svolgere bene queste attività del progetto per quel momento, dopo tutto

5. Ricerca nella fase UX, o meglio, la sua mancanza

I clienti spesso non sono a conoscenza del punto di condurre ricerche UX in fase di progettazione (e se lo fanno, ringrazia il tuo reparto vendite per un cliente così informato!). Questo è lo svantaggio generale delle software house. Nelle aziende di prodotti, dalle mie conversazioni ai meetup e alle conferenze, era chiaro che sfortunatamente questo non è lo standard anche quando si tratta del processo di progettazione. Tuttavia, vale sempre la pena condurre la presentazione al cliente sulla ricerca UX e spiegare perché è importante e quanto può far risparmiare tempo. Il primo esempio dalla riva - stavo sviluppando un prodotto il cui processo aziendale era piuttosto complicato da capire, come si è scoperto - non solo per me, perché gli utenti non l'hanno capito bene. Insieme al cliente, siamo dovuti tornare alla fase di raccolta dei requisiti, raccoglili di nuovo dopo aver appreso di più sul processo, migliora i modelli e continua lo sviluppo. Ciò avrebbe potuto essere evitato se avessimo avuto un momento per prototipare i mockup e condurre test di usabilità con futuri utenti (dipendenti di uno dei team presso il cliente). Anche allora, avremmo individuato i problemi che sono emersi molto più tardi.

6. Creazione della documentazione

Questo è davvero un lavoro necessario per la verifica da parte del cliente. Per creare la documentazione UX, ho utilizzato l'articolo dettagliato di Autentika sulla preparazione della documentazione (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/in polacco).

Mi è stato molto utile nel crearlo, ma non è stato sufficiente al 100%. I diagrammi di processo nel prodotto che stavo creando in quel momento erano MOLTO complicati, quindi sono andato dagli analisti per un motivo e, con il loro aiuto, ho creato una specifica del caso d'uso e requisiti di processo più dettagliati con criteri di accettazione. Certo, ora farei tale documentazione in modo un po' più diverso, ma a quel punto ne ero abbastanza soddisfatto.

7. Metodologie? Esistono? (No)

La maggior parte delle software house cerca di lavorare in modo iterativo, con un approccio individuale al cliente. È difficile pianificare i processi del libro in tali situazioni, soprattutto perché la ricerca board-to-board viene raramente eseguita perché "non c'è tempo" o lavori come unico designer. In definitiva, la metodologia di progettazione si basa su Agile, ma i framework sono abbastanza simili tra loro e possono piuttosto essere suddivisi in fasi Discover, Define, Design, Develop e Deliver/Deploy (come una 5D estesa con una fase da Double Diamond) .

8. Capire il cliente

Questo è il fulcro della collaborazione con il cliente a livello di progettazione dell'applicazione. Spesso i clienti (soprattutto di settori non IT) non sanno cosa sia la UX, di cosa si tratti, quali problemi possa eliminare nelle primissime fasi del progetto. Un buon esempio dalla mia esperienza sarebbe quando stavo presentando prototipi lo-fi per completare i requisiti aziendali. L'incontro ha coinvolto anche il team di marketing del cliente, che era molto incerto… sul design dei mockup lo-fi. Dal momento che non erano tutti sulla stessa pagina, ho nuovamente parlato del fatto che i mockup erano solo per l'opportunità di parlare di funzionalità e di come dovrebbe funzionare il prodotto. Sfortunatamente, questo non ha impedito al marketing di commentare i caratteri tipografici utilizzati sui mockup, che non avevano alcuna relazione con il design dell'applicazione a quel punto del progetto . Alla fine, l'argomento si è risolto abbastanza velocemente ed è stato compreso, ma il fatto stesso che non lo sia stato subito indica che il tema della UX è del tutto sconosciuto nelle aziende. Vale la pena fare una breve presentazione al cliente proprio all'inizio della fase di progettazione con una discussione su come lavoriamo, cosa presenteremo e fino a che punto abbiamo bisogno del contributo del cliente. E, naturalmente, perché ne vale la pena per lui.

9. Lavorare con gli sviluppatori

Spesso gli sviluppatori hanno un ottimo input quando si tratta di soluzioni e pongono domande molto tecniche e logiche, che molte volte mi hanno dato un buon argomento per pensare a una soluzione. Tuttavia, a volte propongono soluzioni per loro più semplici e non necessariamente buone dal punto di vista dell'utente, quindi qui è necessario bilanciare correttamente ciò che vale la pena eventualmente proporre di cambiare e dove vale la pena fermarli e spiegare le decisioni prese.

10. API, JSON, LDAP, orchestratori e altre parole strane

Questi sono concetti chiave per lo sviluppo di applicazioni che, come UX, dovresti conoscere perché gli sviluppatori e l'intera comunità IT li usano. Impara a conoscerli e sarai in grado di parlare meglio con gli ingegneri. Non sai - chiedi, preferibilmente all'inizio, anche se per me la comprensione di questi concetti è arrivata solo dopo aver esaminato la documentazione di implementazione che gli sviluppatori stavano creando - i diagrammi di comunicazione interna dell'applicazione hanno permesso di capire molto quando si tratta del suo funzionamento.

11. Lavorare in sprint, project daily, sprint planning e retro(spec)

Sono incontri preziosi che danno il pieno controllo su ciò che sta accadendo nel progetto. I Project Manager sono importanti qui, intervenendo quando necessario (ad esempio, quando il cliente cerca di cambiare le disposizioni), così come gli Scrum Master se stiamo lavorando in modo agile (quasi tutti i progetti).

Come puoi vedere, queste sono state molte cose che ho imparato quando sono entrato a far parte dell'IT. Spero che li troverai interessanti e forse questo elenco sarà utile per coloro che stanno considerando la loro carriera UX/UI o anche per le persone che lavorano in questo settore!