diseño y desarrollo de producto son más complejos. ‣ Proyectos suman más personas y equipos especializados. ‣ Se acumula deuda técnica y de diseño cuando se hacen soluciones únicas. Aumenta la complejidad y disminuye la calidad de la experiencia… PROBLEMAS EN EL DISEÑO DE PRODUCTO
a product portfolio to converge on a cohesive experience.” ‣ Un marco escalable de desiciones y comportamientos de equipos dentro de un portfolio de productos para converger en una experiencia coherente. ‣ — Nathan Curtis ‣ DESIGN SYSTEM ES:
to serve the purposes of a digital product.” ‣ “Grupo de patrones conectados y practicas compartidas, organizadas coherentemente para servir las funciones de un producto digital.” ‣ — Alla Kholmatova ‣ DESIGN SYSTEM ES:
Pero son solo una herramienta: carecen de los procesos y metodologías para diseñar componentes de forma coherente; y las prácticas y personas que ayuden a implementarlas en el producto.
‣ Mayor velocidad: se pierde menos tiempo en tomar desiciones y en el hand-off. Se pone el foco en resolver el problema para el usuario. ‣ Consistencia a gran escala: Consistencia como un atributo fundamental de un producto para mejorar la experiencia de usuario. SOLUCIONES QUE PROMETE
ESPACIOS/ESCALAS FORMAS LAYOUT ANIMACION BOTONES, NAVEGACIÓN, LISTAS, FORMULARIOS, ETC… SIMPLES O COMPUESTOS Design Systems de Alla Kholmatova - Smashing Books
ICONOGRAFIA COLOR ESPACIOS/ESCALAS FORMAS LAYOUT ANIMACION BOTONES, NAVEGACIÓN, LISTAS, FORMULARIOS, ETC… SIMPLES O COMPUESTOS Design Systems de Alla Kholmatova - Smashing Books
Se empezó a tomar el producto como la fuente de los componentes. “Cuál es el último diseño de la tabla?” ‣ Problema para hacer cambios: se comparte entre websites y productos. Tecnología que quedó antigua, ya que todos empezaron a migrar a React. ‣ No documenta como se usan y combinan los componentes, lo cual empieza a ser criterio de cada uno. PROBLEMAS DE STYLEGUIDE
equipo. ‣ Evidenciar los problemas trabajo repetido, código difícil mantenimiento, inconsistencias de diseño. Armar inventario de botones para mostrar falta de coherencia en la experiencia. ‣ Mostrar experiencias de otras compañías. EL PITCH: ¿POR QUÉ NECESITAMOS UN DESIGN SYSTEM?
de diseño, desarrollo y testing. Si uno cuesta 100 y se hace en 3 equipos distintos, gastamos 300 por un componente que encima no es fácil de mantener. Y si cada componente se hace 3 veces… UN EJEMPLO: HACIENDO UN CAMBIO COORDINADO
Crear los primeros 6-7 componentes más reutilizables. • Probar el ambiente de desarrollo que auto-genera la documentación. ‣ Tiempo: 3 meses ‣ Demo: para compartir y validar el resultado del experimento PRUEBA DE CONCEPTO
toda la información. • Pegamos imágenes de como se usa el componente (del inventario) y especificaciones del diseño, aunque no esté del todo definido. • Definimos las variantes y configuraciones (props) PATRONES FUNCIONALES
e identidad, tenemos decisiones acerca de los los estilos visuales: paleta de colores, tipografías, escalas y espacios, iconografía, animaciones. Muchos de estos ya aparecían en la Styleguide, pero sin embargo quedan por sistematizar. PATRONES PERCEPTUALES
primarios Colores neutrales (grises) → A partir del inventario identificamos 10 grises. Unidades de espaciado → Usamos la escala de 8px y elegimos los más utilizados (8, 16, 24, 32, 64, 128)
HTML y CSS. ‣ Puesta a prueba del componente: tests con diferentes variantes y cantidad de datos. ‣ También se agrega a la aplicación de prueba. DESARROLLO
Si no está documentado, no existe. ‣ Hacer release para que los usuarios lo prueben. Agregar a Sketch para que se use en los diseños. DOCUMENTACIÓN & RELEASE
3: en tres pantallas del producto, o en en 3 productos distintos. ‣ No está mal que el producto use componentes fuera del design system. Puede haber componentes únicos o temporales. Los productos siempre van a tener librerías locales de componentes. NO TODO VA AL DESIGN SYSTEM
dedicado genera confianza de que habrá soporte y mantenimiento continuo. Está formado por: • 1 diseñador, 1 desarrollador front-end, 1 ingeniero → full-time • 2 ingenieros → part-time EL EQUIPO
colaborar: con diseñadores de producto y desarrolladores e ingenieros. ‣ No hace falta ser del equipo de DS para aportar al Design System. Es un proyecto cross-team, para uso y beneficio común. ‣ El equipo de DS cura y reglamenta el contenido, brinda soporte. COLABORACIÓN
producto usa partes del sistema. Ya sea un nuevo producto o una nueva feature. ‣ Cuando hay muchos productos, es recomendable priorizar el producto estrella (flagship), que es el que marca el rumbo. ADOPCIÓN
‣ Equipo multi-disciplinario para interactuar con múltiples areas. ‣ Hacer foco en las partes del sistema que dan beneficio inmediato a los equipos: es la parte técnica y herramientas de desarrollo? es la documentación de diseño? es el archivo ordenado de Sketch? ACIERTOS
Roadmap. Nos costó priorizar las tareas importantes de las accesorias. Alinear el DS con los proyectos prioritarios de la compañía es la solución. ‣ Hicimos muchos componentes sin terminar de testearlos: Es preferible tener 10/15 componentes al 100%, sino no serán adoptados. Lanzar la primera versión con pocos, pero buenos. ERRORES
con otros equipos. ‣ Adopción del sistema a través de nuevas features vs re-escribiendo las pantallas existentes del producto. En productos nuevos es más fácil! ‣ Qué hacemos con la Styleguide? Armar otro sistema para websites? DESAFÍOS
Design System Handbook (de inVision): https://www.designbetter.co/design-systems-handbook • Todo lo escribe Nathan Curtis (@nathancurtis) en Medium: https://medium.com/eightshapes-llc/tagged/design- systems • Twitter: @jina, @MinaMarkham, @broccolini, @cap, @johngold, @karrisaarinen, @marcosuarez, @yeseniaa, @AngelosArnis, @almonk, @iKristy, @sarah_federman, @marcintreder, @_dte, @bradfrost, etc… Más links: • Design System Repo: https://designsystemsrepo.com/ • Newsletter: http://news.design.systems/ • Comunidad de Design Systems en Slack: http://design.systems/slack/ POR DONDE EMPEZAR