Design Systems: Haciendo productos consistentes y escalables.

1. Design Systems: Haciendo productos consistentes y escalables. IDF BSAS - JULIO 2018 Fernando Carrettoni Design System Lead @ Auth0
2. Fernando Carrettoni Design System Lead @ Auth0
3. ¿Qué es un 
 Design System? DEFINICIONES
4. ‣ A medida que crecen las compañías, los procesos de 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
5. ‣ “A scalable framework of decisions & team behaviors across 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:
6. ‣ “Set of connected patterns and shared practices, coherently organized 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:
7. Las librerías de componentes son una parte esencial de un Design System. Allí vemos la documentación y guías de uso de los componentes que integran un producto. DIFERENCIAS CON UNA LIBRERÍA DE COMPONENTES
8. DIFERENCIAS CON UNA LIBRERÍA DE COMPONENTES Gráfico de Varya Stepanova 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.
12. ‣ Lenguaje común entre los equipos de Diseño e Ingeniería. ‣ 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
13. ¿Es el Santo Grial para el diseño de productos? Definitivamente no. 
 La implementación de un Design system es a medida de cada compañía y sus equipos.
14. Conceptos 
 importantes DESIGN SYSTEMS
15. ATOMIC DESIGN Brad Frost http://atomicdesign.bradfrost.com/chapter-2/
16. COMBINANDO COMPONENTES Brad Frost http://atomicdesign.bradfrost.com/chapter-2/
17. DISEÑO A PARTIR DE COMPONENTES Brad Frost http://atomicdesign.bradfrost.com/chapter-4/
18. PRODUCTO + SISTEMA Brad Frost website o producto http://atomicdesign.bradfrost.com/chapter-5/
19. SISTEMATIZACIÓN DE DISEÑO Patrones Perceptuales Patrones Funcionales TIPOGRAFÍA ICONOGRAFIA COLOR ESPACIOS/ESCALAS FORMAS LAYOUT ANIMACION BOTONES, NAVEGACIÓN, LISTAS, FORMULARIOS, ETC… SIMPLES O COMPUESTOS Design Systems de Alla Kholmatova - Smashing Books
20. SISTEMATIZACIÓN DE DISEÑO Componentes Estilos Patrones Perceptuales Patrones Funcionales TIPOGRAFÍA ICONOGRAFIA COLOR ESPACIOS/ESCALAS FORMAS LAYOUT ANIMACION BOTONES, NAVEGACIÓN, LISTAS, FORMULARIOS, ETC… SIMPLES O COMPUESTOS Design Systems de Alla Kholmatova - Smashing Books
21. SISTEMATIZACIÓN DE DISEÑO
22. De Styleguide 
 a Design System AUTH0
24. ‣ Surgieron nuevos componentes pero la Styleguide no se actualizó. 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
25. El Pitch DE STYLEGUIDE A DESIGN SYSTEM
26. ‣ Convencer al CTO, Director de Diseño y miembros del 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?
27. UN EJEMPLO: HACIENDO UN CAMBIO COORDINADO
28. Cada uno de estos Dropdowns tiene un costo en tiempo 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
30. La prueba de concepto DE STYLEGUIDE A DESIGN SYSTEM
31. ‣ Objetivo: • Copiar una pantalla emblemática del producto. • 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
32. PRUEBA DE CONCEPTO Form Text Input Button / Icon Form Field Page Header Tabs Text Area
33. VIDEO
35. 1. Procesos 2. Equipo 3. Herramientas DE STYLEGUIDE A DESIGN SYSTEM
36. Definiendo un proceso DE STYLEGUIDE A DESIGN SYSTEM
37. Inventario Patrones perceptuales Patrones funcionales Desarrollo Documentación DEFINIENDO UN PROCESO
38. Capturas de pantalla • Recorrer las pantallas de cada producto y tomar capturas de diferentes interfaces. • Agruparlos en categorías según su funcionalidad. INVENTARIO
43. Nombrar los componentes • El nombre puede cambiar pero es importante para no duplicar. • Descartamos de casos únicos o erróneos. • Clasificamos según complejidad: átomos y compuestos. INVENTARIO
45. Definiendo los componentes • Empezamos por un documento para juntar 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
47. Users
48. Variante Tamaño Compact: Uso dentro de Nav Default: Uso dentro Dropdowns Large: Uso dento de Listas/Tablas Variante Link Variante Subtitulo Variante Usuario/Entidad
49. Unificando el lenguaje de diseño En base a nuestro diseño 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
50. Tipografía y estilos Escala tipográfica → Aplicamos una escala. Colores 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)
51. Codificando componentes ‣ Definición de la API y del código 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
53. ‣ Se combinan todas las decisiones: clasificación, diseño, código, usos. 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
54. ‣ Incluir solo las partes reutilizables. Usar la regla de 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
55. Armando un equipo DE STYLEGUIDE A DESIGN SYSTEM
56. Armamos un equipo dentro del area de Diseño. Un equipo 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
57. Colaboración EL EQUIPO
58. ‣ La clave es un equipo pequeño pero que pueda 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
59. Herramientas DE STYLEGUIDE A DESIGN SYSTEM
60. https://auth0-cosmos.now.sh/ https://github.com/auth0/cosmos/
61. LIBRERIAS DE COMPONENTES (SKETCH & REACT)
62. SITIO DE DOCUMENTACIÓN
63. AMBIENTE DE DESARROLLO
64. Los design tokens son las variables esenciales del diseño que se utilizan a través del código. Aquí guardamos las variables de color, tipografía, tamaños, espacios, animaciones, sombras, etc. TOKENS
65. Usamos Storybook para generar ejemplos de uso que estresan el componente. Estas historias se chequean contra cada cambio que se introduce TESTING
67. ‣ El valor del design system se verifica cuando el 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
68. Aprendizajes AUTH0
69. Aciertos
70. ‣ Acercarse a los diferentes equipos y escuchar sus problemas. ‣ 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
71. Errores
72. ‣ Al principio hay mucho por hacer y postergamos el 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
73. Desafíos
74. ‣ Cómo el equipo de DS se integra y colabora 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
75. Muchas gracias!
76. • Design Systems de Alla Kholmatova (@craftui) - https://www.smashingmagazine.com/printed-books/design-systems/ • 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
77. Fernando Carrettoni fernando@auth0.com @landitus https://auth0-cosmos.now.sh/ https://github.com/auth0/cosmos/
78. En Auth0 estamos contratando diseñadores!! Visual, Product, Brand y para Design System https://auth0.com/careers