# Quantifying the Efficiency of Designing in the Browser

In this article, I’d like to show how much more efficient designing in the browser is compared to the classical design process, and express this effect in figures.

In the classical UX design process, we produced pixel perfect designs for each screen, which had to be updated with every change. After that, or in parallel, we created a throw-away prototype, causing additional maintenance effort.

Nowadays, we must produce designs for a multitude of display sizes and interaction styles. Therefore,

## Naive Calculation

We can calculate the amount of **additional effort** required for creating wireframes for every single manifestation using the following formula:

*S: total number of screens to design
T: number of web page templates
Z: number of different states per template
B: number of breakpoints*

**Example**

Let’s assume we want to design 20 templates for a fictitious responsive website with two breakpoints and only three states per template on an average (!). The number of designs calculates as follows:

I.e., for 20 screens, it is necessary to design 180 single designs, which have to be updated upon every change — a hardly justifiable effort, especially for more complex interfaces with several design iterations.

But how can we quantify the actual gain in efficiency per screen by designing in the browser as compared to the design of static screens? It’s as easy as that:

*E: efficiency gain in %
Z: number of different states per template
B: number of breakpoints*

**Example**

## Conclusion

I admit that the formulas are strong simplifications and the examples may not be life-like — which interactive website makes do with only three states and two breakpoints? However, it is possible to point out ostensively how much more efficient it is to design directly in the browser as compared to classic, static wireframe design. Especially for responsive design it is necessary to rethink the role of classic, pixel-perfect wireframes in the UX design process and to apply this powerful tool in a new fashion.

Show all articles
This is an excellent point. I’ll use it when arguing a case for designing in browser. But there’s so many more points that are excellent reasons to design it all in browser. I’m going to write up a post about Pros and Cons to in-browser design here soon but for now I have some tips for people trying to get started. http://andysearles.com/designing-in-the-browser/