Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Why what who when

193 visualizaciones

Publicado el

Cuatro preguntas sencillas para poder abordar la gran complejidad que lleva la creación, adopción y mantenimiento de un Sistema de Diseño

Publicado en: Diseño
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Why what who when

  1. 1. Why, what, who, when.
  2. 2. Hola!Soy Alfonso Morcuende @NOAMMORRISSEY
  3. 3. Demanda Escala Tecnología Diseño
  4. 4. Demanda Escala Tecnología Diseño
  5. 5. “Never before has anything been created that was more elegant or better in its conception, more exact in its execution, or fit for its use.” Le Corbusier
  6. 6. Demanda Escala Tecnología Diseño
  7. 7. THONET.REALIZED.ES
  8. 8. Why What Who When
  9. 9. Why¿Por qué estamos construyendo un Sistema de diseño?
  10. 10. 1.El motivo para crear un DSL no es diseñar menos, es diseñar mejores productos. “Less is more work.” – Patric McCue
  11. 11. 2.Equipos enfocados en problemas importantes, no en tareas repetitivas. “Get rid of everything that is not essential to making a point” – Christoph Niemann
  12. 12. 3.Definir comportamientos estándar crea conocimiento y elimina subjetividad. “Ordo Ab Chao” - Lema del grado 33 en la Scottish Rite Freemasonry.
  13. 13. The Challenge Statement¿Qué resolverá este sistema? ¿Quiénes podrían ser parte de la solución/equipo? ¿A qué productos servirá inicialmente? ¿Quiénes, de momento, están fuera de la solución?
  14. 14. Equipos Consumidores Individuos Productores Dueños del Sistema Aliados y Defensores Otros Equipos
  15. 15. 1. Consistencia Lo más importante es la coherencia en las soluciones que aportamos a nuestros usuarios. (Coherencia en el diseño)
  16. 16. 2. Eficiencia Lo que más valoramos es la velocidad en la que somos capaces de implementar una solución. (Rapidez en el desarrollo)
  17. 17. 3. Calidad Lo sustancial en nuestros productos es “La perfección en la experiencia digital" respecto a la tarea o problema de nuestros usuarios.
  18. 18. 4. Escala Lo valioso es lo reusable. En cada nuevo desarrollo valoramos muy positivamente la reutilización de soluciones anteriores.
  19. 19. 5. Comunicación La alineación en el vocabulario que usamos entre equipos (diseño / desarrollo / mkt / BM) es lo más importante en este proyecto.
  20. 20. Lenguaje visual Componentes UI Cultura y valores Racional de marca Nuestro Sistema contempla… Voz y tono Patrones de diseño Accesibilidad
  21. 21. Librerías de diseño Design Tokens HTML & CSS JavaScript (React, Vue) Consumibles de nuestro Sistema… Código de plataforma (iOs, Android, WMP)
  22. 22. Racionales de diseño Componentes Lenguaje visual Guía de marca Documentamos nuestros… Principios de diseño
  23. 23. Un equipo dedicado ¿candidatos? Colaboradores especialistas internos ¿nombres? Un Product Owner ¿nombre? Aliados y defensores ¿nombres? El equipo debería de esta compuesto por… Consultores expertos externos ¿candidatos?
  24. 24. CONSISTENCIA (COHERENCIA EN EL DISEÑO) Trabajaremos en resolver nuestros problemas de UN LENGUAJE VISUAL, COMPONENTES UI, NUESTRA CULTURA Y VALORES Y UNA DEFINICIÓN DE NUESTRA VOZ Y TONO. Creando un Sistema de Diseño que contendrá LIBRERÍAS EN SKETCH PARA DISEÑO, DESIGN TOKENS Y HTML & CSS DE LOS COMPONENTES INCLUIDOS Los consumibles de este Sistema serán UN RACIONAL DE DISEÑO, COMPONENTES REALES DE CÓDIGO Y UNOS PRINCIPIOS DE DISEÑO QUE NOS AYUDE EN SU CONSTRUCCIÓN La documentación detallará UN PRODUCT OWNER (NOMBRE) Y UN EQUIPO DEDICADO (CANDIDATO 1, CANDIDATO 2) Será ejecutado por un equipo formado por NOMBRE EQUIPO 1, NOMBRE EQUIPO 2 El/los primeros equipos interesados en usar el Sistema son
  25. 25. What¿Qué componentes vamos a construir? ¿Qué Roadmap tiene sentido?
  26. 26. Small Actions Big Impact ¿Cuál es la forma más efectiva de enfrentarse a la deuda de diseño? ¿Qué automatizamos que nos permita ahorrar MUCHO tiempo?
  27. 27. Calculadora de deuda de diseño
  28. 28. Calculadora de deuda de diseño
  29. 29. Generador de Primitives. Librerías, documentación y tokens
  30. 30. Who¿Quién va a construir el sistema?
  31. 31. From Two To Many Uno no es un equipo. Algo hecho en ratos libres no es un proyecto. ¿Cómo creamos y documentamos para un equipo?
  32. 32. EQUIPO MÍNIMO DE DOS DISEÑADOR + DESARROLLADOR DE FRONT
  33. 33. EQUIPO MÍNIMO DE DOS DISEÑADOR + DESARROLLADOR DE FRONT EL EQUIPO DSL DETERMINA LAS FORMA Y PERSONAS QUE APORTAN
  34. 34. When¿Cuándo y cómo va a ser consumido el sistema?
  35. 35. I love It When a plan Comes Together ¿Cuál es el plan para que otros equipos consuman el Sistema?
  36. 36. “You can show how adoption works by depicting how to go from an initial commitment to full adoption via incremental achievements based on specific criteria.” Nathan Curtis
  37. 37. IncrementalBig Bang
  38. 38. IncrementalBig Bang
  39. 39. 4Rock the Race 3Training Plan 2Get the Gear 1Sign up for the Race0Out of System
  40. 40. 4Rock the Race 3Training Plan 2Get the Gear 1Sign up for the Race Color Fuentes Iconos 0Out of System
  41. 41. 4Rock the Race 3Training Plan 2Get the Gear 1Sign up for the Race Color Fuentes Iconos V. Tipográficos Spacing Grid Botones Formularios 0Out of System
  42. 42. 4Rock the Race 3Training Plan 2Get the Gear 1Sign up for the Race Color Fuentes Iconos V. Tipográficos Spacing Grid Botones Formularios Tokens Modales G. Errores 0Out of System
  43. 43. 4Rock the Race 3Training Plan 2Get the Gear 1Sign up for the Race Color Fuentes Iconos V. Tipográficos Spacing Grid Botones Formularios Tokens Modales G. Errores Componentes Tablas de datos Markup Voz y tono Patrones 0Out of System
  44. 44. Why What Who When
  45. 45. Ada Lovelace Ray Eames Patricia Moore Erika Hall
  46. 46. Gracias! @NOAMMORRISSEY

×