Back to overview

Why we prefer to design pattern libraries rather than screens

When we design for print, we have total control over how the design is rendered. But since our screens now come in all sizes and resolutions, it is no longer possible to determine exactly how a design will appear on a screen.

The introduction of responsive design, a design that automatically adapts to the size of the screen, requires a different design process than the one we are accustomed to. Designing for countless screen sizes calls for a much more flexible design process than we are used to working with. 

It is therefore far more advantageous to design a pattern library, rather than fully developed screens. 

What is the problem with fully developed screens?

They give a false sense of security. 

Full screen designs are snapshots. Everything is perfectly balanced, but as soon as we alter one factor, we are left groping around in the dark. The screens are not interactive. They give the impression that everything works, but you can't work with them.

What does a field look like before it is filled in? What if a field has already been filled in? What if a field has been wrongly filled in? 

They are not scalable.

Of course, we can design additional screens as soon as the design changes. We take a smartphone, a tablet and a desktop version. Extra screens give us an idea how the design needs to change in the different screen sizes. 

But what about the in-between sizes? And what about the extreme sizes, such as a smartwatch or an HD screen? And what do we do with other pages that contain other content?

Extra screens only resolve part of the problem. 

They take a lot of time (and cost a lot of money).

The more screen sizes we develop, the slower we work. If we develop each screen three times x the number of screens that we have to design, the number of hours of design work soon mounts up. Design are is bad for schedules and budgets. Not only is designing new screens a good deal more intensive, but adaptations and updates quickly become sheer drudgery.

What is a pattern library?

A pattern library is an overview of all the individual elements that make up the design of the website. This overview includes the specifications of all typographic elements (titles, body text, labels), all buttons, tables, fields, icons, etc.

A pattern library can best be compared to a box full of different types of Lego blocks. You use all the Lego blocks to build the screens. 

  • For example: a title + two fields to be filled in + one button = the login form. 
  • For example: a title + subtitle + body text = a blog post.

What is the advantage of a pattern library?

Save time

A pattern library allows you to design an element once and then reuse it everywhere on the website. We design a button once and this same button reappears on every page. If we have to adapt the button, we again only have to adapt it once and the change is made throughout the website, rather than having to adapt every screen (x the number of screen sizes).

Design for use

The time we save by not designing the same screen in different sizes can be spent developing the different states of an element. As a user interacts with the website or the app, he expects feedback. 

The field he has selected has to look different from the fields that have not been selected. A button that you cannot click on (for instance because the form is not complete) cannot look like a button that you can click on. 

Design in the browser with real content/data

As we no longer develop individual screens, we can very quickly convert the design to code so that we can see our design on various screens and screen sizes. Rather than using the same Lorem Ipsum title every time, for instance, we can see how the design reacts if the titles vary in length. Designing in the browser enables us to take the right decision more quickly for all screen sizes. 

How do you use a pattern library during the design process?

Rather than approving a design once before it is converted into code, we approve the design in various steps. 

Step 1: prototype

We develop the various screens in a click model. During this phase, we want to quickly explore the various possibilities in terms of layout, interactions and architecture. 

In this phase, we assess how the website will work. How do users navigate from one page to the next? What steps are involved, for example, in the subscription form? Or how can users log in and out?

Step 2: pattern library

As soon as we have an idea of the first prototypes, we start listing all the elements that we may need in our design. All elements are styled so that they correspond to the visual identity of the website or application. 

In this phase, we assess not how the website works, but what it looks like. Which font do we use? Which colours do we use? What will our buttons look like? What will our menu bar look like?

Step 3: finishing in the browser

In this final phase, we bring everything together. We fill the first, most crucial screens with realistic content or data. As extra screens are added, the pattern library is brought up to date. After a number of screens, virtually no further adaptations will be required and the design is ready to be rolled out across all the pages. 

In this phase, we assess how the website works across the various screens.

Back to overview