Designing for Reuse with a System
•
1 recomendación•283 vistas
Para poder acometer un reto tan grande como es pivotar el modelo de negocio de una empresa en muy poco tiempo debíamos mejorar la forma en la que trabajábamos. Uno de los cambios fue empezar a usar Atomic Design para diseñar las aplicaciones móviles. En esta charla os contaré el recorrido para implementar este sistema de diseño en la app de Jobandtalent. Con errores y con aciertos. Con logros, ventajas, mejoras y mucho aprendido.
Recomendados
Más contenido relacionado
Similar a Designing for Reuse with a System
Similar a Designing for Reuse with a System (20)
Último
Último (7)
Designing for Reuse with a System
- 1. Working with a Design System
- 3. We Are Hiring! @jobandtalentEng
- 4. De qué vamos a hablar
- 7. Pivotando de Job Board a una Staff Agency
- 8. ◆ Numerosos equipos involucrados. Trabajo en paralelo ● Producto - Diseño - Backend - Celulares ◆ Gran reto a nivel de producto ◆ Features nuevas y diferentes ◆ Un nuevo look & feel Transformar Jobandtalent en 100 días
- 11. ¿Cómo podemos conseguirlo? ● Coordinación ● Paralelización ● Consistencia ● Anticipación ● Rapidez
- 12. Design System
- 13. “A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications” Fuente: Will Fanguy en https://www.invisionapp.com/blog/guide-to-design-systems/
- 16. Diseñar como un desarrollador ● Encapsulación ● Abstracción ● Reutilización ● Polimorfismo● ● “El clean del diseño”
- 19. Iteración I
- 20. Decisiones, decisiones y muchas decisiones ● Modelar componentes a lo android way: Styles + Resources + Layout XMLs ● Folder de recursos independientes: res-tx ● NO usar Custom Views, sólo por causa mayor (Includes + merges) ● Lógica de negocio fuera de los componentes
- 23. Retrospectiva Iteración 1 ✔ ¿Ha sido sencillo crear componentes? ✔ ¿El diseño es consistente? ✔ ¿Nos ayuda el sistema de diseño? ❌ ¿Escala bien?
- 24. Problemas para escalar ● Duplicidad de recursos y de XMLs ● Componentes no documentados ● Se pierde la encapsulación ● ¿Y la lógica de renderizado? ● Velocidad de desarrollo, pruebas y verificación. Dolor ● ¿Cómo afectan los cambios? ● ¿Es fácil que se haga una revisión de diseño?
- 25. Iteración II
- 26. ✔ Duplicidad ✔ Lógica renderizado ✔ Consistencia ✔ Documentación Un paso más Componente 1:1 CustomView
- 27. Custom Views ● Cada componente es una Custom View ● Modelar estado -> ViewState ● Configurable por Atributos (en la medida de lo posible) ● Estandarización, estandarización y más estandarización ● Lógica de renderizado ○ Utilidades Visibility, LineSpacing, SupportVersion, TintCompat... ● Lógica de negocio -> Golpe de Remo
- 29. ✔ Velocidad desarrollo ✔ Respuesta a cambios ✔ Versionado ✔ Evitar duplicidad Un paso más Librería de componentes
- 30. Komponents Library ● Artefacto independiente a la aplicación de JT ● Maven privado ● Gestión de versiones X.Y.Z ○ X = Versión del sistema de diseño ○ Y = Nuevo/s componentes y/o cambios incompatibles ○ Z = Fixes ○ -SNAPSHOT ● Deploy local y remoto ● Actualización versión en el proyecto de JT mediante PR Components Library
- 32. ✔ Design Review ✔ Velocidad desarrollo Un paso más App de prueba
- 36. Aplicación de prueba ● Fixtures ● IconKit
- 37. Aplicación de prueba ● Fixtures ● IconKit ● FontKit
- 38. Aplicación de prueba ● Fixtures ● IconKit ● FontKit ● ColorPalette
- 39. Aplicación de prueba ● Fixtures ● IconKit ● FontKit ● ColorPalette ● Playgrounds
- 40. Sensaciones Iteración 2 ✔ El equipo siente que todo es más consistente ✔ La reutilización de componentes es óptima, mayor desacoplo ✔ El equipo de diseño puede jugar/tocar/validar los componentes antes de ser usados en la app ✔ Aplicamos cambios globales facilmente - ProximaNova a Roboto & color branding ❌ Naming inconsistente ❌ Hacer test de Espresso es tedioso ❌ ¿Cómo iterar un componente? ¿Cuando se debe segregar? ❌ Dificultades en cómo comprobamos la integridad ❌ ¿Se puede mejorar la comunicación con el equipo de diseño?
- 41. Iteración 3
- 42. ✔ Hacer test de Espresso es tedioso Otro paso más Librería con matchers y actions de Espresso.
- 44. ✔ Verificar integridad global Otro paso más Screenshot UI reports & Components UI testing
- 46. En qué estamos trabajando...
- 49. Preocupados en... Rich Item ??!?
- 50. Preocupados en... Rich Item ??!??!?1!1?
- 51. Después de 1 año ● Mejor coordinación Diseño -> Developers ● Paralelización ● Consistencia ● Anticipación ● Rapidez
- 52. ¡Os quiero!
- 55. ¿Debería motivar el uso de un sistema de diseño en mi empresa?
- 56. ¿Preguntas? We Are Hiring! Android, Frontend, Designer, Data Science, Ruby & Rails, PMs… https://bit.ly/2wGYJYe