Avaluació Heurística: Archive of Our Own
Públic Hola a totes! La interfície que he triat per l’avaluació heurística és Archive of Our Own, o AO3, un repositori de fanfiction de codi obert i sense ànim de lucre. La versió beta es va llançar l’any 2009, i tot just fa uns dies, el 2 d’abril de 2026, AO3 va sortir d’aquesta fase de desenvolupament i ara podem gaudir-ne de la versió definitiva. La plataforma va ser ideada per Oranization of Transformative Works (OTW), una organització sense ànim de lucre que volia crear un espai on els fans de sèries, llibres, grups de música i molt més poguessin deixar anar la imaginació i crear obres sense censura.
He escollit aquesta interfície perquè la conec bé i hi he passat moltes estones entretingudes entre fanfictions dels meus grups de música preferits de l’adolescència i l’edat adulta. A més a més, la iniciativa de OTW em sembla molt pionera i soc gran defensora del programari de codi obert.

Logo d’AO3. Font: The Cougar.
Ja entrant en matèria, en aquest post parlaré de la metodologia de l’avaluació heurística, bons i mals exemples dels 10 principis heurístics de Nielsen i un llistat de sis troballes en ordre de menys a més gravetat.
Quant a la metodologia, he dut a terme una avaluació heurística d’usabilitat mitjançant una inspecció de la interfície del lloc web d’AO3. Com a marc de referència, he aplicat els 10 principis de Nielsen i n’he analitzat el compliment per identificar barreres en la UX. Per assegurar-me que la inspecció reflecteix barreres reals, he navegat per la pàgina com si en fos una usuària corrent que realitza les accions habituals (cercar continguts, filtrar-los, llegir…), però també he posat a prova la funcionalitat de les interaccions.
Aplicació dels 10 principis de Nielsen
(Nota: A partir d’aquí, totes les imatges són captures de pantalla pròpies.)
1 – Visibilitat de l’estat del sistema
✅Bon exemple: Quadres de text emergents que indiquen que una acció s’ha dut a terme amb èxit.
![]()
❕Justificació: Informar de les accions finalitzades és una bona pràctica. Els usuaris se senten més tranquils quan el sistema els dona una retroacció que indica que una acció ha funcionat o han fet bé un procés.
❌Mal exemple: En aplicar molts filtres de cerca, o filtres no relacionats, si un d’aquests filtres fa que la cerca doni zero resultats, no hi ha cap indicador dinàmic que ho avisi.

❕Justificació: L’usuari no coneix l’estat de la cerca fins que no prem el botó i es troba que no hi ha resultats. Això fa que hagi de tornar enrere manualment per esbrinar quin filtre ha trencat la llista a base de prova i error.
2 – Relació entre el sistema i el món real
✅Bon exemple: Ús de termes com “kudos”, molt comú en la parla anglesa per expressar l’enhorabona. En el context d’AO3, es fa servir com un “m’agrada”.
![]()
❕Justificació: Aquest tipus de llenguatge és adequat perquè ressona amb els usuaris que fan servir AO3.
❌Mal exemple: Ambigüitat del sistema de col·leccions (collections) i publicacions desades (bookmarks)

❕Justificació: Sense més context, totes dues paraules, sobretot en anglès, poden significar la mateixa cosa. Tanmateix, a AO3, les bookmarks són les obres que l’usuari desa (per llegir-les després, per exemple) i les collections són llistes públiques on tots els usuaris poden afegir obres i el propietari de la llista pot aprovar-les o no. Per tant, és un error ajuntar totes dues opcions en un mateix formulari.
3 – Control i llibertat de l’usuari
✅Bon exemple: El botó “Orphan Work” (permet deixar l’obra però esborrar el teu nom).

❕Justificació: És una opció que no es veu en altres plataformes. Serveix per a desvincular-se de l’autoria d’una obra però sense esborrar-la.
❌Mal exemple: Tot i que es poden fer canvis en bloc quant a visibilitat, etiquetes, classificació i d’altres característiques, els canvis no es poden revertir en bloc si l’usuari s’ha equivocat seleccionant les obres o les opcions.

❕Justificació: L’usuari pot perdre el control sobre el seu catàleg d’obres perquè el sistema no ofereix una sortida d’emergència. Aleshores, per revertir algun canvi ha d’anar obra per obra.
4 – Cohesió i estàndards
✅Bon exemple: Els botons de les diferents opcions es troben sempre a la dreta.
![]()
![]()
❕Justificació: El layout de navegació és constant i manté la imatge de la plataforma.
❌Mal exemple: No hi ha una cohesió en els menús desplegables, ja que uns s’obren en passar el ratolí per sobre (primer gif) i uns altres obliguen a fer clic a sobre per veure totes les opcions (segon gif).


❕Justificació: La incoherència funcional suposa un problema perquè l’usuari esperaria interactuar de la mateixa manera amb tots els menús, però no és el cas.
5 – Prevenció d’errors
✅Bon exemple: AO3 obliga a triar una categoria d’advertència (warning) abans de publicar una obra.

❕Justificació: Les advertències de contingut són especialment útils, especialment perquè no tots els usuaris estan disposats a llegir segons quin tipus de temàtiques. Obligar a seleccionar-ne una impedeix ferir la sensibilitat dels usuaris.
❌Mal exemple: Manca de confirmació o bloqueig en la duplicació de capítols.


❕Justificació: AO3 permet que un usuari pugi exactament el mateix contingut en dos capítols seguits i no llança cap avís. Com a conseqüència, els subscriptors reben l’alerta per correu, i quan l’usuari se n’adona, el mal ja està fet.
6 – Reconèixer abans que recordar
✅Bon exemple: Menú desplegable d’autocompletar en les etiquetes (tags).

❕Justificació: Quan el sistema ofereix opcions visuals que l’usuari únicament ha de reconèixer i seleccionar, es redueix la càrrega cognitiva i s’eviten errors de memòria.
❌Mal exemple: Gestió de les subscripcions a diferents obres.

❕Justificació: El sistema només mostra la llista d’obres amb el nom de l’autor al costat, però no aporta cap més informació (com ara algun resum, fandom o etiquetes). Això obliga l’usuari o bé a fer memòria de quina obra és quina, o directament entrar a cadascuna per recordar-se’n.
7 – Flexibilitat i eficiència d’ús
✅Bon exemple: Diferents opcions de visualització de la web (predeterminada, baixa visió, mode fosc i blau i blanc).


❕Justificació: Ajuda els usuaris a fer el lloc web una mica més seu i a fer-lo servir de la manera més còmoda possible. Un detall com aquest denota que les persones que hi ha darrere d’AO3 prioritzen les necessitats dels usuaris i no deixen ningú fora (com ara els usuaris amb problemes de visió, que necessitarien un disseny més senzill i botons més grans).
❌Mal exemple: La manca d’adaptació dels elements d’interacció, especialment les etiquetes (tags), als dispositius mòbils.

❕Justificació: Malgrat que l’interfície és adaptativa, els elements d’interacció són massa petits per al dit humà, que és més gruixut i imprecís que el punter del ratolí. Sovint, això podria arribar a fer que l’usuari a fer zoom per no equivocar-se en tocar algun element.
8 – Disseny estètic i minimalista
✅Bon exemple: Absència total de publicitat o elements distractors en tota la interfície.


❕Justificació: En ometre bàners i anuncis, AO3 prioritza el contingut principal, és a dir, les obres. D’aquesta manera, no hi ha res que causi soroll visual als usuaris.
❌Mal exemple: En fer una cerca i obtenir-ne els resultats, la quantitat d’informació que apareix és aclaparadora.

❕Justificació: Encara que no hi hagi anuncis, el disseny no filtra la informació secundària i mostra desenes de tags. Això fa que es trenqui el principi de minimalisme funcional i les dades clau de les obres (títol, resum) queden enterrades.
9 – Ajudar els usuaris a reconèixer, diagnosticar i recuperar-se dels errors
✅Bon exemple: Missatges clars quan falta un camp obligatori en un formulari.
![]()
❕Justificació: Un bon missatge d’error indica exactament on es troba el problema, com solucionar-lo i està escrit en un llenguatge planer (per exemple: la contrasenya és massa curta) perquè l’usuari no hagi de desxifrar explicacions tècniques.
❌Mal exemple: Retroacció assegurant que s’ha esborrat un comentari i missatge d’error a sota.

❕Justificació: A causa dels missatges contradictoris, l’usuari pot sentir-se molt confós i no saber si el seu comentari s’ha esborrat o no. A més, la pàgina no redirigeix de nou a l’obra on estava abans.
10 – Ajuda i documentació

✅Bon exemple: Secció de FAQ i suport tècnic gestionat per voluntaris.
❕Justificació: En plataformes amb regles complexes (com ara drets d’autor), la documentació és essencial. Una secció de FAQ correctament estructurada facilita la resolució de dubtes específics de manera autònoma.
❌Mal exemple: Poca ajuda contextual en alguns camps del formulari de publicació.


❕Justificació: En fer clic al signe d’interrogació, s’obre una finestra de text emergent que explica com s’han d’introduir els noms de les col·leccions i el seu funcionament. Malgrat això, el llenguatge és bastant tècnic, no s’explica enlloc què és una col·lecció i no s’esmenta res dels Challenges, que sí que apareixen a la descripció del camp del formulari. Si un usuari nou té dubtes, està obligat a sortir del formulari i anar a la pàgina de FAQ.
Llista de troballes i possibles solucions
La gravetat es qualificarà de la següent manera:
1 – problema de baixa fricció
2 – problema d’usabilitat lleu
3 – problema d’usabilitat greu
4 – problema d’usabilitat gravíssim
1 – Poca ajuda contextual en alguns camps del formulari de publicació. (10)
⭕Gravetat: 1
✨Solució: Actualitzar el text d’ajuda ja existent, tot fent-lo menys tècnic i explicant en termes senzills el significat dels camps que poden suscitar confusió en els usuaris.
2 – Manca de confirmació o bloqueig en la duplicació de capítols. (5)
⭕Gravetat: 2
✨Solució: Implementar un sistema de detecció de text que compari les coincidències de contingut entre capítols. Si el sistema detecta que el text és idèntic, hauria de mostrar un avís de confirmació abans de permetre publicar el capítol.
3 – Manca d’indicador dinàmic de resultats de cerca (1)
⭕Gravetat: 2
✨Solució: Afegir un comptador dinàmic que s’actualitzi en temps real (per exemple: “Mostrant 1.240 obres”) a mesura que l’usuari marca o desmarca filtres, abans de prémer el botó de cerca final.
4 – Manca de cohesió en els menús desplegables (4)
⭕Gravetat: 3
✨Solució: Estandarditzar tots els menús desplegables de la capçalera perquè funcionin de la mateixa manera. Per a dispositius tàctils, com ara mòbils i tauletes, haurien de funcionar mitjançant clic per garantir l’accessibilitat.
5 – Elements d’interacció petits a la interfície per a mòbil (7)
⭕Gravetat: 3
✨Solució: Augmentar l’àrea de clic de les etiquetes i botons en la versió mòbil i separar-los més entre ells per complir amb l’estàndard de disseny tàctil (mínim 44 píxels).
6 – Saturació visual en els resultats de cerca (8)
⭕Gravetat: 4
✨Solució: Limitar les etiquetes visibles de manera predeterminada (i mostrar-ne només les 10 primeres, per exemple) i implementar un botó de “+ veure més” per expandir la resta. Això neteja la interfície sense eliminar la informació.
Fins aquí la meva avaluació! Espero que us hagin resultat interessants els exemples. Gràcies per llegir. 🙂
Aquest és un espai de treball personal d'un/a estudiant de la Universitat Oberta de Catalunya. Qualsevol contingut publicat en aquest espai és responsabilitat del seu autor/a.