Menu Search
Jump to the content X X
Smashing Conf New York

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

Designing Modular UI Systems Via Style Guide-Driven Development

Using a style guide to drive development is a practice that is gaining a lot of traction in front-end development — and for good reason. Developers will start in the style guide by adding new code or updating existing code, thereby contributing to a modular UI system that is later integrated in the application. But in order to implement a modular UI system, we must approach design in a modular way.

Modular design encourages us to think and design a UI and UX in patterns. For example, instead of designing a series of pages or views to enable a user to accomplish a task, we would start the design process by understanding how the UI system is structured and how its components can be used to create the user flow.

Further Reading on SmashingMag: Link

In this post, I’ll explain the value of modularity in UI design and how it ties into the process of style guide-driven development5, which improves the implementation of flexible and user-friendly applications, while helping designers and developers collaborate more productively.

Modular Design In The UI Link

Modular design is about breaking down a design into small parts (modules), creating them independently, and then later combining them into a larger system. If we look around us, we will find many examples of modular designs: Cars, computers and furniture are all modular. Because of their modularity, parts of these systems can be exchanged, added, removed and rearranged. This is great for consumers because they get to customize the system to fit their needs. Do you want a sunroof, a more powerful motor, leather seats? You got it! The modular design of cars allows for these types of customizations and much more.

Another great example is IKEA furniture. In the illustrations below, you can see that the modularity of the design is not only in the shape of the bookcase, which allows it to be set in different directions, or in that you can add inserts in its openings, but also in the very parts that make the piece itself, which are rectangles of different sizes, repeating the same pattern.

Ikea Kalax bookcase shown during assembly6
(View large version7)
Ikea Kalax bookcase assembled8
(View large version9)
Ikea Kalax Bookcase insert10
The design of the Kallax bookcase by IKEA is a great example of modularity and customization: Modular parts are used to build the bookcase, and additional sections can be inserted to add functionality. (Image: IKEA11) (View large version12)

From a manufacturing perspective, modular design is also cost-efficient. One important aspect of this is that building small simple parts that can be connected later is easier and cheaper than building one large complex piece at once. Additionally, the solution can be reused over and over, maximizing productivity.

The goals in creating a UI design are similar. As designers, we want to create a UI system that is efficient in both construction and operation. When we find a solution to a problem, we want to be able to reuse the solution in many places. This not only saves time, but also establishes a pattern that users can learn once and reapply in other areas of the application. We also want to be able to customize the system for certain scenarios without having to restructure everything.

This is exactly what modularity brings to UI design: It leads to a system that is flexible, scalable and cost-efficient, but also customizable, reusable and consistent.

Examples of Modular Design Link

Some examples of modular UI design can be seen in patterns such as responsive grids, tile window design and card design. In all of them, modules are used repeatedly to provide a flexible layout that easily adapts to different screen sizes. In addition, the modules act as containers for components, enabling us to insert different types of content and functionality, much like the inserts that can be added to an IKEA cabinet.

Example of a responsive grid from the Bootstrap framework (Image: Bootstrap13) (View video14)
NASA home page15
NASA uses Bootstrap’s grid to display a card layout. (Image: NASA16) (View large version17)
pinterest.com grid page18
The card design used in a masonry layout on Pinterest (Image: Pinterest19) (View large version20)

Is This Homogeneous? Link

If modular design is about designing a system, and UI systems mostly comprise the same parts (buttons, typefaces, icons, grids, etc.), then you might be wondering:

  • Aren’t modular designs all going to look the same?
  • How will this affect brand identity?
  • How can the UI of a product be made to be unique?

These questions, while valid, raise an underlying question: Where do innovation and uniqueness in product design lie? This debate has picked up lately (see “The Unbearable Homogeneity of Design21” and “In Defense of Homogeneous Design22”), but I would say that, because visual design is what we see first, we tend to think that innovation and uniqueness lie in the way a design looks. However, visual design is just one part of that. Innovation and uniqueness in product design need to be accounted for in the entire product: in the intrinsic value that it provides and in the way people experience it, which includes its appearance.

Take a chair. It is required to be a chair, but not all chair designs look, feel or work the same. In fact, chair design has historically been an area of innovation in design and materials. Similarly, UIs have their own requirements, and using patterns that are proven to work doesn’t mean sacrificing innovation and uniqueness. On the contrary, innovation and uniqueness will be needed to solve the particular problems your customers have. The beauty of modular design is that it encourages us to approach these solutions as a system of parts that are interconnected, rather than to find original solutions in an isolated way for the sake of being different. In other words, an innovative design applied to a UI control won’t stay relegated to one place in the application, but instead will permeate the entire system, maintaining cohesion and improving usability.

The Modularity Of Style Guide-Drive Development Link

From the implementation side, style guide-driven development is also very modular. For starters, the process begins with a discovery phase: understanding the problem that needs to be solved, gathering requirements and iterating through design solutions. While the design solutions are usually presented as an entire package or feature, they should really be the combination of the many parts of the system documented in the style guide. Some parts of the design might be new, but they should still be created as modules. The point is to use the style guide to determine which modules are available in the UI system that can be reused or extended to create the design.

(What if there is no style guide? Do not fret! I will show you in the next section how to design in a modular way, even if you are not using a style guide.)

The next step in style guide-driven development is the abstraction phase, which is basically the exercise of breaking down the design solution into smaller parts. During this phase, designers and developers work together to discern the proposed design and identify the elements and components (i.e. modules) that will be either used or enhanced or that will need to be created for implementation.

Style guide driven development process graphic23
Style guide-driven development in a nutshell (View large version24)

The abstraction phase serves as well to trace a plan for the next step: implementation and documentation. During this phase, the modules are either built or enhanced in isolation from the rest of the existing modules. In web development, this means building a component or defining the styles for an element independent of the application. This is an important aspect of modularity, because it helps you to identify any problems early in the process, preventing unforeseen dependencies with other parts of the system. The result is more stable parts that are easier to integrate in the whole.

Something unique about style guide-driven development is that, while implementation progresses, documentation also takes place, rather than being an afterthought. This is possible because when a style-guide generator is used, the documentation becomes a living style guide, serving as both a framework and a sandbox for implementation:

  • The living style guide serves as a framework of definitions for UI elements (such as headings, lists, links, input controls, etc.) and as a library of components (such as navigation systems, toolbars, search tools, grid tables, etc.) that are available for use. This means that development is not started from scratch every time. Instead, it builds upon existing definitions in the UI system and contributes to it.
  • It is also a sandbox because it serves as a demonstration space to build and test the implementation. This is exactly where the development takes place before it is integrated in the application.

The last step of style guide-driven development, the integration phase, resembles the assembly step in modular design. The UI elements or components that are needed have been developed and are ready to be integrated in the application. What remains is to configure and customize them. During integration, the style guide is like any good instruction manual that is used to assemble a physical modular design.

Now that we have identified the fundamental concepts of modular design and style guide-driven development, let’s put them to use.

Designing In A Modular Way Link

Picture this: You have come up with a great user flow, put together mockups and prototypes to illustrate the interactions, and documented every single part. Chances are that your designs already follow a style guide, which could put you at a great advantage. (If not, don’t sweat it!) Just step back and start mapping out the main parts of your design solution at a high level. These parts could be the interaction points where certain things are accomplished. For example, a checkout flow could look like this:

Checkout flow graphic25
Illustration of checkout flow (View large version26)

But hold your guns! These are not modules yet. To get to there, we need to identify the UI elements that are persistent in the flow, such as:

  • the checkout steps indicator,
  • form elements used to enter information,
  • the representation of products in the cart,
  • the representation of related products that others have bought,
  • policies about the purchase,
  • help text,
  • messages and alerts.
Mockup design of a cart page27
Mockup design of the cart page (View large version28)
Mockup design of a shipping page29
Mockup design of the shipping page (View large version30)
Mockup design of a billing page31
Mockup design of the billing page (View large version32)
UI elements extracted from the designs33
Some of the UI elements that persist in the design (View large version34)

Digging a little deeper, we will also find styles and interaction patterns:

  • Styles:
    • colors used to denote:
      • error, success, warning and information messages;
      • primary versus secondary actions;
      • inactive versus selected versus disabled states;
      • links versus regular text;
      • branding;
    • typography used to denote different types of content:
      • font size for laying out information hierarchically;
      • font types for highlighting messages or providing additional information;
      • lists to summarize information;
    • iconography to convey visual meaning and for quick reference to common actions.
  • Interaction patterns:
    • showing upcoming steps (disabled);
    • showing previous steps (enabled so that the information can be edited);
    • displaying summaries that can be edited;
    • validating information once the user has clicked out of the field;
    • providing help text on rollover;
    • updating the cart once a selection has been made.
Styles extracted from the designs35
Some of the styles persistent in the design (View large version36)

Once the design has been broken down into all of these smaller pieces, we will finally have our modules. At this point, it’s easier to see that a lot of them apply not only to the checkout process, but to many other areas of the application. With a modular design approach, these modules can be created so that they are usable in this particular design as well as in future ones.

Atomic design37 is worth mentioning as a methodology that can accelerate this process of creating modular designs. This methodology analyzes the relationships between the different parts of the system and how they interrelate, using chemistry as an analogy. Going through the steps is pretty much the reverse of our previous exercise:

  1. We start from the atoms, which are the smallest modules in the system (in our example, the buttons, typography and iconography).
  2. The modules grow in complexity, binding together into molecules, which provide more functionality (in our example, the checkout steps indicators and the related products module).
  3. Then, there are organisms, which are molecules that are grouped together in the application (in our example, the application’s header and various forms).
  4. Leaving the chemistry analogy, the next level is the templates, which are predefined structures where organisms are placed.
  5. Lastly, there are pages, which are instances of templates.

The missing piece here is a way to document the modules that have been identified. This is not only a matter of creating a specification document to capture how the modules need to be built, or writing guidelines that capture high-level definitions such as brand colors and font families (which are typical of any standard style guide). Rather, the documentation needs to be more sophisticated and dynamic, so that when these modules change (and you know they will!), the documentation doesn’t become obsolete. This is exactly where living styles guides fill in the gap!

Using A Living Style Guide Link

A living style guide can be very useful during the design process because it provides several things.

A Baseline to Work With Link

Instead of starting from scratch every time, the style guide provides the visual direction and the modules you should use to create the design.

Because a living style guide is generated from actual code, it reflects the latest and greatest version of the implemented design.

Documentation of Design Solutions Link

The knowledge that has been acquired to resolve a particular UI or UX problem can be consigned for later use.

This helps to maintain consistency in the implementation, encouraging you to fit any new solution into part of the current design.

You will be developing patterns that users can get familiar with, thus enhancing usability.

Ease of Communication Link

The guide helps to communicate the design by providing the most up-to-date representation of the UI (unlike static mockups, which get outdated quickly).

A common UI language is developed because you have to name the various elements in the style guide. This requires collaboration not only among UI designers, but between the designers and developers, which is a great advantage when you have to communicate how a design should be implemented.

Whether you have an existing style guide or are planning to create one, automating the process will put you in the right direction, driving the design process in a modular way. So, if you are ready to shop for a generator of living style guides, then I’d recommend the following resources:

Don’t Take It To The Extreme! Link

Now that we have looked at how to finetune the design process to incorporate modularity, as well as the advantages of a living style guide, let’s explore some of the common pitfalls you might encounter along the way.

The Style Guide Does Not Replace Design Work Link

It’s not uncommon to hear from managers that, once the living style guide is in place, most of the design work is done. While a lot of the repetitive and trivial work is done (like prototyping the different states of a button over and over), consider that:

  • new features will continually need to be built,
  • finding a solution involves making design decisions.

So, yes, having a living style guide and following style guide-driven development improves the development workflow, but it doesn’t take the designer out of the equation. Having a tool that speeds up workflows and boosts communication is advantageous to both designers and developers. But the great thing about this approach is that it allows a lot of room for the UI to be customized, thereby enhancing the user experience — and figuring that out is part of the designer’s role.

Don’t Follow Patterns to the Extreme Link

We should always strive to use patterns in an application. For example, consistent use of colors and font sizes can quickly indicate to the user elements in the UI that can be interacted with. However, avoid using a pattern just because it has been implemented before; rather, use it because it really solves the problem at hand.

For example, if you have established the pattern of displaying toolbars at the top of the screen, this pattern will work in most cases, but there will be times when presenting a contextual toolbar, closer to where the user is taking action, makes more sense. So, always question whether reuse of a pattern prioritizes ease of implementation over the user experience.

Don’t Overlook Design Iteration Link

This ties in a bit to the previous point. Don’t overlook the value of iteration and innovation when trying new patterns and finding ways to design an interface, even if at first sight they do not follow the style guide. The style guide should not be a rein on your effort to create the best user experience possible. Rather, as the name suggests, it should be a guide, a starting point to help you resolve problems by tapping into previous work and experience. Iteration during the design phase should continue to be as important as ever and should spur you to improve on established patterns.

The Maintenance Burden Link

Among the gazillion things your job involves, maintaining the style guide should be the last thing that feels like a burden. To overcome this, I find the following practices helpful:

  • Find a documentation system that is easy to install and easy to interact with on a regular basis.
  • Make documentation updates a part of your workflow, rather than an afterthought once the implementation is already out. Document as you go!
  • Establish guidelines that make it easy for everybody to contribute to the documentation. This will distribute the workload and increase the sense of ownership.

Design Modular To Build Modular Link

Creating a flexible UI system that is consistent and easy to customize, while also scalable and cost-efficient, depends not only on how it is built, but on how it is designed. A library of components has very little value if every new design is created independently, ignoring established standards and patterns.

On the flip side, it’s not about making cookie-cutter interfaces that reuse the same styles and patterns because it’s convenient. A good design is effective not because of its uniqueness, but because it combines both form and function to create a great experience. This goal should always be top of mind, and using a method such as style guide-driven development to bring modularity to both design and development should help you to create a cohesive UI system that achieves this goal.

(cc, ml, al, il)

Footnotes Link

  1. 1 https://www.smashingmagazine.com/2014/02/effective-style-guides-with-adobe-fireworks/
  2. 2 https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-style-guide-tools/
  3. 3 https://www.smashingmagazine.com/2015/03/automating-style-guide-driven-development/
  4. 4 https://www.smashingmagazine.com/2011/06/free-style-guides-icon-set-for-writers-and-editors/
  5. 5 http://blog.bitovi.com/style-guide-driven-development/
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-ikea-kalax-bookcase-parts-opt.png
  7. 7 https://www.smashingmagazine.com/wp-content/uploads/2016/03/01-ikea-kalax-bookcase-parts-opt.png
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2016/03/02-ikea-kalax-bookcase-opt.png
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2016/03/02-ikea-kalax-bookcase-opt.png
  10. 10 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-ikea-kalax-insert-opt.png
  11. 11 http://www.ikea.com/
  12. 12 https://www.smashingmagazine.com/wp-content/uploads/2016/03/03-ikea-kalax-insert-opt.png
  13. 13 http://getbootstrap.com/
  14. 14 https://vimeo.com/161011132
  15. 15 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-nasa-homepage-cards-grid-design-opt.jpg
  16. 16 https://www.nasa.gov/
  17. 17 https://www.smashingmagazine.com/wp-content/uploads/2016/03/04-nasa-homepage-cards-grid-design-opt.jpg
  18. 18 https://www.smashingmagazine.com/wp-content/uploads/2016/03/05-pinterest-card-desing-opt.jpg
  19. 19 https://www.pinterest.com/
  20. 20 https://www.smashingmagazine.com/wp-content/uploads/2016/03/05-pinterest-card-desing-opt.jpg
  21. 21 https://medium.com/@morgane/the-unbearable-homogeneity-of-design-fe1a44d48f3d#.2ju7zhzig
  22. 22 https://medium.com/@yarcom/in-defense-of-homogeneous-design-b27f79f4bb87#.n0te3zqme
  23. 23 https://www.smashingmagazine.com/wp-content/uploads/2016/03/06-style-guide-driven-developement-process-opt.jpg
  24. 24 https://www.smashingmagazine.com/wp-content/uploads/2016/03/06-style-guide-driven-developement-process-opt.jpg
  25. 25 https://www.smashingmagazine.com/wp-content/uploads/2016/03/07-checkout-flow-opt.png
  26. 26 https://www.smashingmagazine.com/wp-content/uploads/2016/03/07-checkout-flow-opt.png
  27. 27 https://www.smashingmagazine.com/wp-content/uploads/2016/03/08-app-mockup-01-cart-opt.png
  28. 28 https://www.smashingmagazine.com/wp-content/uploads/2016/03/08-app-mockup-01-cart-opt.png
  29. 29 https://www.smashingmagazine.com/wp-content/uploads/2016/03/09-app-mockup-02-shipping-opt.png
  30. 30 https://www.smashingmagazine.com/wp-content/uploads/2016/03/09-app-mockup-02-shipping-opt.png
  31. 31 https://www.smashingmagazine.com/wp-content/uploads/2016/03/10-app-mockup-03-billing-opt.png
  32. 32 https://www.smashingmagazine.com/wp-content/uploads/2016/03/10-app-mockup-03-billing-opt.png
  33. 33 https://www.smashingmagazine.com/wp-content/uploads/2016/03/11-app-elements-opt.png
  34. 34 https://www.smashingmagazine.com/wp-content/uploads/2016/03/11-app-elements-opt.png
  35. 35 https://www.smashingmagazine.com/wp-content/uploads/2016/03/12-app-styles-opt.png
  36. 36 https://www.smashingmagazine.com/wp-content/uploads/2016/03/12-app-styles-opt.png
  37. 37 http://bradfrost.com/blog/post/atomic-web-design/
  38. 38 https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-style-guide-tools/
  39. 39 https://github.com/davidhund/styleguide-generators
  40. 40 http://alistapart.com/blog/post/style-guide-generator-roundup

↑ Back to top Tweet itShare on Facebook

Adriana De La Cuadra is a UX designer at Bitovi, a Design and JavaScript development consulting company in Chicago that authors and maintains several open source JavaScript front-end frameworks, including CanJS and DoneJS.

Through her consulting work Adriana has had the opportunity to work with Fortune 500 Companies, working in the design of large e-commerce sites and complex internal applications. She likes to geek about documentation and homemade bread. You can read more of her design articles on the Bitovi blog.

  1. 1

    Dani Kelley

    June 15, 2016 3:08 pm

    Thank you so much for such a fantastic article! I’m primarily a designer who knows how to code and keeps up with web standards enough to be able to offer lots of support for my coworker (my office’s developer), and this article puts words to a lot of how we approach building our websites. Having those words (and seeing how we can break down our process to be even more efficient) is so valuable and will be really great to help us keep on the same page and explain to higher-ups and our clients why we’re doing things the way we are. Thank you!

    1
    • 2

      Adriana De La Cuadra

      June 15, 2016 3:59 pm

      Dani Kelley thanks for reading!

      Modular Design and SGDD has really helped us and our clients at Bitovi to get on the same page while getting more efficient at both design and development. Looking forward to hear how this approach works for you. Cheers!

      2
  2. 3

    Arturo Leal

    June 15, 2016 5:48 pm

    Hi Adriana,

    Really great article!, This is exactly what I was planning to do in my current project, we are on the discovery phase for a very complex enterprise app, the fact that we still dont know all the details and an Agile environment makes Modular Design a perfect fit in my opinion.

    Thanks!

    2
    • 4

      Adriana De La Cuadra

      June 15, 2016 6:26 pm

      That’s excellent Arturo Leal! As a matter of fact, we went with this approach for an enterprise client with whom we built an internal UI framework, and it has worked really great as any design and development that is done for the framework benefits any apps using it. Basically the UI framework is a Living Style Guide that many apps use.

      Also in an agile environment, we opted for breaking down our stories in “implementation of the design into the framework” and then “integration of that implementation into the application”. This helped greatly with chunking out the work and doing better story estimations (sometimes the first part was not even needed as we were reusing an existing pattern, win!)

      Best luck in your project!

      3

↑ Back to top