Les proves d'usabilitat tenen una reputació injusta de ser cars i lents. Quan la gent escolata "recerca d'usuaris", es picturen un mirall unidireccional, un moderador amb una carpeta, i una línia de temps de dues setmanes. Aquesta versió de proves existeix i té els seus usos — però no és la versió que la majoria d'equips de producte necessiten la major part del temps.
La versió que la majoria dels equips necessiten és més simple: cinc usuaris, un prototip de Figma o un entorn de posada en producció, una trucada de vídeo, i 45 minuts per sessió. Feta bé, això revela la majoria de problemes greus d'usabilitat abans que es desplieguin. Feta consistentment — fins i tot una vegada per sprint — produeix una millora composta en la qualitat del producte que cap quantitat d'analítica post-llançament pot replicar.
Aquí hi ha com executar-la des de zero.
Cinc participants és el nombre correcte 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 decrescents després d'això. Executar tres sessions de cinc usuaris en diferents punts del procés de disseny és més valuós que una sessió amb quinze.
Els criteris de reclutament són més importants que el nombre. Una prova d'usabilitat amb cinc persones que coincideixin estretament amb el vostre usuari objectiu revelarà problemes reals. Una prova amb quinze persones que no coincideixin generarà soroll. Definir dos o tres criteris de cribratge — rol, context d'ús, nivell de comoditat tècnic — i mantenir-s'hi.
La ruta de reclutament més ràpida per a la majoria dels equips és enviar correus electrònics als usuaris existents que han donat permís de contacte. Oferir un incentiu modest — una targeta de regal de 20€ és suficient per a una sessió de 45 minuts. Objectiu programar sessions dins de la mateixa setmana; com més llarga sigui la bretxa entre el reclutament i les proves, més alta és la taxa de no compareixement.
L'error d'escriptura més comú és escriure tasques com a instruccions: "Feu clic a Configuració, després navegueu a Notificacions, i canvieu la vostra preferència a..." Això li diu a l'usuari què fer, el qual significa que estàs provant si poden seguir direccions, no si la interfície és intuïtiva.
Escriure tasques com a escenaris en lloc: "Imagina que has estat rebent massa notificacions i vols rebre només alertes quan algú et menciona directament. Mostra'm el que faríes." Això li dóna a l'usuari un objectiu realista i et permet observar com naveguen realment — incloent on es confonen.
La part més difícil de moderar una prova d'usabilitat és resistir l'impuls d'ajudar. Quan un usuari està confós, cada instint diu que saltar i mostrar-li on fer clic. Però la confusió és les dades. Un usuari que estava lluita t'està dient que alguna cosa està malament amb la interfície — i el moment que intervé, perds el senyal.
Demanar als usuaris que pensin en veu alta durant tota la sessió: "Mentre avançes, simplement diga'm en què estàs mirant i en què estàs pensant." Això produeix un flux continu de dades sobre el seu model mental. Anotar no només errors sinó vacil·lacions — un usuari que fa una pausa de tres segons abans de fer clic al botó correcte ha revelat un problema de disseny, fins i tot si finalment van tenir èxit.
El pas de síntesi és on es crea la majoria del valor — i on la majoria dels equips tallem les cantonades. Les notes crues de cinc sessions no són conclusions. Es converteixen en conclusions quan es fa debrief com a equip, s'agrupen observacions per tema, i s'assignen classificacions de severitat.
Fer el debrief el mateix dia que les sessions, mentre que les observacions són fresques. Agrupar problemes en tres cubetes: crítica (els usuaris no van poder completar la tasca), moderada (els usuaris van completar la tasca però amb dificultats significatives o error), i menor (fricció que no va prevenir la realització). Els problemes crítics han de ser arreglats abans del llançament. Els problemes moderats han de ser prioritzats en el proper sprint. Els problemes menors van al backlog.
Escriure les conclusions en una sola pàgina: els tres problemes crítics més grans, amb proves de com a mínim dos participants cadascun, i un canvi de disseny proposat per a cadascun. Qualsevol cosa que necessiti més espai que això pertany a un document separat.