settings
1

Requerimiento de diseño, de principio a fin.

UX

Bien, voy a comenzar este artículo dejando en claro que esta puede que no sea la mejor forma de hacerlo. Pero como siempre digo (como pasó con Flash, como pasa con frameworks de UI, etc.)

“Usa lo que se adapte a tus necesidades y te dé resultados”

Con esto en mente puedo contar un poco más sobre cómo he llegado a definir este proceso de requerimiento de diseño. En el diseño de producto y hablando estrictamente del binomio funcional + visual creo que el primer factor es el que debe siempre imperar sobre el segundo. Ya hemos visto que diseñar para satisfacer únicamente el aspecto visual no es necesariamente lo mejor que se pueda hacer. Una funcionalidad que vaya adelante como una seda acompañada de un aspecto visual agradable y con los efectos justos genera una emoción de satisfacción única en nuestros usuarios. Creo que el desbalance de cuaquiera de estos componentes provoca un bajón en la experiencia de uso que no tiene porqué darse.

Una vez más me voy a centrar en los colegas que trabajan en diseño de producto, lo siento, no soy researcher. Tampoco soy UI/UX, soy Diseñador.

Lo primero que tienes que tener en cuenta para crear tu flujo de trabajo es conocer quiénes van a intervenir en él. Si tienes la suerte de trabajar para cualquier big name pues quizás este artículo no te sirva de mucho, de hecho tendrás unos procesos súper bien montados. Esto 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

Sí, existe el “team of one” y mucho cuidado de confundirlo con el unicornio del que hablo en este otro artículo.

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 donde 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 ello, este modelo que tengo para ti puede serte de mucha utilidad ya que vas a crear de alguna forma un equipo multifuncional con miembros de tu, bueno, 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 “procesisitis 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é cosa es lo que tienes como visión de cómo debería ser el proceso del diseño desde tu punto de vista y entiende los modelos mentales de la gente a la que quieres involucrar. Tiene que haber uncambio 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í.

La propuesta

Lo primero como ya mencioné antes es conocer quiénes van a participaractivamente en el proceso de diseño de la feature, component, o lo que sea que venga. En el ejemplo tenemos al Product Owner, el Designer y el Copy writter. (Si aún no sabías que existía un puesto de copy para un proceso de diseño mira este enlace). Esto, repito, en mi caso, en el tuyo igual estas tú como diseñador y un desarrollador front, da lo mismo, la idea es poner orden a estos requerimientos.

Ésta es la propuesta:

Requerimiento de diseño

El modelo está dividido en 7 secciones, 4 casi estáticas y 3 muy dinámicas (las tres últimas).

  1. Starting point
  2. Personas
  3. User story
  4. Storyboard
  5. Wireframes / Copy
  6. Hi fi mockups
  7. 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.

1. Starting point, la visión que se tiene del diseño.
Es el punto inicial de todo el ciclo, donde se define la visión del diseño, es decir qué es lo que tenemos como ideal. Puedes servirte de otros trabajos que ya tengan éxito (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 se debe definir aquí son lasacciones 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 te inventes un día lo que vas a trabajar al siguiente. Y muy importante:definir las métricas que van a decir si lo que vas a construir tiene éxito o no. Es en base a estas métricas que o bien pivotarás o bien iterarás, sin mediciones de éxito-fracaso te estás jugando mucho.

Herramientas: Googledocs
Nivel de iteración: Medio
Responsable: Product 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 debe hacerse 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 para humanos estás diseñando, no para el portafolio
Siendo un momento de definición, puedes usar también protopersonas, que son tipos de usuario de los que tú crees que van a usar tu producto (aparte de las definidas previamente). Puedes usar variaciones puesto que en algún momento puedes tener un cliente que pague mucho por tu servicio y que no encaja con cualquier otro perfil de usuario que hayas creado.

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. Ya que una vez que hagas del deploy del diseño tu equipo de desarrollo va a buscar la documentación para comenzar a trabajar. No tienes que hacerla tú pero si no te queda más remedio es parte de tu tarea. Y esa es otra, que tú también necesitas una buena historia de usuario para comenzar con tu trabajo, para que “comprendas” a la persona que usará lo que estás diseñando y (creo que ya lo dije) no te vayas por las ramas y te centres en el objetivo. En comunicación social el user story puede ser un “storyline”. Lo digo porque 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é>

Usa Docs para ir documentado esta información y luego ponte de pie y ve a tu pizarra de trabajo (o mesa da igual) y comienza a organizar las ideas. Siempre es útil mirar atrás y puede que esta historia cambie en el tiempo. Recuerda que todo producto de software está en un eterno beta (o “Banana Principle”).

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, da rienda suelta a tu creatividad, eres tú y la pizarra, no hay riesgos. En este punto busca representar los flujos de interacción para conseguir los objetivos que habías fijado previamente en el Starting Point y aprovecha 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 Xms”. Eso significa que vas a involucrar a tu equipo de backend que te dirá posibilidades y limitaciones a lo que tengas en mente.

Si antes el Product owner era quien estaba definiendo con un poco más de responsabilidad las cosas, en este punto tú eres el que debes llevar la iniciativa, eres el diseñador, esta es tu misión, vamos que te pagan para ello.

Si viste que dice “historia en viñetas” es porque eso es justamente lo que se tiene que hacer. Coge los postits y tus rotuladores y ponte 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 tengas que hacerlo tú. Pero no hay problema, si la app en la que trabajas está en español 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 o, lo yo te recomiendo es que el diseño tenga lo que llamo “elasticidad permitida” es decir, que cuando diseñes, tengas 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 decir algo.

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.

Lo que puedes hacer es que los contenidos textuales los hagas en español (recuerda, pensando que puede expandirse o contraerse el átomo o molécula que estés haciendo, no hablo de biología, sino de Atomic Designpor si alguien no lo conoce) y luego los traduzcas al idioma que necesites, puedes usar como referencia lo que sepas, si sabes o el mismo translator de Google (ojo, como referencia). Lo siguiente es que vas a tener que pagar por horas a algún nativo que venga y corrija (de paso haces un minitest de uso) lo que tengas ya montado. Con el tiempo sí que vas a necesitar a alguien dedicado sólo a ello. (Sí, los UX-Copywritters existen).

Con todo ello tienes lo necesario para montar el wireframe con copy real o muy aproximado a lo final y puedes trabajar 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, necesitas tener 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

Simple, esto es lo que casi está listo para salir del horno. Estos mockups finales son una visión muy cercana a lo que vas 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í estás afinando detalles y poniendo todo “en limpio”.

Lo mejor que puedes hacer es 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”, estaimagen 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.

Herramientas: Sketchapp / Invisionapp
Nivel de iteración: Muy Alto
Responsable: Diseñador

7. Desploy 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 front end es tu aliado, si bien es cierto que al final del proceso el diseño depende de tu capacidad de proyectar el concepto en una interfaz útil y usable, los devs de frontend 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 algún caso te van a ayudar a ver lo que tú estás obviando.

El mockup (lo que en diseño gráfico se conoce como “arte final”) debería tener todo lo necesario para que el dev team lo tenga más que claro. El nivel de iteración debería ser bajo porque tienes una documentación sencilla pero potente que le permitirá guiarse. Te recomiendo que si quieres tener una precisión visual al 100% integres Sketchapp con Zeplin 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 despliegues el diseño si no tienes a los devs 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 tus devs tienen que saber:

  • Dónde está archivada la documentación
  • Dónde están almacenados los assets que necesite
  • 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 ves, ese muy sencillo ponerlo al corriente de lo que tiene que hacer. Si tiene 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 writter y copiarlos, etc.

De esta forma tu diseño estará correctamente desplegado.

Herramientas: Invisionapp / Kissmetrics
Nivel de iteración: Bajo
Responsable: Diseñador
Dime qué te ha parecido esta propuesta, ¿la encuentras útil? ¿qué método usas cuando tienes un requerimiento de diseño?.

Tags:
Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273