Les proves d'usabilitat tenen una fama injusta de ser cares i lentes. Quan la gent sent «recerca d'usuaris», s'imagina un mirall unidireccional, un moderador amb una carpeta i un calendari de dues setmanes. Aquesta mena de proves existeix i té els seus usos, però no és la que necessiten la majoria d'equips de producte la major part del temps.
La versió que necessiten la majoria d'equips és més senzilla: cinc usuaris, un prototip de Figma o un entorn de preproducció, una videotrucada i 45 minuts per sessió. Si es fa bé, permet detectar la majoria dels problemes d'usabilitat greus abans de publicar. Si es fa amb constància, fins i tot un cop per sprint, produeix una millora acumulativa en la qualitat del producte que cap volum d'analítica posterior al llançament no pot igualar.
Aquí tens com fer-ho des de zero.
Cinc participants és el nombre adequat per a la majoria de proves d'usabilitat. La recerca de Jakob Nielsen va establir que cinc usuaris descobreixen al voltant del 85 % dels problemes d'usabilitat, amb rendiments decreixents a partir d'aquí. Fer tres sessions de cinc usuaris en diferents moments del procés de disseny és més valuós que fer una sessió amb quinze.
Els criteris de reclutament són més importants que el nombre. Una prova d'usabilitat amb cinc persones que s'ajusten bé al teu usuari objectiu revelarà problemes reals. Una prova amb quinze persones que no s'hi ajusten només generarà soroll. Defineix dos o tres criteris de selecció (rol, context d'ús, nivell de comoditat tècnica) i mantén-los.
La via de reclutament més ràpida per a la majoria d'equips és escriure als usuaris existents que han donat permís per ser contactats. Ofereix un incentiu modest: una targeta regal de 20 £ n'hi ha prou per a una sessió de 45 minuts. Intenta programar les sessions dins la mateixa setmana; com més llarg sigui l'interval entre el reclutament i les proves, més alta és la taxa d'absències.
L'error més habitual en el guió és escriure les tasques com a instruccions: «Fes clic a Configuració, després ves a Notificacions i canvia la teva preferència a...». Això diu a l'usuari què ha de fer, és a dir, estàs comprovant si sap seguir indicacions, no si la interfície és intuïtiva.
Escriu, en canvi, les tasques com a escenaris: «Imagina que últimament reps massa notificacions i vols rebre només avisos quan algú et mencioni directament. Ensenya'm què faries». Això dona a l'usuari un objectiu realista i et permet observar com navega de debò, inclosos els punts on es perd.
El més difícil de moderar una prova d'usabilitat és resistir l'impuls d'ajudar. Quan un usuari està confós, tots els instints et diuen que intervinguis i li mostris on ha de fer clic. Però la confusió són les dades. Un usuari que té dificultats t'està dient que alguna cosa no va bé a la interfície, i en el moment que intervens, perds el senyal.
Demana als usuaris que pensin en veu alta durant tota la sessió: «A mesura que avances, digues-me què estàs mirant i què estàs pensant». Així obtens un flux continu de dades sobre el seu model mental. Anota no només els errors, sinó també les vacil·lacions: un usuari que s'atura tres segons abans de fer clic al botó correcte ha revelat igualment un problema de disseny, encara que al final ho aconsegueixi.
La síntesi és on es crea la major part del valor, i on la majoria d'equips fan curt. Les notes en brut de cinc sessions no són conclusions. Esdevenen conclusions quan feu una posada en comú com a equip, agrupeu les observacions per temes i assigneu valoracions de gravetat.
Fes la posada en comú el mateix dia que les sessions, mentre les observacions són fresques. Agrupa els problemes en tres categories: crítics (els usuaris no han pogut completar la tasca), moderats (els usuaris han completat la tasca, però amb dificultats o errors importants) i lleus (fricció que no ha impedit completar-la). Els problemes crítics s'han d'arreglar abans del llançament. Els moderats s'han de prioritzar a l'sprint següent. Els lleus van al backlog.
Resumeix les conclusions en una sola pàgina: els tres problemes crítics principals, amb evidències d'almenys dos participants cadascun, i una proposta de canvi de disseny per a cadascun. Tot el que necessiti més espai que això pertany a un document a part.