Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Design Systems: Haciendo productos consistentes y escalables.

Design Systems: Haciendo productos consistentes y escalables.

Slides de la charla del 31 de Julio en la Meetup IDF Buenos Aires (@IDF_BsAs) en las oficinas de Auth0

Los temas: Introducción a los Design Systems y los beneficios del uso. El caso de estudio en Auth0: cómo es la solución técnica (Cosmos), los cambios en los procesos y como dar el kick off inicial.

Fernando Carrettoni

July 31, 2018
Tweet

Transcript

  1. Design Systems: Haciendo productos consistentes y escalables. IDF BSAS -

    JULIO 2018 Fernando Carrettoni Design System Lead @ Auth0
  2. ‣ 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
  3. ‣ “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:
  4. ‣ “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:
  5. 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
  6. 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.
  7. ‣ 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
  8. ¿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.
  9. 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
  10. 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
  11. ‣ 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
  12. ‣ 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?
  13. 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
  14. ‣ 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
  15. Capturas de pantalla • Recorrer las pantallas de cada producto

    y tomar capturas de diferentes interfaces. • Agruparlos en categorías según su funcionalidad. INVENTARIO
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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)
  21. 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
  22. ‣ 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
  23. ‣ 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
  24. 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
  25. ‣ 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
  26. 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
  27. Usamos Storybook para generar ejemplos de uso que estresan el

    componente. Estas historias se chequean contra cada cambio que se introduce TESTING
  28. ‣ 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
  29. ‣ 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
  30. ‣ 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
  31. ‣ 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
  32. • 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