For most of the web’s short lifetime, the primary way to design a website has been to create wireframes and comps (design compositions) of a site’s key pages. Oversimplifying a bit, designers identify these key pages and essentially create pictures of what the pages look like when presented on the web. The designs are typically done with desktop computers in mind and at a fixed screen width.
The client or product owner provides feedback on the work and eventually approves the page designs. The comps then get converted into HTML/CSS and built out as templates in whatever Content Management System is being used. And done! Like magic!
While not exactly easy, this process more or less worked for a long time and was the primary method most firms used to design websites. For a variety of reasons, over the last few years this page-centric design approach has proven to be irrevocably broken. The page-based approach is simultaneously time consuming and ineffective at showing what the end product will actually look like.
Following we explain the problems with page-based design and how our Brick Factory team has transitioned to a system-based design approach.
Rise of Smartphones and tablets.
Five years ago, nearly all website traffic came from desktop and laptop computers. If 10% of a site’s traffic came from phones and tablets that was a lot. Today it isn’t unusual for a site to see 50% of traffic coming from phones and tablets.
And within each of the main device categories (phones, tablets, desktops and laptops) there is a ton of variance in screen sizes. For our average site, the most popular screen size (usually 1366 * 768) is used by only 10% of visitors. For the highly trafficked websites we work on, we might see as many as 1,500 unique screen resolutions each month. A single site design must provide a good experience on gigantic desktop monitors (2560 * 1600) and tiny mobile screens (230 * 270). As you can see, these are two very different balls of wax.
Given the range of screen resolutions, creating designs comps of a bunch of pages at arbitrary screen sizes just doesn’t make a lot of sense.
Increased Complexity of Interfaces
Web design has gotten a lot more sophisticated over the last few years. The projects we complete for our larger clients feel more like applications than simple websites, with user inputs often driving how the site looks and behaves. Designing these interactions out as “pages” requires a ton of page comps. For example, a donation system for a nonprofit client could easily require 10-20 page comps by itself.
Even simple websites are much more complex than they were four or five years ago. A four or five page promotional website today is likely to include sophisticated transitions and animations that are difficult to convey in a page comp.
It just isn’t efficient to demonstrate this sort of complexity via flat, page-based design comps.
Page-Based Design Doesn’t Scale
Due to the proliferation of screen resolutions and increase in complexity, on large projects we have ended up doing a staggering number of wireframes and design comps when using a page-based design approach. Whereas four or five years ago a complex project might have meant twenty page designs, today it can easily mean 50-100.
The sheer volume of comps that we have ended up producing has lead to consistency problems. If every page is designed separately, unnecessary and redundant design elements are very likely to get introduced. This makes the resulting site harder to build and maintain, and the overall quality of the work is compromised.
Page-based design just doesn’t scale.
Bottom Line
Perhaps the biggest problem with page-based design is that it creates an inaccurate representation of how the end user will experience the resulting website. The designs a client approves don’t really reflect what the site ends up looking like.
Once those pixel perfect PSDs are turned into HTML/CSS and viewed in different browsers at different screen resolutions, they often look pretty different. All that painstaking design work is sort of wasted, as you still end up spending a ton of time polishing the site once you have a working draft.
Ultimately with page-based design there is a fundamental disconnect between the way the site is designed (flat PSDs) and the way it is built (HTML, CSS, Javascript, etc.).
While it has been a bit of a struggle, over the last few years we have made a conscious effort to move away from page-based design. Along with many other designers, we are trying to design systems instead of pages.
While we are still refining our approach, for us this means creating a design process that is in tune with the way websites are actually built and function. We design overall styles and repeating elements that make up the pages, instead of the pages themselves. So instead of fifty design comps, for a project today we might produce the following design deliverables instead:
After we get these key building blocks designed and approved, we start creating the site templates in HTML/CSS and see what things look like. We then allow ourselves plenty of time for refinement and polish. Instead of front loading all the design work, we take a more agile approach and fine tune the design after we see what the working draft looks like.
We haven’t perfected our process yet and by the time we do everything is likely to change again. But, at least to us, this system-based approach makes a lot more sense than producing an endless series of page comps.
We wrote a follow up to this post walking through a project that uses a systems-based approach.
Sign up today to have our latest posts delivered straight to your inbox.
