La historia de una función: “Ver mis facturas”

Ubuntu junio 10, 2021

En esta publicación de blog, haré una inmersión profunda en el proceso de diseño de una pequeña función en ubuntu.com, desde la necesidad original, pasando por la fase de diseño hasta que se entregue a la ingeniería. Tiene la intención de brindarle una buena descripción general de alto nivel de cómo hacemos el diseño de la experiencia del usuario (UX) en Canonical en una pequeña función como esta.

Fondo

Nuestros clientes pueden pagar sus suscripciones a Ubuntu Advantage anualmente o mensualmente, pero en este momento solo reciben una factura por correo electrónico. Esto está bien para un MVP, pero no es una experiencia de usuario muy completa.

Queremos permitir que los clientes vean una lista de sus facturas, las descarguen y administren sus métodos de pago.

Este es solo un elemento pequeño en una hoja de ruta ajetreada, por lo que debemos ser eficientes y producir una gran solución en solo un par de semanas.

Investigación de usuarios

Gracias a nuestro Grupo de entrevista de usuario tenemos una comunidad próspera de cientos de clientes que están listos y dispuestos a participar en entrevistas con los usuarios (puede Únete al grupo si estás interesado).

Realizamos entrevistas de usuarios con un grupo diverso de usuarios de Ubuntu, que incluyen;

  • Un administrador de sistemas en una importante universidad
  • Un director de TI a nivel de junta responsable del soporte
  • Co-fundador de una empresa de tecnología especializada
  • Un profesional de TI con menos experiencia que dirige una agencia multicliente

A partir de esto, pudimos aprender mucho sobre las diversas razones para comprar Ubuntu Advantage y cómo a nuestros clientes les gusta comprar y consumir el servicio.

Algunas de nuestras conclusiones clave de esta investigación son;

  1. “Pago con mi propia tarjeta por algunas máquinas y necesito obtener una factura para poder pasarla a Finanzas”.
  2. “Admitimos una gran cantidad de máquinas, por lo que prefiero que me facturen un año de soporte a la vez en lugar de mes a mes”.
  3. “A veces me olvido de presentar las facturas y buscarlas en mi correo es una molestia”.

Toda una información realmente útil que podemos incorporar a nuestro diseño y validar las decisiones de diseño que estamos tomando.

Historias de usuarios y características

Basándonos en nuestra investigación, las mejores prácticas y nuestro conocimiento del producto, podemos construir una lista simple de historias de usuarios en el formato:

“Como un [type of user] yo quiero [do something] así que yo puedo [achieve a goal or complete a task]”.

Como ejemplo, según nuestra investigación, sabíamos que los usuarios querían un acceso fácil y directo a las facturas, por lo que deberíamos agregar una historia para esto.

Este es un método UX de larga data que ayuda a los diseñadores a obtener una imagen completa de las necesidades de los usuarios para una función. Es posible que no capturemos todo en esta primera versión, pero debemos estar seguros de haber cumplido con las necesidades expresadas en nuestra fase de investigación, así como con las necesidades comerciales de las que tengamos conocimiento.

Arriba: un conjunto básico de historias de usuarios para esta función.

Luego, especificamos y asignamos estos casos de uso a las características requeridas. Esta es una buena técnica para asegurarnos de que no nos hemos perdido nada; una necesidad no satisfecha del usuario en el lado izquierdo o una característica que no es realmente necesaria en el lado derecho.

Nuevamente en nuestro ejemplo, podríamos ofrecer a los usuarios una descarga directa con un clic de un PDF de cada factura para completar la historia del usuario.

Arriba: mapeo de historias de usuarios en funciones.

Enlace API

En este punto, tenemos algunas ideas claras de las características que debemos presentar a nuestros usuarios.

El front-end (la interfaz de usuario que ve en el navegador) se basa en el back-end para proporcionar sus datos, que vienen a través de una API. Solo podemos ofrecer al cliente una experiencia que se puede entregar a través de nuestra API compatible, por lo que ahora es el momento de hablar con nuestro equipo de ingeniería y verificar que lo que tenemos en mente sea posible.

En este caso, nuestra API admitió obtener el valor en dólares individual de una factura cuando se solicitó la lista de facturas de usuarios, el monto en dólares no se incluyó. Esto significaría que la interfaz tendría que iterar a través de las facturas, lo cual es lento y consume muchos recursos.

En cambio, nuestro equipo de backend tomó un problema para enriquecer la respuesta de la API con el monto en dólares de cada factura en la lista.

Si nos hubiéramos saltado este paso, habríamos terminado con una experiencia de usuario mucho peor o habríamos creado algún trabajo de última hora para la ingeniería, los cuales son resultados indeseables.

El diseño y la ingeniería de la experiencia tienen como objetivo trabajar en estrecha colaboración para ofrecer los mejores resultados posibles a nuestros clientes.

Wireframes

Los wireframes son diseños de página muy toscos que intentan mostrar cómo se verán las vistas de la aplicación, ¡sin la distracción de hacer que se vean bien!

Los wireframes se crean rápidamente y permiten a los diseñadores e ingenieros visuales comprender las intenciones de diseño de UX para una función.

En los ejemplos a continuación, mostramos tanto un “arquetipo”, cómo nos gustaría que se vea la vista eventualmente, y un “MVP”, un Producto mínimo viable que creemos que es la funcionalidad mínima que podemos lanzar y aún así ser de utilidad para nuestros clientes.

Este enfoque permite a nuestro equipo comprender no solo el diseño de esta iteración, sino hacia dónde nos dirigimos en el futuro, para que puedan tomar mejores decisiones sobre su trabajo.

Arriba: el ‘arquetipo’ de esta vista.

Arriba: la versión ‘MVP’ de la vista.

Review de UX Peer

¡Nunca trabajamos solos! Creemos que nuestro mejor trabajo proviene de la colaboración, por lo que todo nuestro trabajo es revisado por nuestros compañeros para asegurarnos de que no nos hemos perdido cosas y para que se consideren otras perspectivas.

No siempre aceptará todos los cambios y propuestas que le sugieran sus compañeros de equipo, pero a menudo habrá uno o dos “¡ajá!” momentos en los que una nueva perspectiva desbloquea algo en lo que estabas atrapado.

Arriba: una sugerencia útil de una revisión por pares.

Diseño visual

El paso final antes de entregar nuestro trabajo a los ingenieros de front-end es la etapa de diseño visual. Trabajando con Vanilla Framework, nuestro Diseñador Visual Senior tomará los wireframes básicos y los transformará en maquetas simples, elegantes y de alta fidelidad de las páginas.

Pensar en la jerarquía de la información, la tipografía y ceñirse a los patrones dentro del Marco de vainilla, se asegurarán de que la función sea utilizable y coherente con el resto del producto.

Arriba: una maqueta de alta fidelidad de la vista, lista para ingeniería.

Durante la etapa de producción, el diseñador ayudará al ingeniero de front-end en cualquier problema / restricción y revisará el proyecto desarrollado asegurándose de que todos los componentes visuales y técnicos se muestren y funcionen correctamente.

Y eso es todo para esta inmersión profunda. Puedes ver más de nuestro trabajo en Instagram @ubuntudesigners, Síganos en Twitter @ubuntudesigners – y no te olvides de comprobar posiciones abiertas si deseas unirse a nuestro equipo.