A design system maintains the visual and functional elements of IDX in one place. It may include a sketch library, style guide, pattern library, organization principles, best practices, templates, code snippets, and more. Creating and maintaining a consistent UI and UX across every part of your product helps your users intuitively navigate and successfully interact with different sections of your applications without confusion.
Visit http://styleguides.io/examples.html for an extensive list.
Starting with atoms, the smallest module, to build molecules, and molecules to build organisms.
Uses tokens (design variables) to define modules.
It offers a section for content, with guidelines for the tone of voice, grammar, and copywriting tips.
It's an adaptable system of guidelines, components, and tools that support the best practices of user interface design.
It's very detailed and composed of design patterns, code components, and a library of UI assets in Sketch.
It consists of components that are “like elements of a living organism,” where a set of properties defines each component, with its own personality and function.
It's a professional and comprehensive guide to accessibility, components, patterns, utilities, design tokens, and more.
A style guide defines brand identity, design language, voice and tone, writing, and code style.
A pattern library—also known as a front-end style guide, UI library, or component library—defines reusable modules.
Design systems are essential tools for preventing chaos in modern web design and development.
They serve as
Ensure the same experience across all devices and resolutions.
Is this component called a slider, slideshow, or carousel? Establish a shared vocabulary between everyone in an organization, including outside vendors.
Provide helpful documentation to clients, stakeholders, and other disciplines and prove there’s thoughtful work behind IDX design and development.
All disciplines are forced to think of the greater good when they contribute to patterns.
A style guide allows you to view interface patterns in isolation, allowing developers to make cross-browser/device, performance, and accessibility testing easier.
Once the pattern library is established, subsequent design and development become much faster, saving time and money.
Provides a rock-solid, future-friendly foundation for teams to modify, extend, and improve on; even if that future work looks totally different.
What treacherous challenges come with the territory?
It's difficult to convince those with a short-term, quarter-by-quarter mindset that establishing a thoughtful design system is a smart investment in the future.
Aggressive timelines and finite budgets detract from the effort required to make style guides happen, even when teams are committed to the cause.
Treating pattern libraries as something separate from the core project puts them into the nice-to-have category and are dropped when the going gets tough.
Style guides will be abandoned without a proper strategy for who will manage, maintain, and enforce them.
Style guides can be misunderstood as tools useful only to designers or developers, which doesn't foster a culture of collaboration.
It should be welcoming and useful for as many people as possible.
Without providing context, designers and developers don’t know when to use a particular pattern.
Many pattern libraries are little more than loosely arranged modules.
A methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner.
Atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional. They demonstrate all your base styles at a glance.
Molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule. They give abstract atoms purpose.
Organisms are composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface. For example, a header can contain a logo, navigation, and search form.
Templates are page-level objects that place components into a layout and articulate the design’s underlying content structure.
Design systems must account for the dynamic nature of the content, so it’s helpful to articulate image sizes and character lengths for headings and text passages.
Pages show what a UI looks like with real representative content in place. This is what users will see and interact with; this is what stakeholders will sign off; this is where all those components come together to form a beautiful and functional UI. Pages are essential for testing how patterns hold up when real content is applied.
We must create systems that establish reusable design patterns and also accurately reflect the reality of the content we’re putting inside of those patterns.
Atomic design provides a few key insights to create more effective, deliberate UI design systems.
Quickly shift between abstract and concrete, moving from seeing the whole picture down to the smallest component. Atomic design is not a linear process. It would be foolish to design buttons and other elements in isolation, then cross our fingers and hope everything comes together to form a cohesive whole. Don’t interpret the five stages of atomic design as “Step 1: atoms; Step 2: molecules; Step 3: organisms; Step 4: templates; Step 5: pages.” Instead, think of the stages of atomic design as a mental model that allows us to concurrently create final UIs and their underlying design systems.
The close relationship between content and design requires us to consider both as we construct our UIs, and atomic design recognizes the two very much influence each other.
Why introduce terms like atoms, molecules, and organisms when we can just stick with established terms like modules, components, elements, sections, and regions? Atoms, molecules, and organisms imply a hierarchy that anyone with a basic knowledge of chemistry can hopefully wrap their head around. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.
Content audits are usually performed in the early stages of a website redesign process to take stock of all a site’s content. It’s a tedious process involving spreadsheets and caffeine, but all that hard work pays off. By the end of the exercise the organization’s content is laid out on the table, giving teams valuable insights into how to handle their content as they tackle the project.
An interface inventory is similar to a content inventory, only instead of sifting through and categorizing content, you’re taking stock of and categorizing all the components that make up your user interface. An interface inventory is a comprehensive collection of the bits and pieces that make up your user interface.
How do you go about conducting an interface audit? How do you round up all the components that make up your UI? The simple answer is screenshots. Lots of them!
it’s absolutely essential to get all members of the team to experience the pain of an inconsistent UI for them to start thinking systematically. For the interface inventory to be as effective as possible, representatives from all disciplines responsible for the success of the site should be in a room together for the exercise. Round up the troops: UX designers, visual designers, front-end developers, back-end developers, copywriters, content strategists, project managers, business owners, QA, and any other stakeholders. The more the merrier! After all, one of the most crucial results of this exercise is to establish a shared vocabulary for everyone in the organization, and that requires input from the entire team.
The interface inventory exercise generates a ton of screenshots, so naturally, you’ll need software to capture and display those screenshots. Online slide-building software like Google Slides to be very effective as it provides a canvas for free-form image positioning.
The interface audit exercise involves screenshotting and categorizing all the unique UI patterns that make up your experience. Bear in mind this exercise doesn’t mean capturing every instance of a particular UI pattern, but rather capturing one instance of each unique UI pattern.
Assign each participant a UI category. You may need to pair people or have participants document multiple categories, depending on how many people are taking part in the exercise. Once again, it’s helpful to have as many participants as possible since more people screenshotting will result in more thorough documentation.
Obviously, the categories are going to vary from interface to interface, but here are a few categories to start with:
It’s important to set time limits on the screenshotting exercise to avoid going down a rabbit hole that ends up lasting all day. The amount of time you allocate will vary depending on how many people are participating, but I find between 30 and 90 minutes to be sufficient for a first pass of an interface inventory.
Which parts of the site should participants capture in the interface inventory? Short answer: everything. Any piece of UI that is or could be managed by your organization should be documented. Areas like customer support, FAQs, reports, modals, 404 pages, and legal terms should not be neglected.
After a break, it’s time to discuss what's been captured. Have each participant spend five or ten minutes presenting each UI category to the group. Here’s where the fun begins. Presenting to the group allows the team to discuss the rationale behind existing UI patterns, kick-starts a conversation about naming conventions, and gets the team excited to establish a more consistent interface.
Naming things is hard. It’s fascinating to hear the inconsistent names designers, developers, product owners, and other stakeholders all have for the same UI pattern. This exercise is an opportunity to unearth and iron out disparities between pattern labels, and also establish names for previously unlabeled patterns. Once every category has been presented and discussed, all the participants should send their slides to the exercise leader. The leader will then combine everything into one giant über-document, which will soon become a wrecking ball of truth and justice.
With the über-document in hand, it’s time to get the entire organization on board with crafting an interface design system. Laying bare all your UI’s inconsistencies is a great way to make that happen! One of the most powerful benefits of interface inventories is that you can show them to anyone, including non-designers and developers, and they’ll understand why inconsistent UIs are problematic. You don’t need to be a designer to recognize that having 37 unique button styles probably isn’t a good idea.
A smaller, cross-disciplinary team will be going through the über-document and establishing the next steps for the design system. Once the gaps in the interface inventory have been filled, the working group can have some important conversations about next steps for the design system project. Some key questions for this group to cover include:
Creating an interface inventory can be quite an undertaking, but the benefits of making one are many:
Despite all your efforts, the sound idea of establishing an interface design system and pattern library was shot down. What’s a responsible web team to do?
Do it anyway.
For the same reason performance, accessibility, and responsiveness are built into our products; a design system should be built by default. Interface design systems are a means to create great work for our clients and organizations. And to create the whole, you need to create the parts of that whole.
Unfortunately, we humans are creatures of habit, and stepping outside familiarity’s warm embrace is uncomfortable. We don’t like being uncomfortable. We must overcome our existing predispositions if we’re going to embrace our ever-shifting industry’s best practices and create successful digital work.
As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. - Dan Mall
How did we get to the point where we sell and design websites like they’re static images?
A team is tasked with making a website. Once the kick-off meeting dust has settled, a UX designer goes away, puts their head down, and eventually emerges with a giant PDF document detailing the entire experience. This monolithic wireframe document gets passed around to the project stakeholders, who sign it off after some feedback and suggestions.
The UX designer then passes the wireframes to the visual designer, who hops into Photoshop or Sketch to apply color, typography, and texture to the structured-but-sterile wireframes. Behold, a website design! Now for the feedback:
“This looks fantastic, and I think really hits the mark for what we’re trying to accomplish with this project. But…”
Once everyone has rambled off their wish list of what they’d like the design to accomplish, the visual designer retreats back to their tools to work on a redesign.
“I feel like we’re almost there. Could we just…”
Weeks pass and seasons change. Nerves wear thin, and the deadline date looms over everyone’s heads. Finally, the visual designer slips the approved design under the door. They scamper away, yelling, “Can you get this done in three weeks? We’re already behind schedule and we’re out of budget!”
The front-end developer picks the design off the floor. With one glance at the composition, a strange feeling—some combination of bewilderment, rage, and dread—washes over them. The front-end developer tries in vain to raise their concerns to the broader group but is quickly dismissed. It’s too late to make significant changes, especially since it’s already been approved. So the developer tries their best to make lemonade out of the lemony static comps. They bend over backward to create responsive layouts that still retain the integrity of the static comps, normalize some of the more blatant component inconsistencies, establish pattern states (like button hover, active, and disabled states) that weren’t articulated in the designs, and make some on-the-fly decisions.
The team finally launches the site. While no one says it out loud, there’s a tinge of disappointment in the air alongside the joy and relief of getting the project out the door. After all, the live site lacks the glossy polish that the comps promised to the stakeholders, and friction between disciplines has bruised some relationships.
Rather than a rigid, sequential waterfall process, a more collaborative process over time looks something like this:
Here’s the thing: I’ve never had a computer science class in my life, and I spent my high school career hanging out in the art room. Suffice it to say those requests made me extremely uncomfortable.
There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still code, front-end development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many front-end developers, myself included, a severe identity crisis.
Organizationally, there is often a massive divide between designers and developers (or marketing and IT, or creative and engineering, or some other divisive labels). Designers and developers often sit on different floors, in different buildings altogether, in different cities, and sometimes even in different countries on different continents. While some of this organizational separation may be justified, creating a division between designers and front-end developers is an absolutely terrible idea.
Crucially, jumping into the browser faster also kick-starts the creation of the patterns that will make up the living, breathing design system. More on this in a bit.
This is not to say teams must design entirely in the browser. As with anything, it’s about using the right tools at the right time to articulate the right things. Having the design represented in the browser in addition to other design artifacts gives teams the ability to paint a richer, more realistic picture of the UI they’re crafting. Teams may demonstrate an aesthetically focused design idea as a static image, and simultaneously demonstrate a working prototype of that same idea in the browser.