En aquest repte s’ha realitzat un Tree Test fent servir l’eina online de Optimal Work [1] amb les dades obtingudes al final en el Card Sorting de la botiga online de fotografia. El Tree Test es un mètode amb usuaris que ens permet avaluar si la navegació del nostre servei es la millor opció i en cas que no, estudiar quin es el camí que els usuaris haguessin triat per re-avaluar l’arquitectura.
En l’elaboració del Tree Test, a més a més de comptar amb els resultats del Card Sorting per estructurar els productes, s’han plantejat els següents objectius per tal de completar el disseny de navegació:
Buscar un element que hagi tingut molt de concens en el Card Sorting.
Buscar un element que hagi tingut poc concens en el Card Sorting.
Indicar on es pot descobrir el contacte de la botiga física més propera.
Indicar on es pot descobrir l’estat de la comanda en curs.
Indicar on es pot descobrir les polítiques de devolució d’una compra passats 15 díes.
A més a més, ja que el Tree Test és anònim, s’ha plantejat algunes preguntes per poder identificar quin perfil té les persones que realitzen l’activitat. Aquestes són saber l’edat, el nivell de familiaritat amb compres online i el nivell de familiaritat amb elements fotogràfics.
Donat que el Card Sorting es va realitzar en castellà i per mantenir la concordança, el Tree Test s’ha presentat en castellà i per tant els resultats obtinguts estaràn en castellà. Tot i així, l’informe es mantindrà en català.
Proposta de menú de navegació inicial
Un cop analitzat l’informe de resultats del Card Sorting i tenint en compte les tasques a completar, s’ha dissenyat el següent menú de navegació.
Descripció de les tasques sol·licitades
Per tal d’avaluar els objectius principals, s’han dissenyat 5 tasques indicant un context per a que els usuaris poguessin abordar el repte.
1. Buscar un element que hagi tingut molt de concens en el Card Sorting.
Descripció. «Para tu cumpleaños te han regalado una cámara réflex para que te la puedas llevar de vacaciones pero, para viajar más cómodo, decides proteger la cámara. Busca una funda para tu cámara.«
Ruta d’èxit.
Productos > Accesorios y complementos > Fundas cámaras
2. Buscar un element que hagi tingut poc concens en el Card Sorting.
Descripció. «Tu mejor amiga le encanta la fotografía y constantemente intenta buscar formas de innovar con distintas tecnologías. Como se acercan las vacaciones y en el trabajo te han dado un plus, decides hacerle un regalo sorpresa. Busca un dron para regalarle a tu amiga.«
Ruta d’èxit.
Productos > Cámaras y videocámaras > Drones
3. Indicar on es pot descobrir el contacte de la botiga física més propera.
Descripció. «Hace unos días tramitaste el pedido de tu funda para cámara y el dron para tu amiga, pero te gustaría consultar en qué estado se encuentra el pedido. Indica dónde consultarías el estado del pedido.«
Ruta d’èxit.
Cuenta de usuario > Pedidos > Pedidos pendientes de entrega
4. Indicar on es pot descobrir l’estat de la comanda en curs.
Descripció. «Mientras esperas que llegue el pedido, decides buscar si la tienda de fotografía tiene tienda física y como contactar en caso que necesites asistencia personal. Indica dónde consultarías dónde se encuentra la tienda y cómo contactar.«
Ruta d’èxit.
Contacto > Sobre nosotros > ¿Dónde nos puedes encontrar y contactar?
5. Indicar on es pot descobrir les polítiques de devolució d’una compra passats 15 díes.
Descripció. «Finalmente te ha llegado el pedido de la funda de cámara y te das cuenta que no acaba de encajar bien con tu cámara. Sin embargo, ya han pasado 15 días desde que tu pedido llegó y no sabes si puedes devolverlo. Indica dónde consultarías las condiciones de devolución de tu pedido.«
Ruta d’èxit.
Cuenta de usuario > Pedidos > Pedidos entregados
Servicios > Políticas de compras y devoluciones
Nota. Per a resoldre aquesta tasca s’han proposat dues rutes perquè des del punt de vista del disseny, ha semblat coherent que es pugui consultar les polítiques de devolució tant desde les polítiques i la normativa de la botiga online, com des de la propia comanda entregada, ja que si es pogués fer la devolució, seria des d’allà la forma més lògica des del punt de vista del dissenyador.
La prova s’ha realitzat a un total de 7 persones d’edats compreses entre 18 i 28 anys. D’aquests usuaris, han respost el questionari principal de la següent manera:
A continuació es mostra el resum de les tases d’èxit per cadascuna de les tasques:
Busca una funda para tu cámara. 100% d’èxit
Busca un dron para regalarle a tu amiga. 100% d’èxit (14% indirecte)
Indica dónde consultarías el estado del pedido. 100% d’èxit
Indica dónde consultarías dónde se encuentra la tienda y cómo contactar. 71% d’èxit
Indica dónde consultarías las condiciones de devolución de tu pedido. 71% d’èxit (14% indirecte)
Les 3 primeres tasques han tingut un èxit del 100% i per tant podem deduir que la navegació proposada per completar aquests objectius és la correcte per la mostra presa. Però en canvi, la tasca 4 i 5 han tingut 2 usuaris a cada tasca que han arribat a la secció errònia. Comentar que els usuaris que han triat un camí alternatiu a l’esperat, l’han triat només en una tasca, es a dir que tots els usuaris han acabat correctament com a mínim 4 de 5 tasques.
Si analitzem els camins alternatius que han triat veiem que en la tasca 4 els usuaris han acabat arribant a la secció de Soport técnico per trobar la botiga més propera.
En canvi, si mirem els camins alternatius en la tasca 5, veiem que un usuari ha acabat arribant a Soporte técnico mentre que l’altre usuari que ha escollit la ruta alternativa, ha arribat a Políticas y condiciones de envíos.
Conclusions
Després de veure els resultats obtinguts podem concloure que la navegació en termes generals ha estat una bona elecció tal i com s’ha plantejaat, malgrat que en dues de les cinc tasques no tothom ho hagi resolt igual. Però, la desventatge d’haver-ho fet de forma online és que els usuaris que no han arribat al camí esperat no se’ls ha pogut preguntar perquè han triat aquella opció i aquest es el punt de desventatge per a plantejar una millora en aquests aspectes, potser només es tracta de proposar un nou etiquetatge però no podem saber perquè han triat aquesta opció o uba altra.
En primer lloc, podem observar en els resultats que els usuaris han triat l’opció de Soporte técnico per a consultar informació. Això fa pensar, els usuaris fan servir aquesta opció com a ruta comodí per resoldre les tasques que amb la navegació proposada no han trobat el camí lògic potser. Per altra banda, un dels usuaris ha triat l’opció de Políticas y condiciones de envío en lloc de l’opció de Políticas de compras y decoluciones per a la tasca 4 que consistia en consultar les condicions de devolució. Aquest punt fa pensar també, pot ser que l’usuari no hagi tingut clar què consultar si les «condicions» o bé la «devolució»? Per què ha triat aquesta i no l’altre tenint en compte que les opcions estaven una al costat de l’altre?
S’ha vist que amb aquesta tècnica s’ha pogut avaluar una proposta de disseny de navegació que ha estat prou ben plantejada com per a que la tasa d’èxit de navegació sigui del 89%. Pero el Tree test s’hauria d’haver plantejat una mica diferent, fins i tot que s’hagués fet de forma presencial o bé afegir alguna secció més per a que l’usuari pugui aportar les seves sensacions i no quedar-nos amb el resultat quantitatiu només, sobretot perquè la mostra no ha estat suficientment gran i en aquests casos és més interessant tenir també un feedback qualitatiu que aporti valor per millorar els resultats obtinguts. Malgrat que hagin estat positius, només pel fet que no totes les tasques han estat del 100%, vol dir que es pot millorar i com a dissenyadors, tenim la responsabilitat de seguir iterant per millorar la proposta de disseny de navegadors, sempre que sigui posible en els temps establerts.
Tan bon punt el procés iteratiu de sketching ha quedat prou acurat, s’ha procedit a seguir en el procés de prototipatge de baix nivell, sense aportar cap disseny gràfic definitiu. Cal aclarir que, en aquest nivell de prototipatge no és necessari incloure cap imatge ni colors ni res però, per tal de facilitar l’enteniment, s’han fet servir les imatges auxiliars de Mutek per omplir allà on fes falta una imatge i s’han posat alguns colors per poder identificar més fàcilment què es pot pitjar i què no.
Donat que es plantegen 2 tipus d’usuaris, s’han dissenyat 2 fluxos de prototipatge per tal de permetre abordar els dos tipus d’interacció. Aquests prototips s’han dissenyat fent servir Figma. Per accedir a aquests enllaços de prototipatge, prémer les imatges per cadascun dels prototips.
Proposta de valor
A continuació es mostra la proposta de valors que aporta l’applicació acord a les necessitats identificades en la documentació proporcionada en el briefing i les fitxes persona de l’Anne i de’n David.
Un dels pasos a l’hora de dissenyar un sistema interactiu consisteix en observar i analitzar altres productes que compleixen un servei similar al que es vol dissenyar per tal de veure aquells punts de fortalesa així com de feblesa i poder tenir-los presents en el propi disseny. Donat que Mutek va sol·licitar una aplicació que permeti la compra d’entrades així com la retransmissió en streaming dels espectacles, per a aquest anàlisis s’han escollit les següents dues webs: LiveNation i Banister Live.
Per a analitzar els llocs web indicats, es realitzarà una avaluació Heurística seguint els 10 principis de Nielsen. Per tal de tenir presents aquests principis de Nielsen, s’exposa una breu explicació extreta del blog de Interactius [1].
1. Visibilitat de l’estat del sistema.
«El sistema ha de mantenir a l’usuari informat sobre el que passa a través d’una retroalimentació apropiada en un temps raonable.»
2. Adequació entre el sistema i el món real.
«El sistema ha de parlar en el llenguatge de l’usuari, amb paraules, frases i conceptes familiars per ell. Utilitzar convencions del món real, fent que la informació apareixi en un ordre natural i lògic.»
3. Llibertat i control per part de la persona usuaria.
«A vegades els usuaris escullen funcinalitats per error i necessiten una ‘porta d’emergència’ per sortir d’un estat indesitjat. Oferir suport per desfer i refer accions.»
4. Consistència i estàndars.
«Els usuaris no haurien de preguntar-se si diverses paraules, situacions o acción signifiquen les mateixes coses. Que es segueixin les normes i convencions de la plataforma sobre la que està implementat el sistema.»
5. Prevenció d’errors.
«Abans que dissenyar bons missatges d’errors, és millor evitar que el problema es dugui a terme.»
6. Reconeixement abans que record.
«Minimitzar la càrrega de memòria de l’usuari fent que els objectes, les accions i les opción estiguin visibles. L’usuari no té perquè recordar la informació d’una part del diàleg a una altra»
7. Flexibilitat i eficiència d’ús.
«Els acceleradors, no vistos per l’usuari principiant, milloren la interacció per l’usuari expert de tal manera que el sistema pot servir per usuaris inexperts i experimentats. És important que el sistema permeti personalitzar accions freqüents.»
8. Disseny estètic i minimalista.
«Els diàlegs no haurien de tenir informació irrellevant o que es necessiti rarament. Cada unitat extra d’informació en un diàleg competeix amb la informació important, disminuint la visibilitat relativa.«
9. Ajuda a les persones usuaries a reconèixer i diagnosticar els errors i a recuperar-se.
«Els missatges d’error han d’estar expressats en un llenguatge pla, sense codis, indicant amb precisió el problema i suggerir una solució.«
10. Ajuda i documentació
«Encara que es millor que es pugui fer servir el sistema sense documentació, és necessarti proporcionar a l’usuari ajuda i documentació. Aquest ha de ser fàcil de buscar, centrat en les tasques de l’usuari, amb informació de les etapes a realitzar encara que no sigui molt extensa.»
A continuació es mostrarà el diagrama de flux d’una taca en cadascuna de les webs indicades i es farà una avaluació Heurística d’aquests.
LiveNation
Tasca – Comprar dues entrades a un concert
Escenari: Després de 2 anys de restriccions sanitàries degut a la pandèmia de la Covid-19, Destripando la Historia torna als escenaris de forma presencial arreu de la península. Tu i el teu millor amics, fans incondicionals dels artistes, decidiu assistir al primer concert que facin aprop de la teva ciutat. El concert és promocionat per LiveNation, compra les entrades des d’allà.
Diagrama de flux
En analitzar el diagrama de flux per tal de comprar entrades a través de LiveNation, un dels punts que ha cridat més l’atenció és que ells només promocionen els concerts però tot el que té a veure amb la gestió de les entrades està en mans de TicketMaster, un servei de tercers. Un altre aspecte curiós és que les funcions de promoció són bastant limitades i de seguida surt a altres pàgines webs des don es gestionen les entrades, el cual dona una sensació com si LiveNation, a ulls de l’usuari que navega, es dedica a agrupa els esdeveniment però no té cap mena de control sobre aquests.
Avaluació Heurística
A continuació s’exposa l’avaluació Heurística de LiveNation:
1. Visibilitat de l’estat del sistema.
LiveNation aplica una bona pràctica. En tot moment l’usuari està informat de quin punt està en la compra d’entrada i quina mena de decisions i dades ha de prendre.
2. Adequació entre el sistema i el món real.
LiveNation aplica una bona pràctica, però millorable. En la majoria dels casos fa servir un llenguatge natural per l’usuari però a vegades hi ha algunes expressions com el botó de «Entradas» per seguir amb la compra que poden despistar una mica i si no fos perquè és l’única opció, potser no seria tant lògic prémer aquest botó.
3. Llibertat i control per part de la persona usuaria.
LiveNation aplica una mala pràctica. Degut a que LiveNation fa servir un servei de tercers per a gestionar la compra d’entrades, en el moment que s’accedeix a TicketMaster perd el control de permetre tornar enrrere i obliga a l’usuari a retrocedir a través del navegador i no pas a través de la web.
4. Consistència i estàndars.
LiveNation aplica una bona pràctica. Segueix els estàndars habituals tant de distribució d’informació com en qüestions d’iconografia.
5. Prevenció d’errors.
LiveNation aplica una mala pràctica. En el moment que s’accedeix a TicketMaster per gestionar la compra d’entrades (i la selecció d’aquestes), Aquest no té en compte si encara hi ha entrades o no per assistir i fins que no selecciones les entrades i continues els pasos, no t’indica amb missatge d’error que no hi ha entrades. Per altra banda, LiveNation si dóna accés a comprar els entrades, hauria de poder visualitzar la disponibilitat d’entrades i no permetre que l’usuari intenti comprar sense poder-ne realment.
6. Reconeixement abans que record.
LiveNation aplica una bona pràctica. En el moment de fer la compra a través de TicketMaster, es conserva la informació de la data, hora i lloc del concert selecionat i això permet que l’usuari no hagi de recordar la seva selecció, així com durant el procés de pagament.
7. Flexibilitat i eficiència d’ús.
LiveNation aplica una bona pràctica, però millorable. Des de LiveNation, permet aplicar filtres de dates, llocs i gèneres per tal de afinar la cerca de concerts i si l’usuari que sap a quin concert vol anar, pot fer ús d’aquests. Tot i així, és l’única opció que permet accelerar el procés ja que és bastant lineal. Per altra banda, si ja s’ha fet mai cap compra a través de TicketMarket, aquest pot guardar la informació per a futures compres, i per tant accelerar-ho.
8. Disseny estètic i minimalista.
LiveNation aplica una bona pràctica. Tota la informació proporcionada és clara i directe, permet que l’usuari no divagui en informació irrellevant
9. Ajuda a les persones usuaries a reconèixer i diagnosticar els errors i a recuperar-se.
LiveNation aplica una bona pràctica, però millorable. Des de LiveNation no hi ha errors posibles, ja que en esspencia és un by-pass per a la compra d’entrades. Però des de TicketMaster sí que hi ha una bona pràctica d’errors doncs aquests són clars si falta informació si algun procés ha fallat i què ha de fer l’usuari per a poder continuar.
10. Ajuda i documentació
LiveNation aplica una bona pràctica, però millorable. La majoria d’accions contenen un Tooltip que indica què vol dir o què fa, però també hi ha informació de l’artista que queda una mica amagat al final de la fitxa de l’artista. Si bé no és rellevant per les tasques a realitzar, si justament es vol accedir a la informació de l’artista, el més coherent és que aquesta informació de descripció aparegui al principi, encara que sigui com a introducció per als següents continguts.
Banister
Tasca – Assistir a concert en streaming
Escenari: Durant la pandemia, el duo musical de Destripando la Historia s’ha pogut reunir en «petit comité» per transmetre en viu un concert familiar, comentant algunes canços i parlant amb els seguidors responent preguntes. Tu, emocionat, vas comprar les entrades i avui has rebut la notificació de que tot està apunt per començar el concert. Assisteix al concert en streaming a través de Banister.
Diagrama de Flux
Si una cosa destaca Banister és que en concepte de transmissió en streaming té una forma de gestionar-se bastant lineal i similar a la plantejada per Mutek, amb la diferència que aquest diagrama de sequencies correspondria a la transmissió en streaming mentre que la proposada en el projecte és assistir al concert per ARVR i requereix alguns passos més per a gestionar-ho. Arribats en aquest punt, la part més interessant és veure a nivell tècnic com es realitza el setup que connecta amb Banister alhora de transmetre en viu i sobretot, com interactuen amb els oients i quin grau d’interactivitat tenen els artistes directament amb Banister durant el concert. A més a més, també considero interessant veure com es gestionen els errors tècnics que poden succeir en viu per tal de tenir-los presents alhora de dissenyar la interacció per Mutek.
Avaluació Heurística
A continuació s’exposa l’avaluació Heurística de Banister:
1. Visibilitat de l’estat del sistema.
Banister aplica una bona pràctica. Per la naturalesa del concepte de streaming, i la senzillesa a nivell d’espectador, és fàcil saber en tot moment on es troba l’usuari si fora del concert, esperant per entrar o dins del concert.
2. Adequació entre el sistema i el món real.
Banister aplica una bona pràctica, però millorable. Tot i que el concert en streaming en concret no disposa de molts elements interactius a part del xat (que sí aplica bona pràctica), per buscar detalls, es podria parlar de la gestió del perfil de l’usuari i l’accés a les entrades, amb algun text més intuitiu o algun icona que recordi a «El meu perfil»
3. Llibertat i control per part de la persona usuaria.
Banister aplica una mala pràctica. Realment no hi ha cap porta d’emergència que permeti a l’usuari refer les seves accions, l’única porta d’emergència que hi ha és pitjar l’icona de Banister per tornar al principi de tot.
4. Consistència i estàndars.
Banister aplica una bona pràctica, però millorable. Com s’ha comentat abans, durant la tranmissió en streaming no hi ha molts elements interactius, però els pocs que hi ha són adequats. Podria ser millorable si hi hagués més possibilitats. A més a més, també seria millorable un aspecte bastant repetitiu d’error i es que no tots els blocs «clickables» segons el cursor que es mostra, es poden pitjar i això fa que perdi una mica la consistència de que no fa res aquell suposat enllaç.
5. Prevenció d’errors.
Banister aplica una mala pràctica. La possibilitat de que l’usuari es pugui equivocar són molt reduides però on si poden haver errors és durant la transmissió d’errors. Banister ofereix i assegura una bona disponibilitat de servidors i accessos però en canvi hi ha hagut ocasions on, malgrat saber exactament quantes persones assisteixen en streaming, no han sabut oferir el servei al 100% i això indica que no hi ha una bona prevenció d’errors que permeti oferir el servei ininterrumpudament.
6. Reconeixement abans que record.
Banister aplica una mala pràctica. Com s’ha comentat abans, no hi ha motles pantalles d’interacció per poder accedir al concert, però sí que es cert que, si en el correu de recordatori no indiqués quins passos seguir per entrar al concert, l’usuari sol hauria de provar ja que no hi ha cap estructura que permeti reconèixer com accedir al concert.
7. Flexibilitat i eficiència d’ús.
Banister aplica una bona pràctica. Per la naturalesa del concepte de streaming, i la senzillesa a nivell d’espectador, no hi ha necessitat de trobar acceleradors a la tasca per a experts. Els accesos directes que un usuari expert pugui necessitar estan tant accessibles com per l’usuari principiant.
8. Disseny estètic i minimalista.
Banister aplica una bona pràctica. Tota la informació que es mostra en pantalla és senzilla i autoexplicativa de manera que no hi ha elements innecessaris que competeixin per l’atenció de l’usuari.
9. Ajuda a les persones usuaries a reconèixer i diagnosticar els errors i a recuperar-se.
Banister aplica una mala pràctica. Un exemple molt clar és quan s’intenta editar el perfil, per canviar la contrasenya per exemple. En intentar editar, apareix un missatge d’error que per un usuari estàndard no li aporta cap informació i només el botó de «Tornar» li permet recuperar-se, però el missatge és clar només per a desenvolupadors. Aquests tipus d’errors haurien d’estar millor descrits i en cas que sigui necessari una traça per a desenvolupadors, aquest hauria de mostrar-se com a extra en pantalla i que quedi ocult fins a pitjar «més detall» o fins i tot troba una altra manera d’accedir-hi.
10. Ajuda i documentació.
Banister aplica una bona pràctica, però millorable. La tasca d’accedir al concert no conté molts passos però en canvi, la informació que fos necessaria per poder accedir al concert, només es troba en el correu que rep per accedir-hi. Això implica que s’ha de tenir a mà el correu per saber on trobar les entrades. Està documentat? sí, però no és tant accessible com hauria de ser.
Bibliografia i Webgrafia
[1] Modroño, T. (2022, January 5). Evaluación Heurística (PARTE I). Interactius. https://interactius.com/evaluacion-heuristica-parte-i/
Per a realitzar l’arbre de continguts partint dels requisits trobats en l’anterior pràctica, s’ha elaborat un inventari de continguts, a continuació s’ha dissenyat un Card sorting obert per dur a terme de manera online a joves d’edat compresa entre 20 i 30 anys. El fet que el Card sorting s’hagi optat per a que sigui del tipus obert ha permès tenir una visió més àmplia de la percepció que tenen els usuaris a l’hora de categoritzar de forma natural els continguts, però també ha dificultat la tasca, ja que en alguns casos els resultats han estat una mica ambiguos.
Card sorting
En primer lloc, un cop finalitzat el card sorting, s’han analitzat les categories i observat com els usuaris han categoritzat les diferents targetes. A continuació podeu veure la taula obtinguda després d’estandaritzar les categories obtingudes:
Les cartes s’han agrupat en les següents categories:
Accés a l’aplicació.
Blog i events — on dins podem trobar dues subcategories de Events i Blog.
Perfil.
Altres/Secció d’artista.
Configuracions — on dins podem trobar dues subcategories de Configuració i Tests tècnics.
Arbre de continguts
Degut a l’ambiguitat d’alguns resultats, ha estat necessari crear unes relacions directes entre diferents categories com per exemple les configuracions i l’accés a l’aplicació. S’ha establert que en registrar-se per primer cop es permeti accedir directament a definir les diferents configuracions, però si més endevant es vol modificar, l’aplicació ha de poder permetre-ho i per aquest mateix motiu, també ha de poder accedir-se des de dins l’aplicació, com per exemple des del perfil. Un altre cas on s’ha hagut de prendre una decisió ha estat en les entrades comprades, alguns han suggerit que hauria de ser a events però altres també que hauria d’estar al perfil, però pels requisits establerts inicialment i la lògica contextual s’ha categoritzat com a part del perfil.
Cal comentar també que la categoria de blog i events, per la naturalesa de l’aplicació, és el contingut principal i per tant es pot accedir des de tot arreu així com que no depen directament de cap altre categoria. Per aquest motiu no té cap fletxa de relació. Afegir que la categoria de Secció d’artista queda sobrejada amb un altre color degut a que només els artistes tenen accés a aquests continguts directament.
A continuació podeu veure l’arbre de continguts amb les relacions directes.
En els darrers anys cada cop més s’estan esforçant en digitalitzar els serveis de manera que des de qualsevol lloc puguis realitzar les teves gestions, des de realitzar compres online d’alimentació com realitzar la delcaració de la renta. Aquesta transició permeten que els procesos es realitzin de forma més àgil i òptima en el temps. I el servei de salut pública no es queda al marge d’aquesta transició i menys encara quan el passat 2020 es va viure el confinament sanitari degut a la pandèmia de la Covid-19.
Un dels aspectes més importants de digitalitzar un servei com les gestions sanitàries personals és que totes les persones, grans o joves, amb o sense un ampli coneixement tecnològic, han de ser capaces de realitzar les gestions més bàsiques amb la mínima dificultat possible. Per aquest motiu, fer una evaluació heurística ens permetrà veure, sense usuaris, si l’aplicació mòbil de La Meva /Salut compleix els 10 principis de Nielsen i identificar diversos punts de millora.
Figura 1. Icona de l’aplicació mòbil
Metodologia
La idea principal de digitalitzar la gestió sanitaria és permetre a la ciutadania de Catalunya accedir a la seva informaicó de salut i relacionar-se de manera no presencial amb el Sistema de Salut de Catalunya. Per aquest motiu, s’ha estimat realitzar l’evaluació sobre l’aplicació mòbil, malgrat que aquest servei també està per la Web. A més a més, fer l’anàlisis sobre l’aplicació mòbil -en una pantalla més petita que la de l’ordinador- ens permetrà veure si s’ha tingut en compte alguns aspectes com l’accessibilitat visual, sobretot per les persones grans que poden tenir la visibilitat reduïda.
Prerequisits per a l’anàlisis
Degut a que La Meva /Salut és una aplicació per a accedir a la informació personal del Sistema de Salut de Catalunya, hi ha certes condicions que l’usuari ha de complir i que cal tenir en compte per a poder fer aquesta evaluació heurística així com per a preparar una evaluació amb usuaris.
L’usuari ha de ser resident de Catalunya per poder accedir al Sistema de Salut de Catalunya. [1]
Estar donat d’alta a La Meva Salut. [2]
Un cop l’accés a l’aplicació està garantitzat en quant a permisos, ja es pot realitzar l’evaluació.
Els 10 principis heurístics de Nielsen
Els 10 principis heurístics de Nielsen són postulats enfocats a l’evaluació d’interficies digitales. A continuació es mostrarà l’evaluació dels diferents principis, indicant si ha estat una bona o mala pràctica.
1. Visibilitat de l’estat del sistema
«El sistema ha de mantenir a l’usuari informat sobre el que passa a través d’una retroalimentació apropiada en un temps raonable.»
La Meva Salut aplica una bona pràctica, però millorable. Gravetat 2/5.
Justificació: Tot i que segons quina pantalla és una mica discret, pràctiacment en totes les pantalles sabem quina mena d’informació estem consultant per no perdre’ns ni tenir cap mena de incoherència en el que es consulta. Malgrat que l’usuari sap en la major part del temps on es troba, considero que aquesta es pot millorar. En primer lloc, molt lligat a l’estètica, caldria mantenir una consistència del disseny per identificar les diferents seccions. A més a més, hi ha títols de secció que tenen també la funcionalitat de menú per navegar entre diferents seccions però no a totes i això podria confondre a l’hora de relacionar conceptes. Caldria afegir que hi ha dues seccions que no contenen informació directe com la que es mostra en els següents exemples, i és que desde la informació de l’aplicació s’informa que hi ha seccions que no estan disponibles en l’aplicació mòbil i això fa que la visualització sigui la d’un iframe incrustat de la versió web. A continuació es poden veure alguns exemples.
2. Adequació entre el sistema i el món real
«El sistema ha de parlar en el llenguatge de l’usuari, amb paraules, frases i conceptes familiars per ell. Utilitzar convencions del món real, fent que la informació apareixi en un ordre natural i lògic.»
La Meva Salut aplica una bona pràctica.
Justificació: Una de les dificultats que es podria trobar el servei sanitari és fer servir un ús excessiu del vocabulari mèdic i que en la propia navegació de l’aplicació pugui contenir llenguatge no habitual per l’usuari. Però en canvi, es fa servir un llenguatge bàsic per tal de poder accedir i poder realitzar les diverses consultes (exceptuant la informació mèdica que necessariament ha de tenir un llenguatge adequat). Un dels punts a destacar és l’ús adecuat de la iconografia, així com que acompanyat d’un text explicatiu en cas necessari, que a mesura que l’usuari va accedint, finalment és capaç de relacionar els conceptes a més a més dels que ja té apresos. Un exemple seria identificar com consultar la medicació, les vacunes que un té o fins i tot l’apartat de consultar la cita prèvia.
3. Llibertat i control per part de la persona usuaria
«A vegades els usuaris escullen funcinalitats per error i necessiten una ‘porta d’emergència’ per sortir d’un estat indesitjat. Oferir suport per desfer i refer accions.»
La Meva Salut aplica una bona pràctica.
Justificació: Si bé és cert que cap dels tràmits permesos té cap perill per l’usuari, hi ha dos tipus d’interacció de l’usuari que potser podria cometre un error que vulgui desfer. Els dos casos més habituals serien els de realitzar una consulta/demanar cita prèvia o bé canviar alguna informació personal o bé configuració de l’aplicació. En ambdós casos, en el cas que es sol·liciti una cita prèvia, sempre es pot cancel·lar accedint a les visites programades; en el cas que es canvïi alguna configuració personal, sempre es pot refer la modificació si, per exemple, s’ha introduit alguna informació erròniament. A més a més, en alguns casos et demana comfirmació abans de cancel·lar o eliminar alguna configuració o cita prèvia, per evitar que l’usuari s’equivoqui per accident. Un exemple en imatges seria el cas de configurar els serveis disponibles a consultar, per tenir accés ràpid.
4. Consistència i estàndars
«Els usuaris no haurien de preguntar-se si diverses paraules, situacions o acción signifiquen les mateixes coses. Que es segueixin les normes i convencions de la plataforma sobre la que està implementat el sistema.»
La Meva Salut aplica una mala pràctica. Gravetat 5/5
Justificació: Una de les coses en les que destaca l’aplicació, negativament, és que fa una barreja de estàndars entre la plataforma mòbil i la plataforma web. Què significa? Que tant aviat pots tenir una secció ben pensada per a gestionar-ho des de mòbil com et trobes una altra secció per gestionar-la amb vista web. A més a més, l’estètica de les dues versions no es manté en la majoria dels casos o es dupliquen banners per incrustar un iframe amb la matèixa estètica de l’aplicació. El gran problema d’incrustar web en l’aplicació mòbil és que si la web no es manté estèticament com l’aplicació hi ha una disonància molt gran, com és el cas, i si a més a més no s’aplicat el concepte de responsive a l’hora de desenvolupar la web, ens podem trobar coses com les següents.
Per què és important? És important perquè quan l’usuari veu aquesta barreja de visualitzacions i d’estàndars, principalment quan es troba amb la part web el primer que pot pensar és «perquè voldria fer servir l’aplicació si em mostra la web? Si ho he de fer servir amb la vista web, millor faig servir un ordinador per fer les gestions» i es perdria l’objectiu base. L’única avantatge que tindria l’aplicació mòbil sobre la web per a fer que es mantingui, malgrat aquesta disonància, és que iniciar secció es pot automatitzar amb paràmetres biomètrics pròpis de la plataforma.
5. Prevenció d’errors
«Abans que dissenyar bons missatges d’errors, és millor evitar que el problema es dugui a terme.»
La Meva Salut aplica una bona pràctica.
Justifiació: Com s’ha explicat en la secció «Llibertat i control per part de la persona usuaria», en cas que es realitzi una acció -encara que reversible- que l’usuari pugui penedir-se, apareixen missatges d’avis abans de comfirmar l’acció. Un altre exemple on hi ha aquesta prevenció d’errors és en l’inici de sessió, en el cas que es faci servir usuari i contrasenya, en lloc d’identificador biomètric, l’aplicació no et permetrà prémer el botó d’accés per a comprovar dades buides.
6. Reconeixement abans que record
«Minimitzar la càrrega de memòria de l’usuari fent que els objectes, les accions i les opción estiguin visibles. L’usuari no té perquè recordar la informació d’una part del diàleg a una altra»
La Meva Salut aplica una mala pràctica. Gravetat 3/5
Justificació: Una de les avantages que té l’aplicació en quant a l’arquitectura de la informació és que està dissenyat de forma que no cal accedir a moltes pestanyes internes, si no que aquelles acción més bàsiques es poden accedir en pocs passos i gairebé no necessites recordar un recorregut perquè és directe. Però, el fet que no totes les seccions tinguin identificat on es troba l’usuari i que es barregi amb la web incrustada, fa que l’usuari es pugui trobar en la situació de «no recordo com he arribat fins aquí» i que si hagués de repetir l’exercici, hauria de tornar a començar enraonant com arribar fins aquell punt. Exemples de mala pràctica és la secció de tràmits i serveis o bé les consultes i cites prèvies.
Un altre dels efectes que succeeix és que un parell de seccions porten al mateix lloc i això encara pot confondre més a l’usuari que intenta recordar el camí que ha fet, però varis camins són possibles. A continuació es pot veure un gif com a exemple.
7. Flexibilitat i eficiència d’ús
«Els acceleradors, no vistos per l’usuari principiant, milloren la interacció per l’usuari expert de tal manera que el sistema pot servir per usuaris inexperts i experimentats. És important que el sistema permeti personalitzar accions freqüents.»
La Meva Salut aplica una bona pràctica, però millorable. Gravetat 1/5
Justificació: en quant a les possibilitats de l’aplicació no són extremadament extenses com per a que sigui estrictament necessari una alta personalització per als usuaris experts, el que es veu és el que és. I tot i així, es permeten afegir serveis a «favorits» per tal de poder accedir-hi més ràpidament. Però, encara que totes les funcionalitats són accessibles per a tots els usuaris en un grau de dificultat senzilla, sí que seria interessant poder personalitzar la pantalla principal per a facilitar l’accés i prioritzar les gestions més habituals, com podria ser accedit al certificat Covid, a la medicació o directament a la gestió de cita prèvia. Aquest grau de personalització podria millorar l’eficiència però considero que no és massa freu que no ho tingui perquè tot està relativament accesible. A més a més, un cop s’ha accedit per primera vegada a l’aplicació, aquesta en guarda les dades d’accés per tal que la següent vegada sigui més àgil.
8. Disseny estètic i minimalista
«Els diàlegs no haurien de tenir informació irrellevant o que es necessiti rarament. Cada unitat extra d’informació en un diàleg competeix amb la informació important, disminuint la visibilitat relativa.«
La Meva Salut aplica una mala pràctica. Gravetat 5/5
Justificació: Com s’ha vist en els altres principis, l’aplicació mòbil d’entrada conté un disseny bastant minimalista en general però on cau considerablement és en les seccions que contenen la web incrustada, que trenca tota l’estètica corporativa de l’aplicació. En les imatges següents podem veure aquesta disonància:
Per què és important? Com ja hem comentat, trencar amb aquesta estètica no només funcionalment, té un impacte negatiu sobre l’usuari. Potser no està trobant un cas de sobreexposició d’informació però no hi ha una coherència que permeti identificar tota la aplicació amb totes les seves funcionalitats com a una unitat funcional, sino que sembla com si fos una aplicació montada a peces, algunes «locals» altres de la web.
9. Ajuda a les persones usuaries a reconèixer i diagnosticar els errors i a recuperar-se
«Els missatges d’error han d’estar expressats en un llenguatge pla, sense codis, indicant amb precisió el problema i suggerir una solució.«
La Meva Salut aplica una mala pràctica. Gravetat 3/5
Justificació: en la gran majoria de casos quan es produeix un error com que la sessió ha expirat, l’usuari es pot recuperar correctament. Malgrat això, hi ha altres casos d’errors genèrics o errors d’aplicació que no estan informats o bé no es suggereix cap solució. Aquest es el cas de quan s’intenta accedir a una e-consulta amb un usuari que aparentment té un error d’accés però no pot fer res per intentar solventar-ho, no està al seu abast, però tampoc s’informa de com intentar arreglar-ho, a qui hauria d’adreçar-se? O un altre cas és, com per exemple, quan s’intenta demanar una cita prèvia, el sistema no carrega correctament el formulari, si l’usuari ha accedit abans sabrà que allà hi falta aquest formulari però si no, com sabria que hi ha un error d’aplicació i quin tipus d’error? Com es solventa?
Per què és important? És important que el control d’errors estigui molt ben aplicat perquè no tenir-lo, dona una imatge de incomplet, com si estigués a mitges o que no s’ha cuidat bé tots els casos i això és molt important fer-ho arribar als desenvolupadors i destacar la importància d’aplicar-ho.
10. Ajuda i documentació
«Encara que es millor que es pugui fer servir el sistema sense documentació, és necessarti proporcionar a l’usuari ajuda i documentació. Aquest ha de ser fàcil de buscar, centrat en les tasques de l’usuari, amb informació de les etapes a realitzar encara que no sigui molt extensa.»
La Meva Salut aplica una bona pràctica, però millorable. Gravetat 1/5
Justificació: L’aplicació de La Meva Salut només entrar disposa de conèixer els serveis que disposa i per a què serveix cadascun, encara que no aparèixen tots els que realment té com a seccions principals. També disposa d’informació d’ajuda amb les preguntes més freqüents de gestions amb el Sistema Sanitari. Tot i que no hi ha molta sofisticació en les tasques més habituals, aquest inclou informació de què cal fer per completar la tasca, com per enviar una consulta per a cita prèvia. Tot i així, podria ser millorable primer de tot perquè no conté tota la informació de totes les possibilitats per tal de dur a terme i entendre cada secció i en segon lloc perquè hi ha com a últim recurs trucar al 061 per a més informació, però el que no t’informa és que aquest telèfon és de pagament i potser l’usuari voldria intentar investigar més abans de trucar. A més a més de completar la informació, els banners del principi abans d’accedir amb l’usuari, només aparèixen a fora i seria convenient també poder veure-ho un cop loggejat.
Problemes identificades
Durant l’evaluació heurística s’han identificat 7 problemes de disseny que seria necessari fer-hi una pensada per a que l’experiència d’ús sigui millorada. A continuació es recullen segons els principi heurísitcs de Nielsen, els problemes identificats i s’indica el grau de gravetat. El detall de la justificació es pot trobar desenvolupat en l’evaluació anterior.
Disseny estètic i minimalista – Gravetat 5/5
Consistència i estàndars – Gravetat 5/5
Ajuda a les persones usuaries a reconèixer i diagnosticar els errors i a recuperar-se – Gravetat 3/5
Reconeixement abans que record – Gravetat 3/5
Visibilitat de l’estat del sistema – Gravetat 2/5
Flexibilitat i eficiència d’ús – Gravetat 1/5
Ajuda i documentació – Gravetat 1/5
Conclusions
El gran problema que té l’aplicació mòbil és que està barrejant el disseny de dos tipus de plataformes que produeix que hi hagi una disonància en tota l’aplicació. Si bé és cert que hi ha apartats que sembla que hi hagi la Web incrustada, manté un disseny molt similar al de l’aplicació i podria passar desapercebut (exceptuant el doble banner). Però hi ha altres funcionalitats molt bàsiques i característiques que s’esperen que es pugui fer des de l’aplicació com les e-consultes però en canvi apareix la vista web.
«Migrar totes les funcionalitats web incrustades a funcionalitats mòbils»
En quant a aquesta millora proposada, pot ser que inicialment no es pogués realitzar tot o bé hagués quedat fora del presupost o els temps d’entrega, migrar tota la funcionalitat. Però també podria ser que tècnicament, les gestions de cites i consultes compti amb un sistema tancat que no es pugui accedir des de fora de la Web, en aquest cas caldria fer un anàlisis prèvi del servei de consultes a nivell de desenvolupament per veure de quina manera es pot extendre per poder aplicar les duncionalitats sense dificultats al mòbil.
En segon lloc, ens trobem amb el problema de la detecció d’errors. Aquí hi ha un problema de retroacció d’errors no identificats i saber com gestionar-los per parts de l’usuari.
«Revisar tots els possibles errors i assegurar-se que hi ha un feedback de tornada de qualitat per a que l’usuari sàpiga com reaccionar»
En quant al principi de «reconeixement abans que record», ens hem trobat que l’usuari podria oblidar on es troba en quant navega per l’interior i si oblida d’on ve, com podria tornar a arribar si no hi ha res que permeti reconèixer el camí de tornada?
«Traçabilitzar la ruta segons l’estat en les seccions que hi hagi diverses pantalles fins arribar al final»
Pel que fa a la visibilitat de l’estat del sistema, en general està prou ben aconseguit però no és suficient, especialment relacionat amb el problema identificat anteriorment. Però a més a més, caldria homogenitzar l’estètica per poder identificar les diferents seccions, així com està estructurat al menú lateral, per tal que hi hagi una concordança estètica i de conceptes, per poder tenirn un model mental més acurat i entendre millor els diferents nivells sense haver d’accedir al menú concretament.
«Aplicar concordànça en totes les seccions del sistema per ajudar a situar a l’usuari en cada pantalla»
Finalment, tenim un parell de problemes menors que aplicar una millora faria que l’usabilitat fos de més qualitat. Aquests són permetre una mica més de personalització per tal de tenir accés més ràpid per aquells usuaris més experimentats, i tenir la documentació d’ajuda una mica més accessible així com actualitzada i en coherent amb les funcionalitats oferides.
«Permetre la personalització d’accessos ràpids a usuaris experimentats»
«Oferir informació d’ajuda actualitzada i coherent amb l’aplicació»
Aquestes dues últimes no s’han qualificat com a molt greus degut a que l’aplicació o bé no requereix molts accessos per la seva simplicitat, així com que l’ús és més aviat esporàdic, i perquè l’aplicació és prou autoexplicativa com per no necessitar molta més informació de la que ja s’ofereix.
Hola! Us comparteixo l’escenari proposat per en David Martínez, com gestiona la compra d’entrada per poder gaudir de l’experiència hibrida que ofereix Mutek. Em sembla interessant compartir aquest primer escenari per tal de tenir una primera vista del que l’aplicació pot oferir com a nivell interactiu inicial.
Escenari
En David fa anys que segueix les activitats que realitza Mutek, té les notificacions de Twitter activades per no perdre’s cap esdeveniment ni noticia rellevant del món de la música. El mòbil sona, en David mira la pantalla i veu que Mutek a fet un post indicant l’inici de temporada dels festivals que organitza i, sobretot, fan èmfasis en la nova possibilitat d’assistir-hi des de qualsevol lloc del món a través de la seva app mòbil.
Com no podia ser d’una altra forma, en David es descarrega la aplicació mòbil i es registra amb el seu correu de Google. Un cop dins, el primer que busca és el llistat de performances, el que veu es com si fos un feed d’una xarxa social on indica informació en primera plana del tipus de performance, l’artista, la data i el lloc. A més a més, disposa d’una icona que li permet guardar a favorits aquell esdeveniment publicat. En David no pot evitar emocionar-se quan veu que l’Anne Woods, una de les seves artistes preferides, realitzarà un concert el proper divendres. Sense dubtar-ho ni un segon més, pitja a l’esdeveniment per veure com podria gestionar l’assistència. Quan obra el detall, veu una descripció de la performance que realitzarà, així com les dades principals que ja es veien en el feed, però a més a més també hi veu dos botons: “Accedir en streaming” (opció que retorna un feedback de que encara no és el dia) i “Comprar entrades”. Quan pitja la segona opció, li apareix dues opcions o bé pot comprar les entrades d’asistència física o bé l’opció de Realitat Augmentada.
La possibilitat d’assistir a un concert amb realitat augmentada li crida l’atenció, però encara més que facin servir la tecnologia de Google ARVR, doncs permet no només experimentar la realitat augmentada des del mòbil, sinó que si disposa de les ulleres de VR podrà experimentar l’experiència d’un concert immersiu virtual. Els passos de compra es divideixen en 3 passos: verificació de les dades de compra, verificació de les dades personals i finalment, introducció del mètode de pagament. Els passos són molts similars a altres llocs de compra online i són clars, per a que no es perdi i en tot moment pot retrocedir en cas de dubte.
Este es un espacio de trabajo personal de un/a estudiante de la Universitat Oberta de Catalunya. Cualquier contenido publicado en este espacio es responsabilidad de su autor/a.