Cómo montar un proceso de diseño de producto (del requerimiento al código).
“Usa lo que se adapte a tus necesidades y te de resultados”.
En el diseño de producto y hablando estrictamente del binomio funcional/visual en Audiense Engineering el primer factor es el que debe siempre imperar sobre el segundo. Puedo asegurar que cualquier diseñador de producto ya sabe que diseñar para satisfacer únicamente el aspecto visual no es necesariamente lo mejor que se pueda hacer. Una funcionalidad que vaya adelante como la seda acompañada de un aspecto visual agradable y con los efectos (sean animaciones o micro-interacciones) justos genera una emoción de satisfacción única en nuestros usuarios. El balance errado de cualquiera de estos componentes provoca un bajón en la experiencia de uso que no tiene por qué darse.
Para llegar a definir el requerimiento de diseño y su flujo, previamente se hace una investigación de nuestros usuarios, en Audiense tenemos dos tipos: el cliente externo B2B y el interno, que son nuestros compañeros de customer success y support.
Cuando creamos flujos de trabajo lo primero que definimos es el quién va a participar. En otras start-ups tienen otro tipo de procesos diferentes pero en nuestro caso el equipo de producto somos dos. En todo caso este artículo es para ayudar a quienes como yo en algún momento han sido un “team of one” y saben lo que es trabajar en primera línea.
Team of one
Si tienes la suerte de contar un Product Manager, pues, lo de team of one se convierte en un potentísimo team of two!, (a lo Fabulman y Dinamita).
De todas formas quiero hacer hincapié en el “team of one” y mucho cuidado de confundirlo con el unicornio de este otro artículo. Lo digo porque en muchas otras start-ups es un único diseñador quien hace funciones de diversa índole.
El “team of one” es un término acuñado por Leah Buley y del que puedes descubrir mucho más en su libro editado por Rosenfeld, el cual recomiendo que leas cuanto antes, en serio, si ya has visto el enlace, cómpralo.
Aquello que lo hace especial es que usualmente el equipo (de uno) se encuentra en situaciones en dónde no sólo ve una oportunidad para conseguir un enfoque mucho más centrado en el usuario, si no que atrae a otros miembros de la organización hacia este enfoque.
Resumiendo, tienes que ser el integrador, el facilitador y el líder de un cambio o mejora en la cultura de la organización. Por este motivo, este modelo que usamos en Audiense Engineering puede ser de mucha utilidad ya que vas a crear de alguna forma un equipo multifuncional con miembros de tu, “equipo”.
El Problema con los procesos
El enorme problema que se tiene con los procesos es que se llega a un punto en el que la “procesitis y protocolaritis” se vuelven más importantes que lo que realmente importa. La mentalidad. Uno puede tener procesos pero si la gente que se va a involucrar en ellos no lo ve claro… vas a pasar tu tiempo haciendo procesos en vez de buscar un cambio de mentalidad que es lo que realmente funciona.
Haz una declaración de intenciones, qué es lo que tienes como visión, cómo debería ser el proceso del diseño desde tu punto de vista y entiende los modelos mentales de las personas a las que quieres involucrar. Tiene que haber un cambio de actitud y tu labor como facilitador en este momento es muy importante.
Reserva la mayoría de procesos engorrosos para tu uso privado y busca la integración con el equipo en aquellos que faciliten la vida a tus compañeros, mientras menos tiempo perciban que le van a dedicar más asequibles se van a comportar de cara a los procesos que les estás planteando. Tampoco puedes ir en contra de los patrones ya establecidos. Si la compañía usa Trello o Asana o Yammer o lo que fuera, no contravengas a este “establishment” porque vas a perder el juego. Crea a partir de ahí. En el caso de Audiense Engineering, el equipo de producto usamos Trello.
El proceso
Lo primero como ya mencioné antes es conocer a quiénes van a participar activamente en el proceso de diseño de la feature, component, o lo que sea que venga. En el ejemplo tenemos al Product Manager/Owner, el Designer y el UX-writer. (Si aún no sabías que existía un puesto de copy para un proceso de diseño mira este enlace). Esto, repito, puede variar, en tu caso igual estas tú, como diseñador y un desarrollador front, da lo mismo, la idea es poner orden estos requerimientos.
Ésta es un esquema del proceso:
El modelo está dividido en 7 secciones, 4 casi estáticas y 3 muy dinámicas (las tres últimas).
- Starting point
- Personas
- User story
- Storyboard
- Wireframes / Copy
- Hi fi mockups
- Deployment
Al final de cada evento encontrarás ésta lista:
- Herramientas: Las herramientas básicas que deberías emplear, cada quien tiene su propio toolbox, pero las que menciono son las que recomiendo.
- Nivel de iteración: Cuándo se produce usualmente la mayor iteración, no confundir con el hecho de generar más o menos conversación. Ésta siempre debe ser fluida pero en ciertos puntos el nivel se eleva o decrece.
- Responsable: Quién tiene la responsabilidad del entregable, en ningún caso digo que no sea participativo.
- Starting point, la visión que se tiene del diseño.
Es el punto inicial de todo el ciclo, donde se definimos la visión del diseño, es decir qué es lo que tenemos como ideal. Nosotros también nos inspiramos en otros productos exitosos (ya sabemos que “everything is a remix”) cosa que no es en absoluto mala. Todo lo contrario, si no es que se copie es que caminas por sendas ya transitadas y no tienes que inventar la rueda, esto es un time saving único y nos ayuda a evitar las terribles parálisis de análisis. Lo segundo que definimos aquí son las acciones que queremos que los usuarios realicen.
Alguno se preguntará pero… entonces Personas no debería venir antes. Pues no. Porque aquí estas pensando muy en bruto qué es lo que quieres, realmente estás en una situación en la que se debe sustentar el porqué se quiere construir lo que sea que tengas entre manos. Para ello, como ves en la gráfica tienes un research previo sobre el que comenzar a andar. No es que nos inventamos un día lo que vamos a trabajar al siguiente. Y muy importante: definimos las métricas que van a decir si lo que vamos a construir tiene éxito o no. Es en base a estas métricas que o bien pivotamos o bien iteramos, sin mediciones de éxito-fracaso es jugarse mucho que al final cuesta tiempo y dinero.
· Herramientas: Google Docs
· Nivel de iteración: Medio
· Responsable: Product Manager/Owner
2. Define las “Personas” que forman parte del proceso
Poco que decir, estas ya han sido definidas en el research previo a este proceso (¿porque las tienes no?). Lo que hacemos en este momento es establecer a quiénes va a ir dirigido el diseño final, ponerle cara al usuario y tenerlo en mente para humanizar nuestro trabajo, cuando se pierde este grado de humanización empezamos a volar con UIs que resultan utópicas porque perdemos el rumbo.
Pienso que en algún momento de la creación del diseño debes hacerte un captcha mental y preguntarte si eres humano, porque estás diseñando para ellos, no para el portafolio y estás en un equipo.
Siendo un momento de definición, usamos proto-personas (tengo que decir que Audiense es una herramienta potentísima para este fin), que son tipos de usuario de los que tú crees que van a usar tu producto (aparte de las definidas previamente). También nos planteamos variaciones puesto que en algún momento podemos tener un cliente que pague mucho por el servicio y que no encaja con cualquier otro perfil de usuario que tengamos.
· Herramientas: Googledocs
· Nivel de iteración: Bajo
· Responsable: Product Owner
3. User Story, el quién, el qué y el porqué el diseño
Puedes buscar en Internet muchísima información de cómo hacer una user story, yo te recomiendo este enlace de Roman Pichler, lo importante es comprender porqué es tan relevante redactar una historia de usuario con sentido porque créeme que los desarrolladores no van comprender lo que les estás pasando, sea por GitHub o por Pivotal Tracker si no redactas una buena historia de usuario vas a ocasionar confusión, en Audiense Engineering lo tenemos claro, sin esta parte es muy muy complicado avanzar bien. Una vez que hacemos el deploy del diseño nuestro equipo de desarrollo busca la documentación para comenzar a trabajar. En comunicación social el user story puede ser un “storyline”. Esto puede servirte si quieres profundizar en ello.
La plantilla para un user story es ésta:
Como <persona> quiero <el qué> de forma que pueda<el porqué>
Nosotros utilizamos Google Docs para ir documentado esta información y en la pizarra de trabajo (o mesa da igual) comenzamos a organizar las ideas. Siempre es útil mirar atrás y puede que esta historia cambie en el tiempo. Siempre tenemos en mente que todo producto de software está en un eterno beta (o “Banana Principle”). Básicamente lo de “design is never done”.
Solemos utilizar este mapa de flujo de usuario: User see/User do, que al contrastarlo con la plantilla vista antes nos afina la visión del diseño.
· Herramientas: Googledocs / Whiteboard / Post Its
· Nivel de iteración: Medio
· Responsable: Product Owner
4. Storyboard, la historia en viñetas
Esta es la parte que le va a gustar a muchos, dar rienda suelta a tu creatividad, eres tú y la pizarra, no hay riesgos. En este punto buscamos representar los flujos de interacción para conseguir los objetivos que habíamos fijado previamente en el Starting Point y aprovechamos para definir los requerimientos no funcionales (desde el punto de vista de interacción) como por ejemplo: “Necesitamos que la respuesta a esta query se de en X ms”. Eso significa que involucramos al equipo de back-end quienes nos aportan otras posibilidades y también nos ponen al tanto de limitaciones a lo que tengamos en mente.
En pasos previos el Product Manager/Owner era quien estaba definiendo con un poco más de responsabilidad las cosas, pero en este punto el diseñador de producto es quien lleva la iniciativa.
Si viste que dice “historia en viñetas” es porque eso es justamente lo que hacemos. Cogemos los post-its y rotuladores y nos ponemos a diseñar la funcionalidad y los estados.
“Diseñar los estados de una interfaz es lo mismo que diseñar el plan de acción frente a una posible contingencia. Debes tener en mente el antes, el durante y el después”
· Herramientas: Whiteboard / Post Its
· Nivel de iteración: Medio
· Responsable: Diseñador
5. Wireframe & Copy
Aquí quiero hacer un hincapié, porque creo que tenemos que comenzar a dar la importancia debida al contenido, lee este artículo si no te has convencido. Bueno, el asunto es ¿quién hace el copy cuando no hay nadie específico para ello? El copy lo tiene que hacer alguien del equipo y lo más probable es que sea el mismo diseñador quien se encargue. Pero no hay problema, si la app en la que trabajas está en tu idioma tienes suerte, pero si tenemos inglés u otro idioma de por medio te aconsejo que siempre tengas en cuenta los patrones de uso existentes, hay muchas webs con patrones de uso y puedes adaptar los copy de estos mismos , nosotros tenemos algo llamado “elasticidad permitida” que quiere decir, que cuando diseñamos, tenemos en mente que un label “Cancel” no es lo mismo que “Cancelar”, tenemos un par de caracteres más por lo que hay que pensar que en componentes más complicados un texto en español no va a ser igual de extenso que uno en francés, por ejemplo.
Ahora, copy no es bajo ningún concepto lo que se llama Estrategia de Contenidos, no te confundas, de lo que estoy hablando es de de dos conceptos que son micro y macro copy. Para suerte nuestra tenemos estas dos joyas que son “The Craft of Words, Macrocopy y Microcopy”, recomiendo su lectura.
En Audiense Engineering lo que hacemos es que los contenidos textuales los preparamos en el idioma de la app (inglés y, recuerda, pensando que puede expandirse o contraerse el átomo o molécula que estés haciendo, no hablo de biología, sino de Atomic Design por si alguien no lo conoce) y luego los traducimos al idioma que nos hace falta, en el equipo tenemos a personal nativo (que de paso hace un mini test de uso) para esta finalidad (sí, los UX-Copywritters existen ).
Con todo ello ya tenemos lo necesario para montar el wireframe con copy real o muy aproximado a lo final y con ello trabajamos con una certeza mucho más grande que sólo utilizar el Lorem Ipsum (por favor no uses esto para tus wireframes multidisciplinares, eso para ti está bien pero no para el resto).
Del wireframe poco que decir, modelos de baja fidelidad (preferiblemente en papel y lápiz o en alguna herramienta de software) que sirven para iterar de forma veloz y con bajo costo y que es el paso previo al mockup de alta fidelidad.
La iteración en este punto es vital, nosotros tenemos una comunicación fluida con el resto del equipo involucrado en el proceso, es el momento de garabatear todo lo que quieras. No hay excusa para no tener canales abiertos.
· Herramientas: Papel y lápiz / Sketchapp / Invisionapp
· Nivel de iteración: Alto
· Responsable: Copy writter
6. Hi Fi Mockups
Esto es lo que casi está listo para salir del horno. Estos mockups finales son una visión muy cercana a lo que vamos a ver en producción al final del proceso. Conllevan una gran iteración con el equipo pero en una menor medida que en el paso previo, aquí afinamos detalles y ponemos todo “en limpio”.
Solemos crear estos mockups con escala de grises, así vamos a seguir teniendo foco en la funcionalidad (siempre y cuando tengas creada tu guía de estilos para colorearlo luego), te recomiendo que utilices este hexadecimal #23272f como punto de partida y saques la escala de colores en 0to255, créeme cuando te digo que esto te va a resultar más sencillo a la hora de poner todo listo para desplegar el diseño final. Es importante anotar que llegados a este punto, es posible que la visión de diseño inicial se vea recortada por diversos motivos y que lo que tenías en mente en un inicio se haya reducido a un “Minimum Viable Feature”, esta imagen del product development team de Spotify el mejor resumen de lo que estoy diciendo ¿Qué quiere decir esto?, pues que puedes usar este modelo para todo lo que hace falta en el diseño, no tiene que ser necesariamente la app completa, sino, componentes enteros pueden tener este mismo camino. Por ejemplo, para una simple interacción preferimos montar un vídeo con la visión de diseño y animación que buscamos, de forma tal que queda claro qué es lo que se quiere conseguir.
· Herramientas: Sketchapp / Invisionapp / Principle
· Nivel de iteración: Muy Alto
· Responsable: Diseñador
7. Deploy design, listo para enviarlo al dev team
Quiero resaltar que bajo ningún concepto en todo este proceso debe obviarse la participación de más miembros del equipo. El equipo front-end es el aliado natural del equipo de producto, si bien es cierto que al final del proceso el diseño depende de nuestra capacidad de proyectar el concepto en una interfaz útil y usable, los desarrolladores de front-end tienen vista una enorme serie de patrones de uso por todo lo que han hecho en sus carreras, aportan una visión diferente y en más de un caso nos van a ayudan a ver lo que puede que estemos obviando.
El mockup (lo que en diseño gráfico se conoce como “arte final”) lo dejamos con todo lo necesario para que el equipo de desarrollo lo tenga más que claro. El nivel de iteración suele ser bajo porque tenemos una documentación sencilla pero potente que les permitirá guiarse. Nosotros para tener una precisión visual al 100% tenemos integrado Sketchapp con Zeplin e Invisionapp aunque la guía de estilos que tendría que estar ya montada debería ser suficiente para tener de muy claro espacios y márgenes.
Cuando desplegamos el diseño si no tienes a los desarrolladores a tu lado y están en remoto como es el mío te recomiendo que uses la opción de conferencia de Invisionapp para que hagas un review de lo que hay que hacer. En este punto nuestros desarrolladores saben:
- Dónde está archivada la documentación
- Dónde están almacenados los assets que necesitan
- Dónde tiene que poner las trazas de monitorización
- Qué activa la función o de dónde parte la interacción y dónde termina (y cómo)
Como se ve, ese muy sencillo ponerlo al corriente de lo que tienen que hacer. Si tienen dudas de la interacción, pues se dirige al storyboard (le habrás hecho fotos o habrás montado el esquema final antes de borrar la pizarra), para el copy, sólo tiene que abrir los comentarios del copy writer y copiarlos, etc.
De esta forma los diseños que producimos están correctamente desplegados.
· Herramientas: Invisionapp / Zeplin
· Nivel de iteración: Bajo
· Responsable: Diseñador
Listo para cocinar
Es el product manager quien decide lo que entra o no en el sprint según las prioridades y otra serie de factores entre los que se encuentra la opinión del CTO quien influye en esa decisión con información sobre la complejidad de implementación, de esa forma mantenemos esa visión de hasta dónde debemos aspirar a nivel de diseño y de experiencia de uso (las limitaciones de recursos, tiempos y necesidades no deben influenciar en el proceso creativo pero sí deben conocerse.)
En estas últimas semanas hemos incorporado una adaptación del Sprint Design para probar si es viable avanzar con ello con el equipo completamente en remoto.
Es importante en todo caso que cada equipo cuente con su propia metodología, no todos los equipos de trabajo son iguales y no todos los productos pueden llevarse de la misma forma, cada uno debe adaptar los métodos a su propia manera de trabajar. Cierto es que se debe conocer una serie de prácticas que te puedan servir en montar un proceso propio, y ¿dónde aprender? hay muchos sitios en Internet, cursos presenciales (por ejemplo, Ironhack y sus cursos de UX) y online, vídeos y libros (hay una serie de bibliografía muy muy buena y además gratuita para comenzar).
UPDATE
He incorporado al set de herramientas Abstract para el control de versiones de diseño, está resultando sumamente funcional a la hora de modificar según iteramos con el PM y se complementa genial con Invisionapp.
