Scope Components, Not Pages

Recently, the always-brilliant Scott Jehl wrote a post titled Grade components, not browsers. In his post, Scott explains that grading browser support is an ineffective way of determining what experience a particular device/browser should get. Instead, the Filament Group grades components based on their level of intricacy, which results in a more granular way of enhancing experiences to better reflect the capabilities of a device/browser/configuration.

Scott’s post reminded me of the many conversations about Web pages I’ve had over the years with clients and project managers.

“How long will the homepage take?”

Throughout my career, I’ve been asked to estimate how long it will take to develop a “quick one-page website” or how long a particular page would take to create. Pestering project managers would ask, “Hey Brad, how long will it take to build the homepage?” “What about the product detail page?”

It didn’t take long for me to start asking “Well what’s going on these pages? Is the homepage simply comprised of some text and images, or will there be something like a carousel? (hint: the answer is always ‘yes there will be a carousel.’) How about forms for data capture? Video content? An interactive HTML5 canvas? WebGL? Parallax? A whammy bar?”

I recently received an e-mail from someone at a large organization. He articulated something that pretty much every organization going down the responsive path is struggling with:

What we’re struggling with here is transforming our entire website (thousands of pages) into a responsive design.

At first glance, one might say “Thousands of pages!? Wow, that sounds challenging!” But in reality, those thousands of pages might be comprised of the same four basic components. A project’s level of effort depends entirely on what the interface is made of.

What is an interface made of?

For the past few years I’ve been obsessed with the question “What is an interface made of?” It’s the question that led to the creation of the responsive pattern library, atomic design, and Pattern Lab.

In order to better scope projects, it’s essential to look at what the interface is comprised of rather than looking at the quantity/type of pages. This is what software developers have been doing for years now, but the concept of “Web pages” has distracted us from breaking things down into features and components.

Interface Inventories to the Rescue

So how can you scope a project based on components rather than pages? I think a good place to start is with an interface inventory.

An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.

We conducted an interface inventory as part of our redesign of the Pittsburgh Food Bank. We went through and captured all the unique components and features that make up the site. While most of the site is comprised of text and images, there are quite a few pieces of functionality that will need a lot of design attention. Here’s a few samples from our interface inventory:





By conducting an interface inventory, we’re able to better gauge the level of effort for each piece of functionality (especially factoring all the variables discussed in Scott’s article), discover potential hang-ups, and better communicate the project scope to the client.

Getting granular and scoping a project by components/features rather than pages leads to a more realistic scope.


  1. I love inventory lists. In many situations, envisioning where you want to be, and then working backwards from there is a more viable workflow method than taking things in a traditional manner.

    As web developers, we often see the collection of “pages” as the basic unit of development. Instead, they are more of an end result, comprised of individual components. In the design process, tangential components to the primary topic are always preferred over seemingly random ones as it helps to provide supporting functionality without wasting interface space.

    Yet another instance of how a non-traditional approach yields higher comprehension of the problem, and allows us to formulate a more accurate solution.

  2. Another great post thanks – it’ll be good to get our clients to recognise this.
    It also allows you to give more progress feedback to a client more regularly and allows them to see what work actually goes into each and every different part!

  3. I think a good place to start is with an interface inventory. Yes the important in web design is components like electronic industry . Design the various components then assemble them to a page.

  4. This is a great concept and I agree wholeheartedly—but what does a component-scoped agreement look like to a client? What is the deliverable for the component design phase, then? A pattern inventory built on Pattern Lab? What is that called on the timeline? (I’m in the process of drawing one up now and am falling short of the right language.)

  5. Victor

    Great post (of an unfortunately wel known experience).

    Besides scoping on components/features, let’s not forget to mention that scoping should also be done on design-elements/patterns. If some features are not designed yet, it’s hard to predict what effort you need for adding new styles to complete these parts.

Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.