Gobierno
En nuestra experiencia desarrollando sistemas de diseño para grandes organizaciones, tenemos claro que definir el modelo de gobierno del sistema es clave para permitir que el sistema escale de forma sensata, manteniendo la consistencia y pero dejando espacio también para la innovación y la creatividad. Es fundamental tener claro cómo va a ser este gobierno antes de lanzar el sistema.
Antes de entrar a ver el método que usamos para estandarizar el workflow, veamos un par de cosas claves para que este proceso tenga éxito:
Digital System Team
El Digital System Team (DST) es un equipo formado por diseñadores y desarrolladores que analizan los nuevos componentes que se van añadiendo al sistema. Tendrán que ser perfiles diversos que representen los diferentes canales, touchpoints y unidades de negocio. Este equipo deberá tener reuniones frecuentes con los equipos de cada proyecto para revisar los diseños y los componentes que están usando y generando. Su trabajo no es aprobar el diseño, sino proporcionar una visión holística del sistema y su uso a todos los equipos.
Canal para feedback
Un canal de comunicación al que sea fácil acceder es crucial para que los equipos puedan recibir feedback sobre nuevos componentes. Este canal puede ser una página de contacto en la web del sistema, una dirección de mail, un canal de Slack...sea cual sea, debería ser fácilmente accesible y su existencia debe estar bien comunicada a todos los equipos que trabajan en el sistema.
Formulario para nuevos componentes
Este formulario estandarizará el proceso de los equipos de diseño a la hora de sugerir nuevos componentes para el sistema en función de sus necesidades. Para lograr que el Digital System Team sea capaz de revisar y responder a todas las peticiones de forma eficiente, lo mejor es que todas ellas sigan la misma plantilla e incluyan los siguientes elementos:
Equipo y proyecto
Touch point (web, app, unidad de negocio)
Necesidad de nuevo componente explicada
El diseño del nuevo componente
Cualquier información o contexto adicional que ayude a analizar el componente (para qué lo necesitan, el componente usado en una página completa, un user flow si el componente impacta en UX, etc)
Fecha de entrega del sprint
La comunicación del sistema de diseño
Una newsletter bi-semanal a todos los equipos de producto permite tener una conexión constante entre todos los equipos involucrados en el sistema y aporta información adicional como:
Actualizaciones del sistema (nuevos componentes)
Próximas actualizaciones o componentes, con fechas
Guías de uso
Recordatorios importantes
Workflow
Petición de nuevo componente
Es muy probable que, conforme pasa el tiempo, los equipos de producto vayan identificando nuevas necesidades de componentes que todavía no estén cubiertas por el sistema. Aquí podemos tener 2 escenarios:
Ya existe un componente similar. La librería actual ya tiene un componente que cubre esa necesidad (o uno muy similar) y por tanto, deberían utilizarlo.
La librería no tiene ningún componente que cubra esa necesidad y por ello, hace falta crear uno nuevo. En este caso, el equipo de diseño de producto debería seguir los pasos que explicaremos a continuación.
Pasos para crear un nuevo componente
Diseñar este "suggested new component" (SNC) usando las guías del sistema.
Enviar este SNC al Digital System Team rellenando el formulario de nuevo componente y enviándolo a través del canal oficial de feedback que hayáis definido.
Si es un grupo de componentes o si es un componente muy complejo, es recomendable una reunión (presencial o en remoto) entre el equipo del proyecto y el Digital System Team para poder hablar sobre el ello y poder dar más contexto, resolver dudas in situ y llegar a una solución final.
Una vez que el nuevo componente ha sido revisado, el equipo del sistema (DST) podrá determinar en que Tier va a colocar este nuevo componente (es decir, si es un un componente que estará Tier 2 como librería global para ese touchpoint, y que por tanto podrán reutilizar muchos otros equipos, o si no merece la pena porque es un caso muy concreto y entonces se queda en el Tier 3 de la app o web local). Para tomar esta decisión, deberían tener en mente:
Lo reutilizable que es este componente para otras herramientas o productos
El impacto que tendría este componente en el sistema de diseño
La complejidad técnica de este componente
Versionado
Como ya hemos ido comentando varias veces a lo largo de esta guía, un sistema de diseño está vivo y deberá irse actualizando constantemente. El DST (design system team) deberá crear y comunicar las nuevas versiones del sistema de forma constante. Para hacer esto de forma controlada y efectiva, sugerimos el siguiente flujo:
Definir los objetivos: cuáles son los objetivos y prioridades de esta nueva versión y qué necesidades se están cubriendo.
Ejecutar los cambios: añade nuevos componentes, modifica estilos o componentes ya existentes en función de datos o test que hayas hecho o elimina componentes que ya no se usen o que no estén funcionando como deberían.
Valida todo: cada nueva actualización debe cumplir con los criterios definidos para garantizar usabilidad, coherencia y calidad (es decir, estados, comportamientos, acciones, escalabilidad...)
Cierra la versión: publica la nueva versión en Figma/Sketch y empieza a implementar estos cambios en la plataforma del sistema de diseño.
Es importante documentar qué cambios se han hecho en cada versión que se cierra. Hay pluggins que pueden extraer esta información de forma automática y crear un 'change log' para que los diseñadores y desarrolladores tengan una referencia rápida de todo, o hay herramientas que ya te dan esta información directamente.
Acciones
Crear un DST (Design System Team) que sea multidisciplinar.
Definir la forma en que cualquier persona puede ponerse en contacto con el equipo del sistema de diseño, tanto para preguntar dudas como para solicitar un nuevo componente.
Definir y comunicar el modelo de gobierno y el workflow de versionado. Todo el mundo debe conocer ambas cosas.
Last updated
