Migrando Sistemas de Diseño
Migrar un sistema de diseño pudiera parecer una tarea fácil de lograr. Desafortunadamente, no es tan fácil como uno piensa. Es normal cuestionarse qué tipo de pasos debo de tomar o que debo revisar y validar antes de incluso pensar en la migración de un Sistema de Diseño de una herramienta a otra.
Para ello, el siguiente documento espera ser de gran ayuda para preparar todo lo necesario para lograr la tarea de migrar un DS (Design System o Sístema de Diseño. Usaremos esa abreviatura a partir de ahora).
¿Cuál es el principal objetivo?
Ofrecer una guía que facilite identificar qué necesitas de antemano y los pasos para migrar un DS de una herramienta (o sofware) a otro. Durante este documento reforzaremos y validaremos elementos importantes en el proceso de migración.
¿Qué esperar?
Esta guía te mostrará en 4 pasos lo que necesitas considerar para una migración exitosa de un DS. Cada paso tiene una lista de cosas a revisar, su descripción e información de respaldo junto con links a otros artículos.
Este documento NO TIENE LA INTENCIÓN de enseñar cómo hacer Sistemas de Diseño. No te enseñará a cómo crear componentes, símbolos o cualquier otro elemento ya que cada herramienta/software/plataforma tiene funcionalidades únicas y el uso de estos varía dependiendo de los flujos en los que se trabaje.
Antes de empezar…
La idea de detrás de este documento proviene de una tarea especifica:
“Necesitamos migrar el Sistema de Diseño de Sketch a Figma pero no sabemos qué va primero, qué va después y cómo hacerlo.”
Transformando esto desde la perspectiva usando el método STAR:
-
Necesidad de migrar el DS de una herramienta a otra
Design System – the complete set of design standards, documentation, and principles along with the toolkit (UI patterns and code components) to achieve those standards.
-
Identificar y definir el proceso para realizar la migración
-
1. Definir el estatus actual del DS
2. Definir roles y responsables
3. Definir responsabilidades clave
-
Empezar a migrar el DS por partes
Lectura recomendada: Flow to make a good Design System Migration. Get the basics in the following document:
Sigue este proceso de 4 pasos para ver el ‘big picture’ o el panorama general e identifica, si es posible, las fallas y mejoras que existen antes de migrar el DS.
Paso 1. Revisar necesidades
Mapea el proceso. Identifica quién hace qué y cómo funcionan actualmente las cosas
[ ] Idenfica quién entrega y quién aprueba en el DS
[ ] Identifica quién usa qué herramientas
[ ] Identifica el producto o los productos que el DS impactará
Define el público objetivo. ¿Quién usará el DS? (Diseñadores, PMs, Desarrolladores, otras personas clave… etc)
[ ] Lista todos los involucrados en la toma de decisiones de diseño
[ ] Incluye los valores clave de la compañía
Define el propósito. ¿Cuál es la razón para crear el DS?
[ ] Lista a los involucrados en la toma de decisiones del DS
Define objetivos. ¿Cuáles son los objetivos del DS? (Resolver problemas, tener una sola fuente de consulta… etc)
[ ] Lista los objetivos (Recuerda que deben ser específicos, medibles, alcanzables, relevantes y con tiempo definido)
Paso 2. Definir madurez del Sistema de Diseño
No implementado. Componentes/Símbolos existen pero no hay una estructura definida o solo existe una ‘Guía de estilos’ básica
[ ] Define el tipo de Sistema de Diseño
¿Es un Sistema Modular (intercambiable y reusable) o Sistema Integrado (componentes no son intercambiables. Son únicos)?
¿Es un Sistema estricto (necesita estar muy detallado) o Sistema flexible (provee un framework pero hay flexibilidad en su uso)?
¿Es un Sistema centralizado (un equipo está encargado) or Sistema distribuido (varios equipos trabajar en el DS)?
[ ] Lleva acabo una auditoría visual
[ ] Recolecta todos los símbolos/componentes/patrones en un mismo lugar
Puede ser en una página, en un frame, etc… (Lee más acerca del Atomic Design. Esta lectura ayudará en la organización y estructura de tu Sistema de Diseño) Atomic Design Methodology | Atomic Design by Brad Frost
[ ] Define la prioridad de los componentes
Identifica qué componentes son críticos para el producto y prioriza cuáles deben de estar organizados y documentados primero
Diseñado pero no Implementado o documentado adecuadamente. Existe una estructura y organización. Diseñadores pueden usar componentes para crear flujos pero no está implementado en código (un repositorio donde los programadores colocan los componentes funcionales) o falta documentación
[ ] Identifica cuál es el proceso actual
[ ] Identifica dónde está localizado el DS
‘Codeado’/Implementado. Existe un repositorio donde los desarrolladores colocan los componentes funcionales con la documentación tanto de diseño como desarrollo. Estos componentes son los que se usan en el o los productos
[ ] Idenfica la librería/repositorio desarrollado y el DS
Paso 3. Define Responsabilidades
Participantes. Ya identificaste los procesos, quién está involucrado y el estatus del DS. Ahora es tiempo de definir quién trabajará en el DS
[ ] Define responsables
Lectura recomendada: Matriz RACI. Puedes usar la matriz RACI para determinar/identificar participantes y sus roles para definir responsabilidades. Source
Roles. Clarifica quién lidera al equipom, quiñen toma decisiones clave y quién realiza tareas operativas. Como tip, define también los roles de Scrum Master y Control de calidad*.
[ ] Define Roles
Lectura recomendada: UX Design Systems | Create & Maintain | Adobe XD Ideas
*Quality control is a subset of QA. In QC, teams ensure that the developed product meets the organization’s quality standards. Defects in a software product, such as UI glitches, design imperfections or accessibility issues. Source
Cadencia de trabajo. Cada rol necesita tener una lista de tareas y que necesita hacer con tiempos realistas (definición de tiempos y juntas).
[ ] Define la cadencia* de trabajo
[ ] Define canales de comunicación
Cadence can be referred to when, where and how a leader or manager and his team regularly meet and where team members and staff have an opportunity to share views and information.
Paso 4. Estructura del Sistema de Diseño
Auditoría visual. Dependiendo del nivel de implementación, es posible que el DS tenga, o no, cierta documentación acerca de él.
[ ] Describe Problema-Solución del DS
[ ] Identifica documentación funcional
[ ] Idenficia documentación técnica
Lectura recomendada: How to govern a design system that is continuously evolving
Definiendo una estructura. Organiza tu DS y define su estrutura. Puedes tener múltiples páginas o incluso múltiples archivos (esto dependerá de qué tan grande y detallado sea el DS).
[ ] Incluye reglas de Branding, lenguaje, tono y voz
[ ] Incluye Guías de Estilo*
Style guide – Another subclass in the design system, this static documentation describes the design system itself: how products should look and feel, use cases for UI patterns, correct typographic scales, etc.
[ ] Incluye Librería de Patrones (si está por separado)*
Pattern Library – A subclass in the design system, this is the set of design patterns for use across a company.
[ ] Incluye Guía de Contenido
Ayuda con el tono y forma de los componentes
Este proceso de 4 pasos puede ayudarte a definir una estructura. Este proceso puede aplicar tanto para Guías de estilo como Librerías de Patrones. Descubrir: audita y recolecta requerimientos y consideraciones específicas. Definir: identifica y define taxonomía, propiedades y variaciones. Diseñar: Revisa diseños y requirimientos actuales y empieza a construir desde ahí. Entregar: Revisa e itera con stakeholders hasta la aprobación.
En resumen…
Esta es solo una guía que puede ser replicada y adaptada a cualquier tipo de DS y su nivel de madurez. Si tu equipo solo tiene una Guía de estilo, trata de adaptar este proceso de 4 pasos. O si solo tienes un grupo de componentes o colección de símbolos, intenta implementarlo y darle forma a tu DS.
La llave del éxito es tener el panorama completo (qué es lo que tienes, quién está involucrado y cómo se maneja) sin importar el nivel de madurez que tenga el Sistema de Diseño.
También, no te preocupes por el proceso operativo (ej. crear componentes en Figma o símbolos en Sketch), primero organiza lo que tengas y luego toma acción. Tomará más tiempo (y recursos) estar arreglando cosas que organizarse bien desde el principio.
Puedes descargar gratis esta Cheat Sheet para el Sistema de Diseño. La click en el botón de abajo