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.

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
PagesTemplates
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)?
YesUse 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)?
YesUse 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)?
YesUse 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