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.
In this post, I’ll explain the value of modularity in UI design and how it ties into the process of style guide-driven development, which improves the implementation of flexible and user-friendly applications, while helping designers and developers collaborate more productively.
Modular Design In The UI
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.
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.
Atomic design 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:
We start from the atoms, which are the smallest modules in the system (in our example, the buttons, typography and iconography).
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).
Then, there are organisms, which are molecules that are grouped together in the application (in our example, the application’s header and various forms).
Leaving the chemistry analogy, the next level is the templates, which are predefined structures where organisms are placed.
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
A living style guide can be very useful during the design process because it provides several things.
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.
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.
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.
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.
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.
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.
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.