Categorías
Product management

Sistemas de Diseño. 3de3

En la entrada anterior, hable de las partes que suelen componer un sistema de diseño

¡Y nos dejamos el postre!… vamos a ver como podemos guiar o dirigir los procesos de diseño. Establecer un gobierno es importantísimo para mantenernos alejados de la entropía. ¡Vamos! que todo siga en su sitio y con sentido según vaya creciendo el sistema más y más.

¿Preparados para la perorata? ?

La principal preocupación de los equipos de productos es sacar el trabajo lo más rápidamente posible, no mantener la integridad del sistema de diseño… así que o alguien lo gobierna, o la corrupción de este está garantizada.

El gobierno va a depender de muchos matices, los elementos que componen el sistema, las personas o roles que van a formar parte, los procesos que definiremos para llevarlo a cabo, los artefactos que obtendremos, las herramientas en las que nos apoyaremos…

Además, también dependerá de si hemos decidido que el sistema sea estricto o es más flexible, si está centralizado en un equipo o no, si es modular o no. Cada una de estas circunstancias cambian los procesos de gobierno

Nombres y clasificaciones

Antes de empezar, hay que recalcar que si el Sistema de Diseño es un lenguaje en sí mismo, una forma de compartir un vocabulario entre todos, especialmente entre los diseñadores y los desarrolladores… Pues hay que hacer hincapié en la arquitectura de la información del propio sistema.

Deberemos definir sin margen a dudas que nombre y organización seguirán nuestros componentes, ¿será por su funcionalidad? ¿Por jerarquía? ¿Por producto? ¿Por tipo de cliente? ¿O por su propósito?… ¿Cómo gestionaremos las variantes o alternativas de cada componente? Sin olvidarnos del versionado en cada uno de los casos.

Los diseñadores tienden a clasificar por la estructura de los componentes y los desarrolladores suelen estar más centrado en la funcionalidad. Pero lo normal es que sea una combinación de ambos con las variantes por producto.

Roles

¿Y quiénes están metidos en este lío?… Pues vamos a necesitar la ayuda de:

  • Alguien de negocio o marketing con la visión de producto y que nos guíe en la funcionalidad a implementar
  • Alguien que aporte la experiencia de usuario y la usabilidad. Tendrá que conocer también las métricas útiles
  • Creadores de contenido; alguien preocupado por el SEO / SEM, Copywriters, traductores, ilustradores…
  • Diseñadores visuales y desarrolladores, producirán los componentes
  • Y los usuarios, recordemos que los productos se hacen para ellos y deben formar parte del diseño

Y lo ideal es que fueran grupos de personas distintas y con su ámbito de responsabilidad, pero esto dependerá del tamaño de nuestra organización.

Un sistema de diseño exitoso debe convertirse en parte del ADN de una organización. Las personas que lo gobiernan deben pertenecer a esta y tener una visión holística de todos los productos y servicios.

Procesos

Llegamos al punto más interesante, como ya he comentado anteriormente esto va a depender de las características del sistema que estemos creando, pero hay hitos que suelen ser comunes:

  • ¿Qué pasos seguiremos para crear un nuevo producto o aplicación?
  • ¿Y para añadir funcionalidad? ¿O para retirarla?
  • ¿Cómo documentaremos?
  • ¿Cómo se obtendrán Feedback y gestionaremos los bugs? ¿Cómo se gestionarán esas comunicaciones?
  • ¿Qué métricas vamos a establecer y como las explotaremos?
  • ¿Cómo y quien va a dar soporte o a entrenar a los recién incorporados al sistema?

Herramientas

Respecto a las herramientas, para el diseño visual, es más que interesante cualquiera que permita compartir el trabajo entre el equipo y mantenga un versionado. Figma por ejemplo es una pasada y dispone de la posibilidad de crear Plug-ins. ¿Te imaginas crear un plug-in que traduzca los diseños visuales a nuestro código?. Hay otras herramientas como Sketch o Adobe Xd.

Para la creación del portal del sistema, existen soluciones gratuitas como fractal, pattern Lab, y de pago como Abstract o las de los propios fabricantes de herramientas de diseño visual, como DSM

Existen también otras que facilitan mucho la documentación de los componentes y permiten jugar con ellos en vivo, como es StoryBook.

Y mil más como Craft, UXPin, Lingo

Y un pequeño ejemplo…

Nuestro sistema de ejemplo, será estricto, centralizado y modular.

La clasificación de los componentes es por producto en primer lugar, después por jerarquía, usaremos Atomic Design, y finalmente por funcionalidad.

Dispondremos de un equipo de personas dedicadas al gobierno del sistema

Y a modo de muestra, os pinto el diagrama de actividades que tendría el proceso para añadir una nueva funcionalidad a un producto. Es una primera iteración simplificada, pero sirve de pista

Los diseños y los componentes se trabajarían con Figma, el código se gestionaría en librerías para React, la comunicación vía Slack y los tickets con JIRA, por ejemplo.

El portal de sistema de diseño se realizaría en React aprovechando las propias librerías de componentes que vayamos generando y con enlaces a la herramienta StoryBook para facilitar la documentación visual e interactiva de los componentes

¡Y eso ha sido todo! Una pequeña referencia a los sistemas de diseño. ¡Una tarea muy chula y agradecida!

¡A darle caña! ?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *