1. Introducción

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 :

• Permiten ahorrar caracteres en redes sociales que limitan la longitud de los mensajes , de forma que se disponga de más espacio para el mensaje restante.
• Permiten generar enlaces más fáciles de recordar al ser más cortos.
• Permiten consultar estadísticas de uso del enlace, como cuántas personas han entrado en el enlace y desde dónde.

 

---

2. Diseño del universo del producto

2.1 Conceptos

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.

2.2 Mood Board

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.

 

2.3 Colores

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.

 

2.4 Tipografía

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.

 

2.5 Iconos

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».

---

3. Proceso de diseño

3.1 Estudio de la competencia

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.

3.1.1 Cuttly

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.

 

3.1.2 Bitly

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.

 

3.1.3 Onurix

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.

 

3.1.4 Goo

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.

 

3.2 Definición de las rejillas responsive

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.

3.3 Definición de activos

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.

3.4 Creación de componentes principales

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.

 

3.5 Diseño de flujos

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:

• El flujo principal deberá permitir a los usuarios acortar un enlace. Para ello, será necesario introducir un enlace como parámetro de entrada, y se obtendrá un enlace acortado que seguirá el formato «short.ly/<enlace acortado>».
• El segundo flujo consistirá en consultar las estadísticas de uso de un enlace generado mediante la herramienta Shortly. Para ello se ha desarrollado la pantalla de estadísticas en base a los wireframes proporcionados por el equipo aquí: https://www.figma.com/proto/JNxbiIdeCAonM3QUWsvNip/Shortly-Wireframes?page-id=0%3A1&node-id=1%3A2&viewport=634%2C366%2C1.11&scaling=scale-down Dado que esto es únicamente la apariencia de la página de estadísticas, se ha determinado que para llegar a ella será necesario registrarse o iniciar sesión. Una vez dentro del sistema mediante una cuenta, se acortará el enlace, se le proporcionará un título y se guardará. Tras guardarse, se podrá pinchar el enlace y consultar las estadísticas.

 

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:

• Ordenador: https://www.figma.com/proto/kKD9rCnky2rcvIlAzHvrGm/Shortly—Clara-PEC-2?page-id=8%3A13&node-id=41%3A834&viewport=311%2C742%2C0.07&scaling=scale-down&starting-point-node-id=41%3A834&show-proto-sidebar=1
• Móvil: https://www.figma.com/proto/kKD9rCnky2rcvIlAzHvrGm/Shortly—Clara-PEC-2?page-id=8%3A14&node-id=45%3A4507&viewport=697%2C313%2C0.08&scaling=scale-down&starting-point-node-id=45%3A4507&show-proto-sidebar=1

 

---

 

4. Evaluaciones y mejoras

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.

4.1 Primera evaluación: Profesional del sector.

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.

4.1.1 Competencia de elementos por atención en página de inicio

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.

 

4.1.2 Elementos inútiles mostrados que distraen

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.

4.1.3 Falta de llamada a la acción sobre estadísticas

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).

 

4.1.4 Varios placeholders para hueco vacío

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.

4.1.5 Falta de contraste y llamada de atención

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.

 

4.2 Mejoras tras primera evaluación

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.

 

4.3 Segunda evaluación: Usuarios.

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”.

4.3.1 Metodología

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:

1. Introducción: Se da la bienvenida al participante, se le informa de que la sesión va a ser grabada y se comprueba que tiene los prototipos abiertos y que se escucha y se ve bien todo por ambas partes.
2. Presentación: Se comienza a grabar y se pide a la persona que se presente con datos básicos demográficos, así como su ocupación y su nivel en cuanto a manejo de tecnologías.
3. Exploración: Se pide al usuario que explore la página de inicio sin interactuar aún con el prototipo, con el fin de que cuente brevemente cómo ha sido la primera impresión: si le agrada a la vista, si le parece de verdad, pensamientos, emociones, etc.
4. Acortar enlace: Se invita al usuario a interactuar con el prototipo para conseguir su primera tarea que es acortar un enlace. Se deja claro que, al tratarse de un prototipo, las funciones de copiar y pegar u otras cosas funcionan automáticamente mediante clic.
5. Consultar estadísticas: Se reta al usuario a consultar las estadísticas de un enlace acortado, incluyendo inevitablemente el proceso de inicio de sesión o registro.
6. Reflexión final: Se pide al usuario que reflexione sobre el proceso y añada lo que crea que pueda ser relevante de cara a mejorar el diseño de la página web. Por último, se agradece su participación y se para la grabación.

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.

 

4.3.2 Participantes

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).

 

4.3.3 Resultados resumidos

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:

• Página de inicio: Se ha dado la situación en la que uno de los participantes consideraba que no era atractiva e incluso que le abrumaba tanta cantidad de texto y en letras tan grandes. Por ese motivo, se ha decidido meter una imagen ilustrativa de la aplicación y reducir el tamaño de las letras o incluso eliminarlas.
• Menú del móvil: Ninguno de los participantes ha sabido intuir el verdadero significado de los iconos del menú del móvil, llegándoles incluso a confundir con funciones que nada tenían que ver. Por esta razón, se cambiarán los iconos a algo más representativo o incluso a texto, donde no quede hueco para la imaginación.

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:

• Página de inicio de sesión: Durante la simulación de la web, únicamente la Usuaria 2 se daba cuenta de estar en la página de iniciar sesión y no de registrarse, por lo que se dirigía a registrarse al ser consciente de no tener una cuenta. Los otros dos usuarios, por su parte, se limitaban a rellenar los datos. Este comportamiento pese a poder tratarse meramente de una forma de interpretarlo al saber que es un prototipo y que tendrían acceso a la funcionalidad, ha puesto en manifiesto la idea de añadir un enlace a “registrarse” dentro de la página de iniciar sesión para facilitar la navegación.

• Proceso de ver estadísticas: A la hora de consultar las estadísticas de un enlace, únicamente el Usuario 1 lo hizo sin dudar. Por su parte, la Usuaria 2 no tenía muy claro si al darle a “guardar” aparecerían las estadísticas por alguna parte. Y finalmente, el Usuario 3 directamente no supo ver que el enlace se había guardado, por lo que pretendía cambiar completamente de página para consultarlas. De esto se deducen algunos cambios potenciales en el proceso:
  • Añadir “ver estadísticas” como botón en algún sitio: Una de las cosas que confundió a la Usuaria 2 fue no encontrar un botón para consultar estadísticas como sí ocurría en la página inicial. Por eso, se propone añadir este botón en esta segunda página también.
  • Quitar el botón de guardar y poner otro nombre: Otro de los factores que confundió al Usuario 3 fue la terminología de “guardar” para el enlace, pensando que podría tratarse de guardar en local la URL. Se propone en este caso cambiar la terminología.
  • Quitar que el título se genere automáticamente u ofrecer forma de editar el título después de eso, donde sea evidente que puede hacerse: Ninguno de los usuarios intuía que se podía editar el título, excepto cuando se les ha preguntado expresamente si podían hacerlo. El hecho de que salga uno por defecto les “libra de responsabilidad” en ese sentido. En este caso, habría que sopesar si es lo que se pretende o si, por el contrario, sería mejor quitar esta funcionalidad que se introdujo en la segunda versión.
  • Añadir título a enlaces guardados y estadísticas: Pero, sin duda, el problema más grande que se ha encontrado en las entrevistas es el hecho de que el Usuario 3 no supiera reaccionar al guardar el enlace y no identificara que lo tenía accesible en la parte de abajo. Por este motivo, se propone añadir un título más visible que el placeholder actual y que se identifique de forma más clara en qué lugar se podrá visualizar cada cosa.

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.

 

4.4 Mejoras tras segunda evaluación

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.

 

4.4.1 Mejoras versión móvil

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.

 

4.4.2 Mejoras ambas versiones

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:

• Ordenador: https://www.figma.com/proto/dLKTfPXah4iPHWQ6IdtSy7/Shortly—Clara—PEC-4?page-id=342%3A1901&node-id=342%3A2145&viewport=603%2C942%2C0.16&scaling=scale-down&starting-point-node-id=342%3A2145
• Móvil: https://www.figma.com/proto/dLKTfPXah4iPHWQ6IdtSy7/Shortly—Clara—PEC-4?page-id=342%3A3261&node-id=342%3A3429&viewport=552%2C1283%2C0.25&scaling=scale-down&starting-point-node-id=342%3A3429

 

5. Conclusiones

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.

 

 

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í.

La primera práctica de la asignatura de Prototipado, consistía en la deconstrucción de una interfaz gráfica. Es decir, se debía seguir el orden contrario: creando un prototipo a partir de una interfaz de una página web ya existente. En este caso, se ha elegido como ejemplo Airbnb.

Airbnb es una compañía que ofrece una plataforma digital dedicada a la oferta de alojamientos a particulares y turísticos (alquiler vacacional) mediante la cual los anfitriones pueden publicitar y contratar el arriendo de sus propiedades con sus huéspedes; anfitriones y huéspedes pueden valorarse mutuamente, como referencia para futuros usuarios.

Sin embargo, dada la extensión de la página web, se ha centrado el prototipo en cuatro páginas clave:

• página home, incluyendo el sistema de búsqueda (destino, llegada, salida, viajeros).
• página de resultados de búsqueda, incluyendo los filtros.
• página de un alojamiento concreto, con galería de imágenes/carrusel incluida (no es necesario dotar de interacción)
• página «Confirmar y pagar»

Todo ello para un total de 3 breakpoints: ordenador, tablet en horizontal y móvil.

 

El desarrollo ha sido:

1. Analizar la web anotando los diferentes tipos de componentes que tenían y los estilos que se habían seguido para crear cada uno de ellos.
2. Crear un UI kit en Figma para poder reutilizar esos estilos a la hora de crear los componentes.
3. Crear componentes en Figma para poderlos adaptar y reutilizar en las distintas páginas y vistas.
4. Crear el prototipo para cada uno de los breakpoints.
5. Introducir interactividad al prototipo para poder simular el comportamiento normal de la web.

 

De izquierda a derecha se ejemplifica la imagen general de cada parte, siendo: UI kit, componentes, prototipo y prototipo con flujo de interacción.

A continuación se dejan algunas de las partes mencionadas anteriormente. No obstante, el prototipo se puede consultar utilizando el siguiente enlace:

https://www.figma.com/file/lhp5UB10Po7yGIR01T0MXj/Airbnbn_Clara?node-id=1%3A3

Por otro lado, el flujo principal del breakpoint principal (en este caso ordenador), ha quedado explicado en el vídeo que se muestra a continuación:

 

 

Ha resultado de especial interés aprender a utilizar el programa de Figma y ver la cantidad de detalles y de estilos diferentes que posee la página. No obstante, resulta de especial interés ver cómo se puede simular una web sin tener absolutamente nada programado y que los usuarios puedan verificar el diseño antes de pasar a la producción en cuanto a implementación.

Sin duda, una forma idónea de validar y verificar de la manera más tangible posible.

 

 

Tras analizar los resultados obtenidos en el formulario por parte de usuarios de apps de videocomunicación durante sus clases de alemán, se ha creado un Storyboard intentando incluir las principales sensaciones o sentimientos expresados por los participantes con el fin de establecer un escenario base sobre el que trabajar en el diseño centrado en el usuario de una app de videocomunicación. A continuación, se puede consultar.

Una vez definido el escenario base, se ha pasado a diseñar un primer boceto de la aplicación. Para ello hemos tenido en cuenta los problemas que los participantes admitieron encontrar durante su experiencia en clases online de alemán, así como las sugerencias que propusieron y las aplicaciones externas que se veían obligados a utilizar debido a la falta de funcionalidad de las aplicaciones existentes en el mercado actualmente.

La propuesta de valor se ha centrado principalmente en:

• Un calendario inicial para organizar las reuniones.
• El cambio de visualización de los compañeros y el profesor.
• La deshabilitación de las notificaciones externas a la aplicación para facilitar la concentración y evitar distracciones.
• La búsqueda eficiente de contenido tanto en chat como en archivos para una fácil encontrabilidad de la información.
• La posibilidad de editar y trabajar conjuntamente en ficheros de forma simultánea a la hora de corregir ejercicios conjuntos, por ejemplo.
• La opción de pedir turno de palabra tanto pulsando un botón como levantando la mano y que la IA capte el mensaje y se lo transmita al moderador o profesor.
• Las reacciones instantáneas que se ejecutan automáticamente al detectar la IA algún gesto como sonrisas, aplausos, etc. con el fin de evitar la pereza y poder facilitar la comunicación y el apoyo entre los alumnos de la clase.

 

 

 

Sin duda, hay algunas otras cosas que se podrían mejorar o incluir. Sin embargo, en este primer diseño se ha centrado la atención en las mejoras que se podrían incluir, más que en cómo mejorar lo ya existente en otras aplicaciones. Por ejemplo, se expone el caso de la pizarra virtual en la que una IA convertiría también los esquemas mal escritos del profesor en texto cuando sea necesario y tenga soporte de formas por defecto para facilitar la legibilidad de los apuntes.

De esta forma, se pretende que la aplicación mejore la experiencia teniendo en cuenta tanto las facilidades de hacerlo online como los elementos que los usuarios echaban de menos de la categoría presencial de la educación presencial.

Se conoce como diseño especulativo la manifestación por la fascinación escéptica por la tecnología que se lleva a cabo mediante el planteamiento de preguntas y la creación de escenarios que definan las posibilidades para prepararnos para retos inconvenientes y facilitar un camino al futuro más deseable y responsable. A continuación se verá cómo se aplica esa base para realizar un diseño especulativo a partir de un objeto físico cotidiano no tecnológico.

El este caso se ha elegido como objeto cotidiano una gorra. Así que descontextualizando e imaginando que es la primera vez que se ve este objeto, se podría definir de la siguiente manera:

Objeto de tela con forma redonda, que posee una visera y un cierre en los extremos opuestos.

Al ser un objeto abierto y relativamente pequeño se descartan algunas ideas como que sirva de almacenaje, funda de balón, etc. Sin embargo, sí que se puede deducir su funcionalidad analizando sus affordances, puesto que se trata de un objeto bastante simple:

• Es de tela, por lo que podría ser una prenda de vestir.
• Tiene forma redonda, por lo que podría ser para la cabeza.
• Tiene una visera alargada que podría proteger los ojos.
• Tiene un cierre en el lado opuesto a la visera que podría servir para ajustarla. Aunque existan cierres de varios tipos como snapback (la tira de plástico con puntitos), hebilla o velcro, en todos los casos se intuye que son mecanismos de ajuste.

 

No obstante, dependiendo de la función que se le quiera dar, se puede ver usada en escenarios muy diferentes.

• Como accesorio de ropa con fines estéticos: gorras conjuntadas con la ropa, sin finalidad alguna más allá de dar estilo y que puede variar su forma de uso como poner la visera hacia un lado o hacia atrás. El escenario en este caso podría ser cualquiera: en clase, en el bar, en una celebración, etc.
• Como herramienta de protección solar: formando parte de algún uniforme o como accesorio de ropa especialmente si la persona va a estar en el exterior y hace calor. La gorra evita que el sol dé directamente en la cabeza y la visera protege los ojos de la luz para una mejor visión.
• Con otros usos alternativos: como recaudar dinero después de una actuación en la calle, identificarse estéticamente con alguna banda urbana en concreto, pasar desapercibido y hacer más difícil que te reconozcan, o incluso como proteger los ojos de posibles golpes al ir de aceituna.

Sin embargo, no deja de ser una pieza de tela cuyas alternativas, a menos que se le añado algo de tecnología, son bastante limitadas. Pero, ¿qué pasa si se le añade tecnología a una gorra? ¿Existe alguna posibilidad de que nos sirva para comunicarnos de manera no presencial? Y mejor aún, ¿también no verbal?

Una de las principales ventajas que hacen de la gorra un objeto especialmente interesante es su continuo contacto con la cabeza. En la cabeza está el cerebro y el cerebro es realmente como el ordenador de nuestro cuerpo, por donde todo pasa y donde todo se procesa: emociones, sentimientos, memoria, movimientos, impulsos, etc. Esto hace que prácticamente toda la funcionalidad del cerebro esté al alcance, aunque sea de manera limitada.

Teniendo en cuenta esa ventaja que ofrece el objeto, la atención se centrará en cómo se puede usar esa información del cerebro para brindar la oportunidad de forzar un cambio social que mejore el futuro de las personas. Y si pensamos en futuro, irremediablemente pensamos en salud, que es lo que suele truncar esos planes a largo plazo. Además, si pensamos en salud y lo juntamos con el hecho de que la gorra se ponga en la cabeza, irremediablemente saltará la alarma de «salud mental«.

En los tiempos que corren, la salud mental ha tomado especial importancia por el ritmo de vida que llevamos y el modelo de consumo y producción en el que centramos nuestras principales actividades. Además, la pandemia ha hecho que estos números aumenten. De acuerdo a cifras oficiales, en España se produjeron en 2021 un total de 3941 suicidios. Esto es una media de 11 suicidios diarios. Además, según la OMS, en España existirían unos 20 intentos por cada suicidio. Eso significa que en un año podrían producirse en torno a 80.000 intentos de suicidio al año en España y que entre dos y cuatro millones de personas posean ideación suicida a lo largo de su vida.

Juntando estos datos con las posibilidades que ofrece una gorra al incorporarle tecnología, se ha llegado al diseño de MoodCap:

 

Por supuesto no es un diseño perfecto y se le podrían hacer cientos de modificaciones. Sin embargo, plantea un debate muy interesante sobre cómo la tecnología puede ayudar en la prevención del suicidio.

Dado que en el mercado actual está prácticamente todo inventado, se pueden comparar sistemas parecidos al que se pretende implementar para tener referencias de cómo se llevan a cabo las principales funciones en algunas webs ya conocidas. De esta forma se puede analizar si el sistema objetivo se parece a lo que ya existe o, por el contrario, no sigue el estándar ya establecido y se diferencia de otras aplicaciones.

Para ello se han seleccionado dos festivales con página web y opción de compra de entradas. Se ha establecido un escenario estándar para simular el comportamiento de un usuario. En este escenario el usuario realizar un total de tres acciones siempre que sea posible: primero consulta la programación del festival, después adquiere la entrada que más le interesa y finalmente comprueba que la entrada se ha adquirido de forma correcta.

Los dos festivales elegidos son el Primavera Sound y el Mad Cool Festival, de los que se hará una breve introducción a continuación, incluyendo los enlaces pertinentes.

Primavera Sound

Primavera Sound es un festival de música que se celebra entre finales de mayo y principios de junio en Barcelona. Su primera edición tuvo lugar en el 2001 en el Pueblo Español y desde el 2005 tiene su sede en el Parque del Fórum, un recinto más grande y al lado del mar.

https://www.primaverasound.com/es

Mad Cool Festival

Mad Cool es un festival de música que se realiza en Madrid desde el año 2016. El arte, la moda, la gastronomía y el turismo se unen eclécticamente en este festival. La última edición, del año 2020, fue cancelada debido a la pandemia del COVID-19.

https://madcoolfestival.es/

 

COMPARATIVA HEURÍSTICA DE NIELSEN

Basándonos en los Principios Heurísticos de Nielsen, podemos evaluar ambas webs teniendo en cuenta si cumplen con las directrices o no. Posteriormente a la tabla, se incluirá una pequeña reflexión de por qué se ha llegado a la conclusión de que las webs cumplen o no con cada uno de esos principios.

Justificación de la tabla de evaluación heurística según Nielsen

 

A continuación, se pasará a exponer el por qué se ha considerado que cada sistema cumple o no con los diez principios establecidos por Nielsen.

• Visibilidad: Ninguno de los sistemas hace uso de las conocidas “migas de pan”, ni muestran barras de progreso o indicadores de carga, por lo que el usuario no conoce en muchas ocasiones el estado del sistema.
• Coincidencia: Para la información de la planificación, ambos sistemas hacen uso del diseño del cartel del festival como si fuese en papel. Además, utilizan iconos parecidos a las entradas para indicar el término.
• Control y libertad: En el caso del Primavera Sound sí que es fácil retroceder o saltar entre varias opciones del menú, sin embargo, en el Mad Cool es necesario terminar muchos procedimientos o simplemente incluso cerrar la página puesto que el menú principal deja de ser visible.
• Consistencia y estándares: No siguen ningún tipo de consistencia especialmente visual entre muchas de sus opciones del menú, especialmente porque ambas implican la redirección a otros sistemas de terceros, lo que puede hacer al usuario desconfiar.
• Prevención: En ambos casos se previene al usuario de realizar una compra indeseada permitiéndole siempre comprobar los datos y haciendo inaccesibles las opciones que no están disponibles para evitar confusión.
• Reconocer en lugar de recordar: Mucha de la información está puesta como imagen y no como texto, lo que hace que el usuario tenga que recordar parte de la información. También ocurre con algunos códigos para las entradas.
• Flexibilidad y eficiencia: Sorprendentemente, especialmente si tenemos en cuenta la envergadura de ambos festivales, las webs no son tan eficientes y la navegación en muchas ocasiones se hace extraña y tediosa.
• Estética y diseño: La estética se rompe especialmente al redirigir a sitios de terceros. Además incluir el cartel como una imagen plana no lo hace especialmente accesible ni adaptable a diferentes dispositivos.
• Ayuda al usuario con errores: En el Primavera Sound es mucho más fácil cometer errores sin darte cuenta puesto que no se indica en ningún momento que los pasos a seguir son erróneos. Sin embargo, en la página de Mad Cool hacen incluso uso de memes y de humor musical para indicar que algo no ha ido bien. Por ejemplo, una foto de Justin Bieber diciendo “Is it too late now to say sorry?” al acceder a una página que no existe.
• Ayuda y documentación: Algo especialmente sorprendente es el hecho de que ninguna de las dos ofrezca la opción de ayuda o documentación sobre el uso del sistema. Si bien es cierto que ambas incluyen información y preguntas frecuentes sobre el festival, ninguna de ellas cubre los aspectos a nivel técnico que puedan surgirle al usuario final.

 

Además, como se observa en los diagramas de flujo, tienen muchos pasos poco intuitivos como que la programación esté sólo accesible desde la página principal o incluso que la compra de entradas sea una opción difícil de encontrar, cuando es precisamente el principal objetivo de negocio.

Por otro lado, dada la limitada funcionalidad de ambos sistemas, sería complicado extraer conclusiones para el sistema que se está diseñando, salvo la idea de incluir en la página principal botones de acción a aquellas tareas que más interesen, es decir, a “ver programación” y “comprar entradas”.

 

 

Con el fin de poder clarificar el resultado obtenido del card-sorting y cómo ha debido evolucionar la arquitectura de la información según estos datos, se ha pasado a la realización de un árbol de contenido. ­Esta estructura se muestra a continuación.

Se han realizado los siguientes cambios a la arquitectura de la información:

1. Se ha sustituido «Programación» por «Actuaciones».
2. La «Compra de entradas» ha pasado a «Entradas» en vez de tener que acceder primero a la actuación para la que se quieren adquirir los boletos.
3. La «Gestión de comentarios» ha pasado de ser algo único del Artista, a ser también parte del rol de Gestor.
4. El descuento en las entradas para el artista ha pasado de ser parte del perfil del artista, a ser una opción en el proceso de compra de las entradas del perfil de espectador.

Con estos cambios se pretende hacer la navegación en la información más accesible e intuitiva para el usuario. El resultado final sería éste: