Modular Web Design With Components

I made this talk to help my Design Team colleagues, at [Digital Origin](https://www.digitalorigin.com/), to better understand the importance of designing in a modular way.

Modularity is the key to creating a flexible design system. For a system to be modular, it must have interchangeable parts (components).

Watch my slides if you want to learn Modular Web Design, to reach a smart system of reusable design patterns, interchangeable components, and well-planned system logic.

Transcript

1. Modular Web Design With Components Think modular, think smart
2. [`nadal sol ear] Meticulous Front-end Developer. Proudly coding since 2001. @nadalsol
3. “We’re not designing pages, we’re designing systems of components.” –Stephen Hay
4. Introducing modularity
5. Blocks Components Modules Elements Atoms Molecules Organisms Pages Templates OOCSS SMACSS BEM SUIT CSS Bootstrap Foundation Widgets Material Design
6. “Modularity is the key to creating a flexible design system. For a system to be modular, it must have interchangeable parts (components).” –Dennis Kardys
7. CompoWHAT?
8. What’s a component*? Definition (*) aka module or widget. 1. Generic term for any pre-defined object that you intend to use across multiple pages. 2. In order to be reusable, they must be standardized in appearance and function. 3. Each component will render reliably regardless of the context it's used in.
9. “Think of components as Legos: interchangeable building blocks you can assemble into pages.”
11. The benefits of components
12. The benefits of components 1. Modularity. 2. Extensibility. 3. Testability. 4. Reusability. 5. Consistency.
13. What makes a component modular? 1. Standardized design: Predetermined appearance. 2. Centralized code: Unique code should not be needed each time you reuse the component. 3. Controlled via system logic: Predefined formatting should occur based on system rules, not content author discretion. 4. Customizable: Display, content, and functional options.
14. Modularizing your design
15. Modularizing your design Eliminate discrepancies and boil each component down into a standardized model. Be deliberately lean, removing any page-specific component customization that doesn’t benefit the system as a whole.
18. Define & document system logic To make components reusable, they need rules. Without system logic defining how they can and should be used, we’d be back at freeform design.
19. Define & document system logic Documenting component rules lead to more efficient UI and code. It can provide reference to content authors seeking to understand what components they have access to, and what the expectations and best practices of use are.
20. “Good component logic provides useful constraints.” –Dennis Kardys
21. Component creation process
22. Source: https://design.canonical.com/2016/07/getting-vanilla-ready-for-v1-the-roadmap/
23. Follow the steps 1. Respect your Design System. 2. Check the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
24. Always respect the rules already defined in your Design System. Things like: • Grid • Spacing • Color palette • Typography • etc... 1. Respect your Design System
26. Follow the steps 1. Respect your Design System. 2. Check the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
27. 2. Check the purpose
28. Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
29. Let’s create a new component when... • When you DON’T HAVE an existing component with the same purpose. • When you DON’T HAVE an existing component with the same structure/behavior. Create new component
30. Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
31. Let’s use an existing component... • When you ALREADY HAVE an existing component with the same purpose. • When you ALREADY HAVE an existing component with the same structure/behavior. • When you ALREADY HAVE an existing component with the same appearance (skin). Use existing component
32. Existing component? Purpose Create new component No Yes Same structure/behavior? No Yes Same appearance (skin)? Yes Use existing component Modify existing component No
33. Modify existing component Let’s modify an existing component... • When you ALREADY HAVE an existing component with the same purpose. • When you ALREADY HAVE an existing component with the same structure/behavior. • When you DON’T HAVE an existing component with the same appearance (skin).
35. Beware of Redesigns Avoid redesigns as much as possible (unless there’s a good reason to). Redesign Modify existing component
36. Beware of Redesigns Redesigns may imply code refactors, or even breaking design consistency across different contexts, causing collateral damage (atoms tend to be used in different molecules). Example: Button size (atom) in different contexts (molecules). Redesign Modify existing component
39. Follow the steps 1. Respect your Design System. 2. Check the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
40. At DO we want to be agile, so we're far from creating Functional Specifications Documents (FSD). The FSD is what's given to: • Developers: so they know what to build. • Testers: so they know what to test. • Stakeholders: so they know exactly what's being created. 3. Define expected behavior and interactions
41. Therefore, the best way to describe interaction is to model it with an interactive prototype. In other words... What happens when you interact with elements in the mockup? 3. Define expected behavior and interactions
42. 3. Define expected behavior and interactions
43. Follow the steps 1. Respect your Design System. 2. Check the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
44. Context is important Always test your new component proposal in many contexts, in order to detect different use cases, as well as possible inconsistencies. 4. Consider context
45. Follow the steps 1. Respect your Design System. 2. Check the purpose. 3. Define expected behavior and interactions. 4. Consider context. 5. Dogfood your Design System.
46. Last, but not least... Don’t forget to update your Design System with whatever changes you made. 5. Dogfood your Design System
47. A classic problem
48. I’m a developer. What do you expect me to implement?
49. Imagine you're designing a new popover component. I’m a developer. What do you expect me to implement?
50. In order to build and test popovers, Developers and Testers need to know: • Do you expect to be dismissible? • Do you expect to be repositioned (i.e. on window resize)? • Do you expect to be placed on top, right, bottom, left? • Do you expect the same behavior on mobile and desktop devices? • etc... I’m a developer. What do you expect me to implement?
51. Anatomy of a component
53. Let's take a real world example, based on DO Notification component. Anatomy of a component
55. How this component could be affected? 1. Different appearance (skin): yellow background, green background… 2. Different content (structure): message only, message plus heading, message plus action… 3. Different interaction: always visible, flash message (toast), dismissible, contextual messages... Anatomy of a component
56. When you need to change your component appearance (skin) or content (structure), but not its purpose, CSS modifiers are handy. Other examples: • Notification: alert, success, info... • Button: small, medium, large... • Popover: top, right, bottom, left... • etc... Anatomy of a component
57. The cost of creating new components
58. What do you think? Let’s discuss...
59. “It’s not just about using a design system, it’s about creating your system.” –Brad Frost
60. Q&A
61. References: Atomic Design, by Brad Frost. Modular Web Design: Designing With Components, by Dennis Kardys. SMACSS (Scalable and Modular Architecture for CSS), by Jonathan Snook. BEM (Block Element Modifier) methodology. My own experience ;)
62. Made with love by @nadalsol , on Nov. 2017