How to use wireframes with design systems

Leon Barnard
We’ve moved to freeCodeCamp.org/news
6 min readDec 17, 2018
Photo by Med Badr Chemmaoui on Unsplash

In my 10+ years as a UX designer, one of the most frequent questions I’m asked about wireframes is how much visual detail to put into them.

There’s an attractive elegance to a simple black and white sketch, but it can sometimes lead to gaps in the shared understanding of what the final product will really look like.

Wireframes shine during the early phases of product development when ideation and rapid iteration are most valued. But what makes them ideal for this phase also hinders them in the next phase, when pixel precision and visual details are called upon for implementation.

As a result, many people (I’ve been guilty of this) try to incorporate fine-grained and aesthetic details into their wireframes by tuning fonts, adding colors, and using other visual effects.

This can often lead to confusion when these proto-high-fidelity wireframes are used as implementation specifications and sent “over the wall” to the development team. Most wireframing tools are not optimized for creating artifacts that look and feel like a finished product. Yet creating polished renditions of every screen or a high-fidelity prototype is time consuming and may not translate well to the final product anyway.

But, is there another way?

There sure is! A way where you can keep your wireframes low fidelity, yet achieve that powerful shared understanding of the implemented look and feel.

Design Systems to the Rescue

An alternative to pushing wireframes beyond their limits is to keep them low fidelity and let another tool do the work of specifying the look and feel.

In this article, I’ll explain why, for web applications and sites at least, an excellent tool for this job is a design system.

Before diving in, let’s define what a design system is.

Like their precursor, style guides, design systems define the application’s look and feel. They go one step further though, in that they often define behavior as well and are backed by working code.

Large companies have been using design systems for a long time. Until recently, they were too labor intensive for smaller companies, as they often required dedicated designers and developers working outside of the primary product teams.

Here is an example, from the IBM Carbon Design System, showing appearance and code for buttons.

Carbon Design System buttons

The design system landscape changed after the Bootstrap framework was released in 2011. It is a free starter kit for web development that provides compliant, robust HTML templates and generally good-looking CSS styles that can be customized to your brand.

It comes with its own grid and typography definitions as well as styles for buttons, forms, and more. In short, it takes a lot of the hard work out of starting a web project and making sure that it works across browsers.

Bootstrap and other frameworks like it have been used as a foundation for design systems for smaller companies that don’t have the resources to build their own.

As you can see below, Bootstrap is very similar to corporate design systems like the one shown above.

Bootstrap buttons

Design Systems + Wireframes in Practice

The main advantage of pairing a design system with a wireframing tool is that it can free you from worrying about look, feel, and behavior when wireframing. Yet, they provide pixel-perfect renditions of the final product components.

When you already know what a button (or tab, menu, etc.) is going to look like and what its state transitions will be when you click it, then you don’t have to style it in your wireframe. Black and white and Balsamiq Sans is just fine.

Having a design system to refer to can allow you to jump straight from wireframes to code without leaving the final vision undefined.

Here’s how you can pair them together. You’ll find that they get along quite well together!

If you already have a design system, great. If not, you can start with a customized download of Bootstrap or Foundation. The next step is to create a mapping between it and the controls in your wireframing tool.

A mapping basically means developing a shared agreement of “this means that”. You can do this by creating a document showing these mappings or by just having a meeting with the design and development teams around a screen to work it out.

Here’s an example of how you might map some Balsamiq controls to Bootstrap components (you could also start with the Bootstrap Wireframes To Go library).

Simple mapping of wireframe controls to coded UI controls

Note: It’s ok to use some color, but it should only be used as much as necessary to indicate states and selections, for example.

Having this kind of mapping means that developers no longer have to wonder whether the colors in the wireframe are supposed to be used in their code. They can just translate in their head that a blue button in the wireframe actually means a green button in the UI (if that’s the color you use), and that breadcrumbs separated by the > character should actually be separated by the / character in the app, for example.

You can also extend your design system by creating your own Balsamiq controls as Symbols to map to other components in your library, like this:

Balsamiq symbols mapped to design system components

This mapping can evolve and grow over time as needs and design language change in your organization.

Here’s a simple example showing what a completed wireframe could look like when built in conjunction with a design system.

Note: Blue in the wireframe doesn’t have to mean blue in the finished product.

Created in Balsamiq
Created with code

Wireframe to working code with no additional design artifacts in between!

Having a design system also means that you’re reusing the same code across all parts of your application so that different developers produce the same UI which leads to better standards and consistency. And if the design system gets updated, the wireframes don’t have to change.

Finally, designers can rely more on the stock controls inside the tool rather than spending hours trying to replicate the look on their own, so both the design and development cycles are shortened.

Summary

Nothing works for everyone, of course. This approach isn’t guaranteed to work for all projects or organizations. For example, it is better suited to in-house teams.

Clients outside your organization are more likely to want to see a high-fidelity mockup. Also, most of the starter design systems are for web-based products. Desktop and mobile application design system templates and examples are less common.

Lastly, and perhaps most importantly, you should have good communication between design and development teams for this approach to work.

Much of the shared understanding of the connection between wireframes and design systems is created by having a conversation about it. Announcing it over email or simply posting it on your intranet alone probably won’t work. Waterfall and distant remote teams trying this might not fare as well.

That said, it does offer lots of advantages for many teams, such as:

  • Saves time when wireframing
  • No mismatch between wireframe and reality
  • Good for Lean/Agile methodologies where deliverables don’t need to be so formal
  • Good for small teams and startups without many resources (especially when using frameworks)
  • Different skillsets can be applied to different design areas (e.g., visual designers and developers for the design system, interaction designers or PMs for the wireframes)
  • Design processes (wireframes vs. design system creation) can be done independently, resulting in fewer bottlenecks
  • More UI consistency across the product

More Design System Resources

--

--

Leon Barnard
Leon Barnard

Written by Leon Barnard

New to this whole writing thing, but not this whole life thing. You can follow me @leonbarnard.

Responses (1)