Knowledge Base Articles > Using Wireframes with Design Systems

Using Wireframes with Design Systems


People often wonder how much visual detail to put into their wireframes. 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.

There is another way, a way that 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 (sometimes called a pattern library).

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 but, 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 a small piece of the IBM Carbon Design System showing the appearance and code for 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 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, Bootstrap is very similar to corporate design systems like the one shown above.


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 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 reference 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 (with your design system even?) 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).

(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:

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 that blue in the wireframe doesn't have to mean blue in the finished product.)

Created in Balsamiq:

Balsamiq Email

Created with code:

Bootstrap Email

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 UIs, 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 (Or, Your Mileage May Vary)

Nothing works for everyone, of course. This approach isn't guaranteed to work for all projects or organizations.

It is better suited to in-house teams, for example. Clients outside your organization are more likely to want to see a high-fidelity mockup or comp. Also, most of the starter design systems are for web-based products. Desktop and mobile application design system templates and examples are less abundant.

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 the 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 BarnardBy Leon Barnard
Got questions or feedback? Email leon@balsamiq.com.