Introducció

La proposta d’aplicació web Short.ly és un producte que pretén permetre als usuaris que la facin servir escurçar URLs llargues i, en cas que es vulgui gaudir de més funcionalitats, registrar-se i permetre, no només personalitzar les URIs dels enllaços escurçats, sinó fer un seguiment de les estadístiques generades per cadascun dels enllaços guardats.

Una de les motivacions per crear el producte de Short.ly era la de tenir un escurçador de URL que permetés tenir les següents 3 funcionalitats principals especificades en el briefing:

• Permetre estalviar caràcters en xarxes socials que limiten la longitud dels missatges (per exemple Twitter). Així, en lloc de gastar molts caràcters amb l’enllaç, poder escurçar-lo i disposar de més espai per al nostre missatge.
• Permetre generar enllaços més fàcils de recordar, en ser més curts.
• Permetre consultar estadístiques d’ús de l’enllaç, per exemple, quantes persones han entrat en l’enllaç i des d’on.

L’usuari objectiu d’aquest producte pot ser molt divers ja que pot ser molt divers però la principal característica és que serà un usuari que requereixi d’un seguiment d’activitat de les seves publicacions i que poder consultar les estadístiques sigui considerat un punt de valor. Però també podem tenir un usuari casual que només vulgui escurçar la URL i necessita que sigui ràpid i fàcil. D’aquesta manera el producte s’ha de poder adaptar a la necessitat dels dos tipus d’usuaris principals.

Per a la proposta de producte cal tenir en compte que s’ha d’adaptar a dos tipus de breakpoint: l’escriptori (Desktops) i el mòbil (Mobile).

Així doncs, al llarg del document s’explicarà com ha estat el procés de disseny des del briefing presentat i les primeres idees d’inspiració, fins a l’avaluació amb usuari i les millores identificades durant les entrevistes.

Punt de partida

La idea principal de la proposta de producte és que ha de transmetre rapidesa, simplicitat, seguretat i confiança. Per aquest motiu la gama de colors triats són més aviat colors verds i blaus i com a color ressaltat secundari, el color taronja. Per mostrar un costat més simple i minimalista es procurarà també tenir una base blanca per poder tenir la sensació de treballar en un entorn el més polit possible. A més a més es proposa fer servir la tipografia de Segoe UI per fomentar aquesta sensació de simplicitat. Aquests són els principals valors que es volen transmetre amb el producte. S’adjunta el Moodboard.

Donat que Segoe UI és una de les tipografies oficials de Microsoft, s’ha fet servir com a inspiració pels principals components els estàndards definits per Fluent UI [1].

Un cop s’ha buscat la inspiració en els principals valors que es volen transmetre, s’ha definit la paleta de colors, la tipografia, iconografia (també de Fluent UI), els logos i els principals layouts per tenir la base de l’univers visual. Un cop definits s’ha pogut començar a elaborar els primers elements interactius simples, com s’ha comentat, inspirats en Fluent UI.

Després de crear els primers components simples, s’ha elaborat els elements més complexes de la solució amb els components simples.

Finalment, amb totes les peces ja preparades, es el moment de muntar el trencaclosques per a presentar el nostre producte.

Procés de disseny

Primera versió de ptototip

La proposta de solució consta de 4 pantalles principals: la pàgina principal sense estar loggejat, la pàgina de registre, la pàgina principal loggejat i la pàgina de perfil. Tenint ben poques pantalles permet per una banda centrar-se en la interacció dels components més específics i complexos i al mateix temps, permet donar senzillesa a l’aplicació de cara a l’usuari.

Cal matisar que al llarg del document es mostraran les captures referents a la proposta del breakpoint Desktop, però tots els canvis millorats també s’han aplicat al breakpoint Mobile.

Pàgina principal loggoff.

Pàgina de registre.

Pàgina principal loggin.

Pàgina de perfil.

Una de les decisions més difícils de prendre ha estat el com representar les estadístiques de manera que d’un sol cop d’ull es pogués veure una visió global de les visites sense que aquesta acapares atenció de l’usuari innecessàriament. És possible que sigui un punt de conflicte però es podrà verificar amb l’avaluació amb usuaris i fins i tot potser recollir idees per part seva.

Avaluació amb usuaris

Una de les formes més efectives d’avaluar el prototip és provar-ho amb usuaris. Per aquest motiu s’ha dissenyat un test comprès per les preguntes preliminars per tal de conèxer l’usuari, un total de 4 tasques per avaluar la interfície i finalment s’ha relitzat un qüestionari SUS per veure quina és la percepció dels usuaris.

A continuació podeu veure el resutlat de la valoració SUS:

Anàlisis dels resultats i punts de millora

En primer lloc, els usuaris tenen una perspectiva de l’aplicació que és molt fàcil de fer servir per allò que està pensada i que en cas d’error no troben que sigui prou crític com per a que la seva valoració empitjori. Però malgrat que el valor SUS està dins de l’escala “Acceptable”, té aspectes que permetran una millor experiència.

En primer lloc i el més evident de tots és el que tots 3 usuaris han indicat des de la pàgina de perfil “com torno enrere?” Falta una navegació per tornar a la pàgina d’inici, ja que no és prou intuïtiu que el logotip porti a la pàgina d’inici. Un altre aspecte important és la falta de feedback. Hi ha passos com el copiar la URL, registrar-se o fins i tot casos d’errors que no tenen feedback suficient. També faltaria corregir la prevenció d’errors de casos com el qui indica la usuària 3, que directament ha posat la URI personalitzada sense cap enllaç.

Entrant en l’aspecte d’estadístiques, en general hi ha certa confusió, tot allò que canviï de color “com els botons” sembla clicable i per tant s’espera que hi hagi alguna informació de retorn, però “no passa res”. A més a més es suggereix revisar l’estructura del detall així com aportar més informació com gràfic de barres per més detall.

Finalment afegir que seria interessant afegir informació referent als requisits de la contrasenya, per tal que l’usuari senti la seguretat que la seva contrasenya és vàlida sense haver d’anar fent prova i error.

Cal comentar que alguns dels punts de millora trobats s’haguessin pogut evitar si prèviament s’hagués fet una avaluació heurística per confirmar que aquesta primera proposta compleix amb el major rigor possible els 10 heurístics que fan que una aplicació sigui robusta i coherent.

Millores aplicades

Un cop identificats els punts de millora, s’han valorat i realitzat una proposta de solució als problemes de la primera versió del prototip.

Feedback

Un dels principals problemes era el feedback de les accions, saber què el que estic fent fa alguna cosa. En aquest cas s’han identificat principalment la falta de feedback en copiar una URL, en registrar-se i en identificar si la URI està disponible o no. S’han resol de la següent manera.

Just després de prémer el botó de copiar, surt un pop-up breu de confirmació de que s’ha copiat correctament

Un cop pitjat el botó de registrar-se en la pantalla de registre, apareix el següent missatge de benvinguda.

Quan la URI està disponible s’indica en la mateixa entrada de text de color verd, en cas contrari seria vermell.

Navegació de retorn

El principal problema de la pàgina de perfil és que no hi ha una manera visual de tornar a la pàgina inicial, o fins i tot de saber on estic. Per resoldre això s’ha solucionat de la següent manera: afegint la navegació a la zona esquerra i tancar la sessió per poder tornar a la primera pàgina.

Prevenció d’errors

Per evitar que l’usuari fas en un ordre erroni el fluxe d’interacció proposat, s’ha deshabilitat allò que no pot fer servir si no és el moment i afegit missatge d’error en cas que s’intenti escurçar sense tenir una URL.

Gràfica “clicable”

Per evitar que l’usuari es senti convidat a pitjar la gràfica s’ha eliminat l’efecte de ressaltat dels blocs de les barres de la gràfica. Ara quedaria de la següent manera.

Estructura detall estadístiques

Per a que quedi més clara la relació entre els components dels detalls, es proposa canviar la distribució de la següent manera.

Requisits de la contrasenya

Per tal d’aclarir els requisits de la contrasenya, tot i que pel prototip en sí no era possible posar res equivocat, s’ha afegit aquest missatge com a ajuda.

Altres correccions

Altres aspectes que s’han identificat durant les entrevistes, tot i que no afecta directament als fluxos proposats, calia tenir en compte per a que l’aplicació tingui més consistència. Un dels casos ha estat el botó de “Editar les meves dades”, s’ha posat com a botó secundari per evitar que cridi l’atenció de l’usuari.

 

A més a més, els desplegables que estan col·lapsats ara tenen un gris més fort mentre que els que estan desplegats mantenen un gris clar.

Prototip millorat

Per poder veure el prototip versió escritori, consulteu el següent enllaç: https://www.figma.com/PEC4—Prototipatge

Conclusions i aprenentatges

La proposta de solució Short.ly és un producte que té unes premisses de funcionament molt senzilles i que amb la meitat de les funcionalitats un usuari casual podria ser-li útil. Aquesta senzillesa de funcionament ha permès donar una imatge de simplicitat del producte i que, malgrat els problemes identificats en la fase de testeig, els usuaris s’han sentit còmodes i sobretot que dominaven l’aplicació fins on ells creien. Però com s’ha comentat abans, que un producte funcionalment sigui senzill no implica que la seva experiència pugui ser descuidada i al llarg de l’estudi ho hem pogut veure.

Elaborar un univers és una tasca complicada i que requereix d’un esforç extra de creativitat, però aquesta inversió de temps en l’aspecte més creatiu no pot descuidar els principis d’usabilitat de l’aplicació, ans al contrari. Els principals problemes del prototip rauen en la falta d’haver fet una avaluació heurística que permeti identificar els primer punts de millora, aspectes que un dissenyador ha de tenir presents a l’hora de prototipar. Si s’hagués fet aquest exercici abans de passar el test amb els usuaris, es podria haver corregit per poder buscar altres punts de millora en les entrevistes.

Una de les coses que queda molt clara en aquest estudi és que el disseny és un procés iteratiu. Què implica això? Que requereix de proposar, avaluar i corregir de forma iterada. Per sort hi ha diferents estratègies per poder avaluar i aplicar diferents fases d’avaluació, amb i sense usuaris, ens permet tenir més ventall d’opcions i perspectives per trobar millores davant d’un problema.

Finalment, si una cosa reflecteix tot aquest estudi és que la senzillesa permet que un producte sigui atractiu però encara més si en termes d’usabilitat és robust i consistent. Per simple que pugui semblar el servei, és important no perdre de vista els principis d’usabilitat perquè si en casos relativament simples no hi ha l’hàbit d’aplicar-ho, com es pot esperar que d’una solució més complexa es pugui tenir present?

Introducció

Tot i que avui dia, tots aquells objectes que fem servir diàriament molt possiblement sabem com fer-los servir, no vol dir que estiguin ben dissenyats per a que sigui el més òptim per l’usuari i eviti caure en error o fer-lo servir malament “encara que funcioni” a base de prova i error. Un dels objectes que des de fa unes dècades que cada llar disposa d’una és la rentadora. En aquest cas escollirem d’exemple la rentadora Edesa model LEA-6110, que és un model una mica antic i econòmic però en quant a interacció és senzilla, ja que consta d’una rodeta per a seleccionar el programa, 3 botons per a altres configuracions i un quart botó per a engegar i parar la rentadora.

L’objectiu d’aquest estudi és fer una avaluació de la interfície de la rentadora i, després de provar amb varis usuaris, fer una proposta de millora en un prototip.

Donat que hem escollit un model relativament econòmic i simple, es planteja posar com a objectiu mantenir la simplicitat de la interfície però que sigui el més òptim, sense incorporar elements que encareixin el producte com una pantalla LED o més opcions que no estan contemplades en els programes de la rentadora. D’aquesta manera es vol demostrar que no cal invertir molts més diners per tal de millorar una interfície.

Memoria

Vídeo

Introducció

Quan ens trobem davant d’una nova necessitat d’un client o un nou projecte, moltes vegades no es parteix de cap idea preconcebuda i es aquest el moment on un dissenyador UX/UI ha de plantejar un univers visual del producte. Tècniques com el moodboard poden ajudar a pensar en aquest univers i permetre al dissenyador fer una proposta de disseny així com elaborar el prototip en base a aquest.

Un aspecte a tenir en compte en aquesta pràctica és que partim des de zero, el que implica que cada element interactiu que volguem incloure ja sigui ara o en un futur, serà necessari que es plantegi per a que l’equip desenvolupador pugui consultar-ne sense que hagi de tornar a passar a mans de l’equip de UX/UI, especialment en els elements més unitaris. També és important que l’hora de crear el UI KIT del producte, aquest sigui el més clar i entenedor possible per a l’equip de desenvolupament.

La imatge que es volia donar amb Short.ly és la d’una web segura, minimalista i amigable principalment. Per aquest motiu s’han volgut triar colors com el blau i el verd per denotar aquesta confiança i colors ataronjats/groguents en moments puntuals per tal de fer notar aquesta simpatía. Així mateix, en quant a tipografies, per al logotip ens hem inspirat en les xarxes socials, per donar un toc juvenil i refrescant alhora que ens hem decantat per a la resta de textos del producte per Segoe UI. A continuació es mostra el moodboard fet servir per aquesta pràctica.

Enllaç al prototip

A continuació teniu els enllaços dels prototips per a escritori i per mòbil, així com un flux per provar els elements interactius principals.

URL Prototip Breakpoint – Desktop

URL Prototip Breakpoint – Mobile

Elements interactius testing

Vídeo dels fluxos d’interacció

En el següent vídeo es poden contemplar el flux d’interacció d’escurçar una URL sense iniciar sessió, així com els passos necessaris per a poder registrar la URL per recollir-ne estadístiques.

Flow Short.ly Breakpoint Desktop | Ariadna Ortega Rams

Conclusions

Una de les principals dificultats que m’he trobat a l’hora de crear el prototip del producte ha estat crear l’univers visual. Tot i que tenia una idea clara del que volia transmetre i els colors que Short.ly em transmetia, l’estil de tots els elements està molt influenciat per l’estil de Microsoft, fent servir com a referència Fluent UI, React i Material UI. Però malgrat ser molt influenciada per aquesta estètica minimalista, sóc conscient que he de practicar en les questions estètiques, sobretot quan he de partir des de zero.

Un altre aspecte que cal destacar és que com a UI kit han faltat alguns components que potser ara no es fan servir però més endavant serien necessaris. Un exemple del que ha pogut faltar és tota mena d’inputs diferents, no només els de text que hem fet servir activament en el prototip.

Com a punt de millora, a part de treballar en aprendre a crear nous estils, crec que hauria de plantejar el UI kit de manera diferent, enlloc de pensar en què necessito per l’aplicació, podria començar creant tots els elements interactius més habituals, sense pensar en la funcionalitat en sí del producte, de manera que faria que l’UI kit fos més complet. L’ordre i la metodologia en la creació d’un UI Kit des de zero són fonamentals per a que l’equip de desenvolupament pugui consultar totes les possibilitats de forma ordenada i autònoma.

Finalment, crec que he fet una bona feina i que estic millorant respecte altres treballs més senzills de prototipar i respecte l’anterior pràctica. Sento que he aplicat de forma més consistent les eines de sistematització de Figma, el qual m’ha permès que la creació de les pantalles fos extremadament ràpida un cop tenia els elements unitaris i els més complexes creats.

Introducció

Una de les eines més importants per al diseny d’un sistema interectiu la guia d’estils que serveix per poder ser consistents a l’hora de disenyar el prototip que reflecteixi el que es vol realitzar i també serveix per als programadors tenir clar com són els elements a crear i quiens consignes han de seguir.

Per aquesta pràctica s’ha fet una deconstrucció de la pàgina web de AirBnB. S’han hagut d’identificar els 3 breakpoints (Escriptori, Tableta i Mòbil), així com els layouts, els components, tipografíes i gama cromàtica. Un cop identificat el comportament s’ha realitzat el prototip d’un dels breakpoints (Escriptori).

Aprenentatges a destacar

Durant la pràctica he fet servir l’eina de Figma. No l’havia fet servir gaire abans, tampoc coneixia l’abast d’aquest, i amb aquesta pràctica he après i entès de primera mà què tant important són la creació de components i les seves variants per tal d’agilitzar la creació del prototip i les diverses parts. El fet de tenir-ho prou agrupat, m’ha permès reduir les «pantalles» d’interacció i respecte l’anterior protitip que vaig fer, s’ha simplificat molt gràcies a fer servir aquests components i variants. A continuació adjunto una imatge per mostrar com de simplificat ha quedat.

Prototipat i vídeo

A continuació es mostra l’enllaç al vídeo i el prototip del fluxe d’interacció.

URL Vídeo mostrant el flux d’interacció. Breakpoint – Desktop

URL Prototip Breakpoint – Desktop

Conclusions i autoavaluació

Després de realitzar tot aquest treball, he de començar dient que he subestimat la profunditat de la feina que hi havia a realitzar. Això ha fet que el temps se’m tirés a sobre i en conseqüència no he acabat el treball amb la qualitat que hagués volgut entregar. Malgrat això, tinc la sensació d’haver après molt, no només en fer servir l’eina de Figma, sinó en pensar en estalvi de recursos i temps.

En primer lloc, l’exercici d’anàlisis m’ha semblat relativament senzill ja que tinc pràctica en investigar llocs web per veure «com són les coses». Gràcies a això, m’he vist capaç de descarregar totes les icones originals, tant imatges com svg, i anar a filar prim en cada detall com la tipografia.

En el moment que m’he posat a fer els components, al principi em costava veure tot el que havia de fer i què no. A mesura que anava creant components anava veient què necessitava i el que m’ha semblat curiós es que hi ha una frase que s’aplica en aquest exercici, així com en la programació, que m’ha fet entendre la gran utilitat dels components: «Tot allò que hagis de copiar d’un altre lloc, potser cal que existeixi un component/funció per a estalviar feina, i si cal canviar-ho es pot fer tot d’una.»

Finalment comentar que fer aquest exercici de deconstrucció m’ha fet pensar en la profunditat del disseny d’un prototip, tota la feina que comporta i l’important que és pel dia de demà ser conscients del treball que suposa per defensar-ho en els futurs projectes en el que participem com a UX.