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:
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.
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.
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.
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.
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:
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.
Un cop identificats els punts de millora, s’han valorat i realitzat una proposta de solució als problemes de la primera versió del prototip.
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.
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.
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.
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.
Per a que quedi més clara la relació entre els components dels detalls, es proposa canviar la distribució de la següent manera.
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 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.
Per poder veure el prototip versió escritori, consulteu el següent enllaç: https://www.figma.com/PEC4—Prototipatge
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?
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
El modelo que se ha seguido para llevar a cabo este proyecto está basado en Design Thinking.
Tras partir de un briefing y toma de requisitos, que nos solicitaba trabajar desde 0 en una aplicación web responsive para acortar enlaces, y que permitiera consultar los datos estadísticos de estos. Se empezó trabajando en un mapa mental para desbloquear posibles conceptos con los que trabajar desde la parte de branding y look&feel. En este caso, optamos por marcar con el sticker de estrella aquellos términos que más encajaban y transmitían como ráfaga y shortcut haciendo referencia a la rapidez, color azul vaquero a lo tecnológico e informal, y el amarillo representativo de la energía y de los avisos de seguimiento y control.
Antes de realizar algún tipo de evaluación exploratoria con usuarios, se tiró de técnicas de investigación sin ellos como puede ser el desk research, y para tener una idea más acertada de la competencia, no sólo a nivel funcional sino también a nivel gráfico, también el bechmarking, ambas para detectar cómo funcionan otras alternativas. Llegando a una conclusión de combinación de colores accesibles, una tipografía de carácter monospace muy tecnológica y un logotipo o simbolo que representa a la perfección la acción de cortar, ayudando incluso a cortar la legibilidad de la url de la aplicación web: «short | ly»
Antes de abordar y tomar decisiones que requieran de más desarrollo, se trabaja la posible solución en papel, anotando el tipo de interacción y navegación. En algunos casos, este tipo de ejercicio ya es usado como primera iteración con cliente y usuario para ir obteniendo feedback, principalmente para desbloquear y alinear los modelos mentales de interfaz de usuario que pueden tener todos los del equipo.
De forma paralela, tras definir los foundations básicos (logotipo, color, tipografía e iconos) se empiezan a detectar componentes, y a definirlos y parametrizándolos mediante figma. Pensando en todas sus posibles variantes y anatomía, se recogen los siguientes:
Esta primera versión de wireframes y prototipo navegable, ya nos servirá de base para lanzar las pruebas con usuarios o investigación evaluativa, y así ir refinando mejoras del producto, iteración tras iteración.
Estas pruebas se realizarán testeando los dos flujos básicos que se requerían. El acortar una url y el consultar sus estadísticas. En este caso, para hacerlas más completas, se optó por definir:
Tras el reclutamiento de los usuarios, se les plantearon las siguientes dos tareas que ponían a prueba los dos flujos descritos. Previamente y posteriormente, se llevaron a cabo también el lanzamiento de algunas cuestiones con el objetivo de conocer un poco más el perfil del participante y recoger finalmente una encuesta de NPS y SUS para así ir teniendo una medida cuantitativa a lo largo de las iteraciones a modo de punto de control.
TAREA Nº1
Historia de usuario:
“como persona que consulta medios digitales y ha encontrado una interesante noticia en youtube quiere acortar el enlace de dicha publicación de manera automática para poderlo compartir desde su perfil de instagram sin tener que borrar el resto de datos que ya tiene. Imagine que el enlace a acortar es el siguiente: https://www.youtube.com/watch?v=EI80NnTGIZs
Obtenga un enlace corto de forma automática y comunique cuál es.”
TAREA Nº2
Historia de usuario:
“como persona que quiere compartir su video curriculum vitae quiere acortar el enlace de la plataforma donde lo ha subido, pero de manera personalizada para poder así, dar mayor visibilidad a su candidatura. Y para ello, tendrá que comprobar que está disponible la extensión que le interesa, y de igual modo poder ver el uso que ha tenido el enlace para hacer un seguimiento de las personas que ven su cv. Imagine que el enlace a acortar es el siguiente: https://www.youtube.com/watch?v=EI80NnTGIZs
Obtenga un enlace corto de forma personalizada comprobando si puede utilizar alguna de estas extensiones: larepe o laureyper, y comunique qué puede ver en las estadísticas del mismo.”
Tras la realización de la evaluación, obtenemos varias respuestas y resultados que agrupamos a continuación:
Siguiendo los insights detectados, las propuestas de mejoras serían las siguientes:
Siempre que decido preguntar e iterar algún diseño con alguien descubro nuevos puntos de vista. Creo que puede ser la fase más importante del proceso de diseño, el testear. Ya que la mayoría de diseñadores damos por hecho que estamos haciendo cosas intuitivas. Que están bien organizadas, que se comunican con éxito, pero la realidad no es ésta. Nadie puede llegar a entrar en nuestras cabezas para entender qué queremos representar, pero sí que con técnicas como estas, podemos nosotros como diseñadoras, acercarnos más a esas mentes. Que al fin y al cabo son los que acabarán haciendo uso real diario de aplicaciones, softwares y otros productos. Por lo que me quedo con la siguiente sensación: es más productivo encerrarse en una sala, con papel boli y post-it, y realizar una sesión de cocreación con usuarios finales durante horas, antes que realizar una gran investigación en muchos casos…Creo que el hecho de dibujar, poner en común y probar, una y otra vez, es la mejor manera de acabar dando en el clavo y prestar una solución que de verdad resuelva los problemas de inicio y los que puedan ir surgiendo.
En este caso, hemos podido observar cómo según el perfil que evaluara la aplicación, sugerían un modelo de navegación concreto y otro, sugería otro totalmente opuesto. Para uno era útil el menú de navegación mobile mediante bottom app bar, pero para otro, prefería por costumbre un solo icono menú hamburguesa donde estuviera todo, incluido el perfil. Llegar a un acuerdo entre todos, y hacer pruebas A/B en caso de discusión, es el cometido.
Nielsen, J. (2020) 10 Usability Heuristics for User Interface Design | NNGroup. https://www.nngroup.com/articles/ten-usability-heuristics/
Nielsen, J. (2012) Thinking Aloud: The #1 Usability Tool | NNGroup. https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/
Doody,S. (2019) How to write a UX case study. Inside Design | Invision. https://www.invisionapp.com/inside-design/how-to-write-a-ux-case-study/
Armengol, D., Casacuberta, D., Chacón, J., Garreta, M., Gondomar, R., Mora, A., Mora, J., Membrives, J., Monjo, T., Mor, E., Nieto, J., Zambrano, J. Test con usuarios. Design Toolkit | UOC. http://design-toolkit.uoc.edu/es/test-con-usuarios/
Martín San Román, J.R. (2022). Cuaderno de prototipado | UOC. http://quadern-prototipat.aula.uoc.edu/es/9-2-1-evaluacion-de-la-usabilidad/
Frost, B. (2022) Atomic design | Brad Frost https://bradfrost.com/blog/post/atomic-web-design/
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
A continuación les presento el enlace de mi prototipo con las mejoras realizadas:
Desktop: Enlace
Mobile: Enlace
Adjunto también mi Case study en PDF:
Saludos,
Carlos
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
En este proceso de prototipado, se ha diseñado un acortador de enlaces llamado Shortly.
Esta herramienta, que se trata de una aplicación web, toma como parámetro de entrada una dirección de internet (URL/enlace) y genera una versión más corta de la misma, tal y como se muestra en el siguiente diagrama. Además, se desarrolla para ordenador y móvil, tratándose por tanto de una aplicación «responsive».
Los acortadores de enlaces como el que se ha diseñado tienen 3 funciones principales :
A la hora de definir la herramienta , hay algunos conceptos distintivos que sería interesante desarrollar como base de su universo. De esta forma, se puede definir la personalidad y la seña de identidad de la aplicación que hará que se distinga del resto y permitirá asegurar el reconocimiento por parte de los usuarios. Además, algunos de estos valores serán los que supongan la base a la hora de desarrollar la estética de la misma.
Elegancia – Una estética cuidada y sin sobrecargos, donde la funcionalidad esté por encima de adornos y florituras.
Distinción – Con un uso de colores atípicos, propios y únicos. Colores llamativos y actuales, que a la vez transmitan modernidad.
Simplicidad – Fácil funcionamiento y en armonía con el entorno de la aplicación. Sin funciones escondidas y procedimientos directos.
Confianza – Con el fin de conseguir usuarios fieles al uso del sistema, que elijan la aplicación por encima del resto.
Seguridad – Para usuarios despreocupados sobre posibles virus o problemas con los enlaces.
Profesionalidad – Imagen profesional, confiable, que lleve a pensar en el buen funcionamiento más allá de las web con diseños descuidados o sobrecargadas.
Se han elegido estos conceptos en función de lo que cabe esperar de una página web con esta funcionalidad y de estas características, haciendo un ejercicio de empatía con el usuario.
A partir de los conceptos definidos anteriormente, se ha creado un «moodboard» que servirá como referencia durante los siguientes pasos. Un moodboard se trata de un mapa de inspiración visual que sirve a modo de lluvia de ideas y que prepara la mente para la ideación de un proyecto.
En este caso, se han buscando imágenes que transmitieran modernidad y profesionalidad y se han elegido los colores que las componen para completar el mapa. Dentro de esas imágenes se ha dado prioridad a aquellas de temática relacionada con la informática y lo digital. También se ha priorizado la elección de imágenes donde aparecieran personas de distinto género, edad y raza, con el fin de dotar a la página de una imagen incluyente y universal.
Además, puesto que se tratan de imágenes de uso libre y sin posibilidad de personalización, se han seleccionado los colores que las componen para definir la estética del resto de la página web y crear así una armonía entre los elementos visuales.
Como ya se adelantaba anteriormente, la paleta de colores se ha visto limitada por los colores de las imágenes representativas de la web. En función de eso, se ha decidido que el rosa sea el color principal, mientras que el verde oscuro sea su complementario en el diseño. Además, se han incluido otra serie de grises como colores neutro.
La gama de rosas es el color principal, siendo el #FF4F5A el color más representativo del sistema, en combinación con el verde #385A64 como complementario. El rosa más oscuro se utiliza para funciones detalladas como el hover en los botones, mientras que el rosa más claro ayuda a suavizar el aspecto de algunos elementos y gráficos.
En cuanto a la gama de verdes, ésta complementa la gama de rosas, siendo el verde #385A64 el principal, mientras que el verde oscuro se utiliza como sustitutivo del negro para los textos y para funciones detalladas como el hover en botones.
Por último, la gama de grises se utiliza especialmente para distinguir las distintas áreas del sistema, así como para armonizar la relación entre ambos colores principales y dar claridad a los campos en los que se espera una entrada por parte del usuario.
A nivel de tipografía, se ha elegido la fuente de «Assistant», que se trata de una letra Sans Serif, lo que hace que sea más simple, minimalista y fácil de leer. Además soporta caracteres especiales como tildes, letras propias del español y otros signos. Se utilizan diferentes tamaños y pesos para diferencias los tipos de párrafo y cuerpo, pero no se ha querido incluir otro tipo de fuente complementaria para armonizar la estética y evitar la sobrecarga del sitio. A continuación se muestran las diferentes combinaciones para cada elemento de la página web.
Cabe puntualizar que en el escritorio los títulos comienzan con H1, mientras que en el móvil se fija el H3 como punto de partida, debido a la diferencia de tamaño entre los dispositivos.
En cuanto a los iconos empleados en la página web, especialmente como apoyo visual a la funcionalidad de los botones, se utiliza «Font Awesome 5».
Antes de comenzar a diseñar la aplicación web, es interesante consultar otras webs con funcionalidades iguales o parecidas para ver cómo está diseñada la competencia y poder sacar tanto las cosas mejores de cada una, como ejemplos que no se quieren replicar. Para ello, se ha consultado la web de cuatro sistemas parecidos y anotado tanto lo bueno como lo malo.
Una de las cosas que más destacan positivamente de Cuttly es que la función principal que es la de acortar los enlaces es accesible desde un primer momento a través de su página de inicio. También es interesante la información que ofrece sobre la página web como qué es cuttly y algunas tarjetas ilustrativas que resumen estos conceptos.
Sin embargo, como aspecto negativo se destaca la gran parte de la pantalla que se dedica a la introducción para registrarse o pagar un plan con ellos, que hacen que la atención no se dirija inicialmente a la barra de tareas de acortar.
La web de Bitly en este caso es más limpia que la de Cuttly. Un aspecto positivo es que las imágenes son más representativas que la de Cuttly y más atractivas. En este caso se tira mucho de imágenes e iconos para apoyar el contenido que se expone en texto.
Sin embargo, un aspecto negativo que destaca de la web de Bitly es que es necesario hacer scroll para llegar a la parte donde acortar el enlace, lo que hace que el usuario pierda un poco el foco o incluso desista de la tarea antes de navegar.
Nuevamente en el caso de Onurix se ve positivamente que la barra de acortar enlaces aparezca en el inicio y sea reconocible a primera vista. Esto puede favorecer el uso de los usuarios, especialmente aquellos que entran en el sitio por primera vez y quieren huir de complicaciones o de requisitos de registro e inicio de sesión de otros sitios. Algunas de las imágenes que apoyan las distintas secciones resultan atractivas y descriptivas del sitio.
Sin embargo, en este caso se detecta mucho texto, pese a que se apoya con algunos iconos e incluso se introduce un vídeo. Queda un poco recargado estéticamente. Además, a lo largo de la página de inicio hay algunos botones de llamadas a la acción que, en este caso concreto, se repiten continuamente. Esto puede resultar un poco insistente para el usuario final.
En este último competidor, Goo, se encuentra la página de inicio más minimalista de todas las analizadas hasta ahora. La mayor parte de la pantalla la ocupa un rectángulo blanco que tiene en el centro la barra para acortar los enlaces. No es negativo que muestre únicamente y de forma limpia la función principal, no obstante, el hecho de no ofrecer más información sobre las opciones o sobre el origen de la empresa puede dar lugar a la desconfianza.
Es comprensible que se quiera dedicar la mayor parte de la sección a la función principal, pero queda excesivamente vacío y pobre. En ese primer golpe de vista, podría haberse incluido algo para enganchar al usuario, hacerle confiar y recurrir al sistema cuando lo necesite.
Una vez que se tiene una imagen clara de la competencia y se conocen los puntos fuertes y débiles de cada una de ellas, es un buen momento para comenzar a diseñar la solución. En este caso, puesto que debe ser una web responsive adaptable tanto a dispositivos pequeños como un móvil como a grandes como un ordenador, se definirán dos tipos de rejilla.
Se he elegido una rejilla de 12 columnas, con 24 de gutter y 80 de margen para los dispositivos más grandes, como un portátil con resolución de 1440×1024.
Paralelamente, se ha elegido una rejilla de 6 columnas, con 16 de gutter y 12 de margen para dispositivos pequeños como puede ser un móvil, cuya resolución de referencia es 360×800.
Tras definir las rejillas sobre las que se va a trabajar, ya se está en disposición de definir los activos que compondrán los componentes y la web. Puesto que se trata de un sistema con una funcionalidad sencilla y que se pretende armonizar su estética, la cantidad de elementos atómicos es bastante reducida. No obstante, a partir de esos elementos atómicos se irán definiendo poco a poco elementos cada vez más complejos hasta formar componentes de funciones principales.
A continuación, se muestran botones, campos de texto con validación, opciones de menú y checkboxes para confirmar las normas de uso. Como se puede observar, los botones con fuente más pequeña serían para el breakpoint del móvil, mientras que los otros serían para el ordenador. Por otro lado, alguno de los elementos se encuentra duplicado con diferentes longitudes y formatos en correspondencia con el breakpoint para el que han sido diseñados.
Aparte de los elementos meramente atómicos, también se han diseñado las cajas de texto como punto de entrada al sistema, cards informativos y menús de inicio para ambos dispositivos.
Otro de los elementos básicos importantes es un pop-up con un mensaje de confirmación que sirve para informar al usuario del estado del sistema cuando el cambio o las consecuencias de sus acciones no son tan evidentemente visibles.
También suponen una parte importante del diseño los elementos de las listas, en este caso concreto la forma de mostrar el enlace creado y guardado para trazar estadísticas.
Por último, aunque se trata de elementos más complejos, se han definido también dos tipos de gráficas para la parte de estadísticas. Nuevamente, se incorporan dos dimensiones diferentes para cada uno de los diseños dependiendo del dispositivo en el que se vayan a visualizar.
Se ha decidido no incluir más elementos en esta sección, ya que la fina línea que separa los activos de los componentes es muy difusa. El resto de elementos compuestos a partir de estos y estructuras más complejas se pasarán a expones en el siguiente apartado de la sección.
Tras definir los elementos pequeños más básicos para componer la interfaz del prototipo, se puede pasar a construir partes más complejas a partir de esas piezas ya creadas. Dentro de estos componentes, se destacan principalmente los que componen la página de inicio del sistema.
Entre esos componentes, destacan los de registro e inicio de sesión.
y
Otro componente importante es el que dirige al usuario a estos dos apartados desde la página principal y que no se trata del menú. En este caso, se invita al usuario a explorar las opciones adicionales de estadísticas tras iniciar sesión o crearse una cuenta si no la tiene.
Se ha incluido también un componente con un pequeño resumen de las funcionalidades detalladas que ofrece la función en sí de consultar estadísticas. Además se ha enlazado con un botón de registro para animar al usuario a hacerse una cuenta y disfrutar de este extra.
Como es propio de la mayoría de las páginas web, se ha decidido crear un apartado de ayuda y soporte para los posibles problemas que les puedan surgir a los usuarios. Esto es especialmente importante a la hora de brindarles confianza y seguridad en el proceso, puesto que tienen a quién recurrir en caso de que algo no salga como esperaban.
Por último, para dar unidad a la web y a la vez hacer accesible mucha información que puede resultar de interés en algún momento al usuario, pero a la vez evitar recargar el menú inicial, se ha creado un footer. Ahí además se enlazar las redes sociales de la empresa, algo fundamental hoy en día y que puede ayudar especialmente a la difusión y crecimiento del sistema.
Una vez que se tiene claro el aspecto de la web y los componentes que la van a componer, es hora de pasar a definir la navegación en la web de cara a cumplir una función determinada. Como se comentaba antes, la funcionalidad de esta web se basa principalmente en dos acciones: acortar un enlace y consultar las estadísticas del mismo. Por ese motivo, se han definido dos flujos que cumplen precisamente con el comportamiento de un usuario que quiere explorar ambas.
Estos dos flujos son:
Según estos flujos definidos, se tiene que el prototipo como tal queda de la siguiente forma:
Ordenador:
Móvil:
Ambos flujos en la versión inicial se pueden consultar en los siguientes enlaces:
Una vez que se tiene una primera versión del prototipo con los dos flujos funcionando, éste se ha sometido a una serie de evaluaciones y mejoras a partir de los resultados obtenidos en éstas. Se han realizado un total de dos evaluaciones: una de ellas por una profesional del sector y otra por usuarios seleccionados. En los siguientes apartados se pasará a explicar mejor la metodología de estas evaluaciones, así como los conocimientos obtenidos a partir de ellas.
La primera versión del prototipo fue enviada a una profesional del sector del Prototipado para una primera evaluación. Este análisis consistió en pasar el archivo a la profesional, permitiéndole que interactuara con él de forma libre y sin la vigilancia de la persona responsable del diseño. Durante esta evaluación, la profesional puso foco tanto en el diseño estático como en el diseño de los flujos del prototipo. A continuación se pasan a exponer los descubrimientos que ocurrieron durante este primera análisis.
Una de las primeras cosas que señaló la profesional fue que en la página de inicio del sistema había tres elementos que competían por la atención del usuario, lo que podría hacer que perdiera el foco o incluso que no entendiera el funcionamiento y desistiera tras una mala experiencia.
Otra de las observaciones por parte de la profesional del sector fue que se estaba mostrando el elemento que debía contener el enlace acortado aun cuando no se había pulsado en «acortar» como tal. Éste aparece desde un primer momento, lo que ensucia y complica la imagen inicial de la página, pudiendo llevar incluso a equivocaciones.
Como se explicaba anteriormente, una de las funciones más relevantes del prototipo es consultar las estadísticas de los enlaces acortados. No obstante, en el menú inicial donde se muestra la opción de copiar no se ha incluido nada de esto. Es necesario leer el apartado de «te ayudamos a alzar la voz» para poder saber sobre esta función (consultar imagen anterior).
Otra de las sugerencias que la diseñadora profesional hizo durante la evaluación fue la de agrupar distintas secciones con varios placeholders en una sola mientras ambas se mantuvieran vacías, para evitar duplicidad. También se sugirió la idea de que el título se generara automáticamente por defecto y que fuera posible cambiarlo por el usuario.
Por último, otra de las observaciones fue que en los elementos de la lista de enlaces guardados quizás faltaba contraste, puesto que no llamaban excesivamente la atención del usuario y podrían pasar desapercibidos especialmente si el usuario estaba algo distraído.
Una vez que se recibieron y se procesaron las observaciones de la primera evaluación, se decidió llevar a cabo las mejoras relacionadas, para evitar que condicionaran o fueran un impedimento en la segunda evaluación, es decir, la que se realizaría con usuarios. Por eso, conforme a los conocimientos obtenidos de posibles problemas, se realizaron las siguientes mejoras.
Lo primero de todo, para evitar que hubiera tantos elementos compitiendo por la atención del usuario, se aumentó el contraste del cuadro de texto de entrada al sistema, se ocultó el componente que mostraba el resultado del enlace acortado mientras que no se hubiera acortado uno y se redujo el contraste del componente que anunciaba la opción de consultar estadísticas. Todo esto, se puede consultar en la siguiente imagen.
Respecto a la observación del uso de varios placeholders al tener varias áreas vacías, se ha pasado a sustituir por una sola con un solo placeholder para evitar mucho ruido visual y la posible distracción del usuario, así como la redundancia en los avisos. Además, como se puede ver en este caso, el contraste del apartado donde aparece el resultado del enlace también se ha bajado. Además, en esta versión aparece un título por defecto al acortar el enlace. Este título se puede editar antes de guardar el enlace, pudiendo introducir uno completamente personalizado.
Por último, se mejoró el contraste de los elementos de la lista de enlaces guardados dentro de una cuenta de usuario. De esta forma, es más sencillo para el usuario que su atención se vaya allí al guardar el enlace y pueda distinguir mejor dónde continúa el flujo.
Una vez realizadas todas las mejoras indicadas en la primera evaluación, se puede pasar a realizar una segunda con el fin de encontrar otros posibles problemas y de comprobar a la vez si estas mejoras han sido efectivas.
Con el fin de realizar una segunda evaluación tras un primer análisis de la interfaz por parte de una diseñadora con experiencia, se ha pasado a programar una prueba con usuarios bajo la metodología de “thinking aloud” que, según Nielsen, es “un test en el que se le pide al participante que use un sistema mientras piensa continuamente en voz alta, verbalizando sus pensamientos mientras se mueve por la interfaz de usuario”.
Para ello se han programado tres entrevistas para el día 15 de diciembre entre las 18:00 y las 21:00 de la noche. Se han desarrollado por medio de la aplicación de videollamadas Zoom, habiendo enviado previamente a los participantes los enlaces del prototipo para que los tengan abiertos en su ordenador y facilitar su manejo. La llamada se ha grabado con la aplicación nativa de Windows 10 para la grabación de pantalla y se ha subido a la plataforma de vídeos YouTube para su consulta por parte de todo aquel que quisiera comprobar los datos en bruto de las entrevistas.
A la hora de realizar las entrevistas, se ha seguido un guion aproximado para no olvidar ninguna parte importante, pero tampoco cerrado para favorecer la naturalidad y no encasillar el conocimiento que se puede extraer. Las entrevistas se han compuesto principalmente de seis partes:
Puesto que se está desarrollando el diseño para ordenador y móvil a la vez, se cree interesante poder contar con opiniones sobre ambos diseños. Sin embargo, hacer el mismo procedimiento sería repetitivo y supondría pocos conocimientos más para el estudio. Por esta razón, se ha decidido valorar la estética del móvil en la parte de exploración y comprobar si la función de acortar el enlace es intuitiva a la hora de encontrar el resultado, puesto que está más oculta que en el ordenador. Por otra parte, el diseño de ordenador se ha utilizado para la parte de estadísticas ya que es la funcionalidad más compleja y además se asegura el conocimiento sacado sobre la primera tarea del móvil, ya que es necesario repetirlo para poder seguir adelante con la segunda tarea.
Los datos demográficos básicos de los participantes, así como alguna información extra que pudiera ser de interés se han recogido en la siguiente tabla.
Como se puede observar, se ha intentado elegir a personas de diferentes rangos de edad, género y con distinto manejo de las tecnologías. Esto aporta una visión más global y con puntualizaciones mucho más heterogéneas entre ellas. También se ha prestado atención a su ocupación: alguien cercano a la tecnología (usuaria 2), alguien cercano a la estética (usuario 3) y finalmente alguien alejado de ambos mundos, pero candidato a usar en un determinado momento el sistema (usuario 1).
Pasando a analizar los resultados de las entrevistas de los usuarios, se puede obtener una serie de conclusiones sobre qué cambios son recomendables hacer al prototipo para hacerlo más accesible e intuitivo para los usuarios y mejorar así su usabilidad.
Poniendo en el punto de mira la versión móvil para comenzar y teniendo en cuenta de que en ella se centralizó únicamente la exploración web y la tarea de acortar enlaces, se proponen los siguientes cambios según los resultados de las entrevistas:
Por otra parte, en la versión de ordenador ha sido donde mejor se han podido comprobar los problemas propios de la tarea relacionada con la consulta de estadísticas de los enlaces. Sin embargo, al ser estos asociados con la funcionalidad y la percepción de la misma y no meramente estéticos, se aplicarán también a la versión móvil. Entre esos cambios destacan:
Aplicando los cambios de los resultados obtenidos en las entrevistas a usuarios, se tendrá la versión 3 del prototipo: una versión ya revisada por una persona profesional del sector y con la opinión de los potenciales usuarios, donde se ha limado la usabilidad y se ha hecho más accesible para todos. Se puede dar en este caso por concluido el ciclo de definición-evaluación del prototipo del sistema.
Tras esta segunda evaluación, se pueden obtener nuevas mejoras, así como valorar si las introducidas tras la primera evaluación han servido de ayuda a los usuarios de esta segunda evaluación. Teniendo en cuenta los resultados expuestos anteriormente, se han introducido las siguientes mejoras en los prototipos.
Las mejoras relacionadas con la estética del breakpoint del móvil se pueden observar en la siguiente imagen. En ella, se ha empequeñecido el texto mínimamente y se ha incluido una imagen para apoyar la definición de la aplicación. Además, los iconos de inicio de sesión y de registro han desaparecido y han evolucionado en un menú de hamburguesa. Al pinchar en el menú, ahora aparece no sólo el icono sino también el texto de la función a la que hace referencia. De esta forma es mucho más sencillo navegar y evitar confusiones.
Correspondiente con que muchos usuarios no captaban si estaban iniciando sesión o registrándose, se ha añadido una modificación dentro de la página de inicio de sesión, de forma que enlace más directa y visiblemente con la página de registro. Este cambio se podría haber ignorado puesto que no queda del todo claro si es que los usuarios no entienden dónde están o si lo están obviando al haberles explicado que se trataba de un prototipo que se iba a rellenar solo. Sin embargo, se ha decidido añadir para prevenir posibles errores en caso de que la suposición fuese cierta.
Respecto a la consulta de estadísticas de un enlace, se ha visto que ha sido sin ninguna duda el paso más conflictivo. Por eso, teniendo en cuenta los comentarios de los usuarios durante las entrevistas, se ha realizado una serie de cambios en este procedimiento. Estos cambios pasan a exponerse a continuación.
Se ha ocultado el elemento que contiene el resultado del enlace acortado mientras que no exista un resultado que mostrar. Esto ya se realizó en la mejora anterior en la página de inicio, sin embargo, se había olvidado replicar esa mejora en esta parte. Además, se han recuperado las dos secciones de enlaces y estadísticas, aunque se ha dejado un único placeholder. Aun así, se ha añadido título a cada una de las secciones para que el usuario reconozca fácilmente dónde irá a parar la información una vez que la consulte.
Otra de las mejoras que se ha llevado a cabo ha sido la sustitución del término de «guardar» en el botón bajo la opción de «copiar». Ha pasado a llamarse «estadísticas» para hacer más evidente la funcionalidad que conlleva detrás de su selección y aportando además consistencia con el elemento que se muestra en la página inicial sin haber iniciado sesión en el sistema.
Finalmente, una vez que se presiona el botón de estadísticas, en vez de aparecer el enlace en la lista de abajo y tener que volverlo a clicar para poder consultar las estadísticas, ahora las estadísticas se muestran directamente puesto que la voluntad del usuario es bastante clara al respecto y se ahora así parte del trabajo. Por tanto, tras clicas en «estadísticas», ésta será la página que se muestre directamente.
Esas han sido las mejoras introducidas en el prototipo tras los resultados de las entrevistas con los usuarios. Obviamente, todavía podrían quedar cosas que refinar, pero sin duda esto es un perfecto punto de partida para los desarrolladores.
Los prototipos finales se pueden consultar en los siguientes enlaces:
Como se ha podido ver a lo largo del Caso de Estudio, a la hora de diseñar un prototipo es importante realizar un proceso de diseño detallado, con sus fases de definición, evaluación y mejora. Si durante ese proceso de diseño además se es sistemático y correcto a la hora de desarrollar los ficheros máster, los cambios posteriores serán mucho más fáciles de implementar. Además, el hecho de partir definiendo los activos y después los componentes es especialmente interesante a la hora de poder reutilizar elementos que comparten varios componentes a la vez.
Por otro lado, una vez que se tiene una primera versión final del prototipo, es clave poder realizar una evaluación del mismo. Y si, como en este caso, pueden ser dos de diferente índole, aún mejor. El hecho de haber implementado las mejoras recomendadas por la diseñadora profesional antes de la segunda evaluación ha sido sin duda todo un acierto, puesto que muchas de ellas podrían haber condicionado de forma diferente la experiencia de los usuarios de las entrevistas. Además, más allá de la teoría del diseño y del prototipado, ha resultado interesante ver cómo los usuarios perciben las cosas de forma diferente entre ellos o a cómo las puede percibir alguien que es parte del mundo del diseño.
Aprender a evaluar y rectificar los puntos débiles del prototipo no sólo nos evita cambios más costosos y complejos en el futuro, sino que crea una base fiable y con gran potencial para comenzar a trabajar junto con el equipo de desarrollo.
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
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.
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
En este caso, al vivir en una zona rural alejada de edificios altos, se ha optado por la opción alternativa de la lavadora, ya que es difícil encontrar ascensores cercanos. Se trata de una lavadora de la marca Candy, modelo CSS14102D3-S, situado en una residencia familiar. En ella podemos encontrar, como viene siendo común en todas las lavadoras, el cajetín para detergentes en la parte izquierda, y a continuación el panel de control, junto con la ruleta de selección de programas.
En este caso, esta línea de productos, posee una aplicación móvil, Candy Simply-Fi, que muestra información extra y ayuda a los usuarios a realizar las tareas de forma correcta. En el caso de la lavadora, ayuda guiando al usuario con el lavado de prendas. A continuación, la representación del modelo de sistema actual, utilizando la herramienta figma para crear dicha réplica:
En este enlace, podrás encontrar las tres entrevistas realizadas: https://loom.com/share/folder/f400d5cdef3243aeb0dd85d85404b84f
Para no complicar mucho la tarea, se ha optado por representar dos de los escenarios dados durante las entrevistas:
El panel de control o display propuesto, consta de la combinación de botones con dos pantallas LCDs integradas. Principalmente, se muestra un botón por cada opción o programa importante que hemos podido observar tras llevar a cabo el breve desk research y realizar las entrevistas. Cada botón, tiene asociado sus valores correspondientes, ya sea detectar carga, temperatura del agua, cantidad de la misma, intensidad o duración. Además, también se encuentran los botones propios del control de ciclo: play/pause, atrás, adelante, stop y vaciado.
A nivel gráfico, se ha optado por utilizar una tipografía sans serif, similar a una futura, por su carácter más amigable y redonda. Hablamos de la fuente Quicksand, disponible de forma libre en google font y que posee cinco variables, lo que permite jugar con la jerarquía de peso cognitivo. Si hablamos de iconos, la mayoría han sido de creación propia, utilizando el mismo figma y la opción flatten para su vectorización, aunque hemos tomado inspiración de los iconos ya existentes en el sistema actual y los proporcionados por material design de google.
Para más información, puedes consultar el siguiente archivo de memoria:
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
A continuación se adjunta la memoria del caso de estudio de la lavadora Edesa de 4L, modelo 104. Se ha realizado este electrodoméstico por vivir en un pueblo pequeño y no tener acceso a ningún ascensor.
En prototipo inicial, medio y la propuesta final se pueden consultar aquí.
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
Hola a tod@s!
A continuación les presento mi propuesta de diseño:
Dossier explicativo:
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.
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.
Debatecontribution 0en 02 Diseño y sistematización de una interfaz gráfica
No hay comentarios.
Lo siento, debes estar conectado para publicar un comentario.