Últimamente he estado participando en el diseño inicial de un sistema de diseño y he tenido muchas inquietudes.
Relacionado con eso, la semana pasada vi este contenido en UX Collective. Lo traduje para los miembros del sistema de diseño dentro de la empresa y me pareció una pena no compartirlo también aquí.
Dicen que es un resumen basado en entrevistas con 10 diseñadores que trabajan con sistemas de diseño.
Pregunta 1. ¿Cómo fracasar en un rol de DS?:
-
Convertirte en la policía
-
Usar el poder del diseñador (hablando de política)
-
Integrar componentes y luego no usarlos
-
Trabajar reaccionando después de los hechos, en vez de anticipar las necesidades del equipo
-
No escuchar ni investigar la voz de los usuarios (otros diseñadores o desarrolladores)
-
Un DS hecho por el bien del DS
-
No mantener un roadmap ni un proceso claros para el trabajo
-
Crear una experiencia ideal imposible de implementar
-
No probar junto con el equipo
-
No entender el DS como un producto en sí mismo
-
Crear herramientas y no enseñar a la gente a usarlas
-
Traer demasiada teoría alejada de la forma real de trabajar
-
Pensar que puedes hacerlo solo
-
No enfocarte al 100% en intercambiar conocimiento con alguien del equipo técnico
-
Crear componentes con muy poca flexibilidad y no permitir detaching
-
No pedir ayuda ni conectarte con otras personas (internas o externas)
-
Dictar reglas desde lejos en vez de hacerlo de cerca
Pregunta 2. ¿Qué habilidades blandas se necesitan para que un DS tenga éxito?
-
Comunicación, comunicación, ¡¡¡comunicación!!!
-
Estar con los usuarios; escuchar, preguntar e investigar es realmente importante.
-
Reconoce los fracasos con humildad
-
Ten paciencia
-
La capacidad de crear un espacio seguro
-
Enseñar
-
Presentar una visión sistemática sobre cómo reutilizar
-
Mantener la consistencia con firmeza incluso al escalar
-
Al tratar de entender a la otra persona, no hace falta empatizar tanto. Acepta las reglas tal como son.
-
El 95% son hard skills y el 5% son habilidades blandas para cuando se rompen las reglas.
-
Fomenta el crecimiento de las personas y comparte
-
Autonomía
-
Sigue vendiendo el producto (DS)
-
Piensa estratégicamente
-
Haz que todas las personas participen
-
Hacer ruido alrededor del DS
-
Dedica todo el tiempo posible a descubrir la mayor cantidad de escenarios posibles
-
Alinea el lenguaje.
Pregunta 3. ¿La forma en que se lleva un DS debería ser más centralizada o más distribuida?
Hay dos enfoques: un equipo centralizado que revisa y se hace responsable de cómo diseña la gente, y otro donde todas las personas comparten esa responsabilidad. Les preguntaron a varias personas cuál de los dos enfoques conviene elegir.
-
Somos un equipo demasiado centralizado, así que se generan cuellos de botella. Pero un modelo distribuido también puede tener problemas de pérdida de ownership.
-
Tenemos un equipo de diseñadores de más de 100 personas para centralizar el DS.
-
Colaboramos con las bibliotecas alfa que crea la gente y a partir de ahí armamos el backlog del equipo de DS.
-
Educamos a las personas para que creen componentes por iniciativa propia.
-
Decidir si centralizar o no es, en gran parte, un tema político. Antes de decidirlo, hay que entender con precisión qué tan escalable necesita ser.
-
Hay que ajustar las expectativas e involucrar a las personas en la construcción del DS.
-
Queríamos colaborar, pero como no sabíamos bien cómo hacerlo, creamos un proceso. (Culture vs Process)
-
Al principio puede ser un poco menos colaborativo para poder entregar. A medida que madura, puede volverse más colaborativo.
-
Ya llegamos al momento en que necesitamos descentralizarlo; hay que enseñar a la gente cómo contribuir.
-
Si no educas a la gente, no va a contribuir.
-
Cuando un diseñador quiere ir más allá del estándar para crear un mejor resultado, al mismo tiempo debe poder pensar cómo estandarizar eso también.
-
Un DS no lo pueden hacer 1 o 2 personas. Como se trata de construir un sistema, el DS debe empezar a nivel de squad.
-
Varía mucho según el tamaño del equipo, y a veces el equipo de DS puede enfocarse en desarrollar componentes core mientras otros embajadores los difunden.
-Al final, somos un equipo centralizado, pero trabajamos de forma colaborativa con embajadores. La decisión final la toma el equipo de DS.
- ¿Crees que un DS son reglas más detalladas y restrictivas, o algo más amplio y abierto que da libertad al diseñador para crear nuevos layouts?
¿Cerrado o abierto? Si trabajas en sistemas de diseño, esta pregunta te va a interesar. A mí también, así que decidí preguntárselo a varias personas.
-
En lo relacionado con la "accesibilidad", conviene un enfoque más restrictivo
-
Todos empezamos desde una estructura básica en común, pero comenzamos a generar algunas inconsistencias. Por eso decidimos no ser 100% cerrados, pero sí poner más restricciones. Aun así, siempre tratamos de encontrar formas de devolverles algo a los diseñadores.
-
Depende de la situación, así que primero mide el riesgo y luego decide. En general, equipos más pequeños = mayor flexibilidad
-
No se trata solo de crear componentes nuevos y creativos. Se necesitan componentes lo suficientemente flexibles como para adaptarse a las necesidades de la gente.
-
El DS es negocio. Cuantos menos componentes, mejor.
-
La gente debe disfrutar usar el DS. A simple vista puede parecer un uniforme y ser fácil pensar que no necesita flexibilidad (pero sí la necesita).
-
No puede ser muy restrictivo desde el principio. Con suficiente tiempo, puede empezar a evolucionar hacia ciertos patrones, etc.
-
Para un diseñador que recién se incorpora a la empresa, puede ayudar tener más restricciones. Para romper las reglas, primero hay que empezar por las reglas.
-
Damos suficientes ingredientes para que la gente pueda crear sus propias recetas.
-
Depende de la madurez del equipo. Si hay más perfiles junior, como tienden a entender menos documentación, suelen pedir más guías de diseño. Entonces hace falta más capacitación, pero aun así intentamos no encerrarlos y permitirles trabajar con libertad. El mayor desafío es lograr que la gente realmente lea y use la documentación, así que existe la posibilidad de llevarla a lugares más cercanos al diseñador, como Figma.
-
Si se trata de accesibilidad y estética, debería ser más restrictivo.
-
Los tokens son importantes para mantener la consistencia.
-
Una buena documentación equilibra la armonía con las personas y la libertad que se les da.
Pregunta 5. ¿Qué opinan de un DS conectado con branding y marketing?
(Como no es un área que conozca bien, la traducción aquí fue un poco difícil.)
Entiendo que al final un sistema de diseño debería tratar sobre productos digitales, pero como el producto puede ser una de las plataformas de marca más importantes, tenía curiosidad por saber cómo la gente relaciona ambas cosas.
-
Una forma de pensar el branding conectado al DS es pensar cómo eso impacta al DS en sentido inverso.
-
Empezamos a alinear el sistema de diseño con la marca para alinear la apariencia y la sensación de la marca.
-
El DS sirve para la escalabilidad y la identidad de marca, pero la conexión entre ambas depende del equipo de branding.
-
Since DS is a language, MKT could support with assets for it;
-
El equipo de branding debe sumarse al DS desde el principio para crear las reglas básicas.
-
Depende de la empresa. Como el DS es una herramienta para fortalecer la marca, es importante mantener la alineación. La conexión entre ambas áreas también afecta la accesibilidad del DS.
-
Es importante encontrar maneras de sincronizarse con el equipo de branding para alinear la estrategia.
-
They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;
-
A veces la documentación y el sistema pueden usarse juntos, pero en general no. El DS es la interfaz. El equipo de marca suele tener por separado un "sistema de branding", y es más común que las bibliotecas interactúen entre sí. No son exactamente lo mismo.
Pregunta 6. ¿Cómo se puede medir el éxito de un DS?
-
Encuestas de percepción para entender la participación, la adopción y el estado de los equipos
-
Cobertura de componentes (cuánto se usa el DS vs cuánto está hardcodeado)
-
Adoption
-
Time to market
-
ROI
-
Figma Analytics
-
Respuesta de los equipos de desarrollo
-
Accesibilidad
-
La cantidad de veces que se usaron los componentes
1 comentarios
Vaya, qué bueno. ¡Gracias por el resumen!