Bottom-up information architecture – creating wireframes from the ground up

by Randy Tsang

Lately at work, I have been exploring the idea of a Bottom-Up Information Architecture methodology for web design. Traditionally, I have taken more of a Top-Down approach, whereby I begin the wireframing process with the navigation and homepage layout, before progressing down the sitemap through landing pages, individual content pages etc. Meanwhile, individual components such as registration forms, search and social media widgets would be designed as and when relevant to the page I am working on. The obvious benefits of this approach are that you can quickly get an understanding of the system in its entirety, and whole webpages can be tested early and in context.

A bottom-up methodology would take the opposite approach, whereby the emphasis is instead placed on designing and testing specific individual components separately, before they are eventually brought together into the final page layout. The potential of this approach would be a more robust overall system built around core functionality, thereby affording key user tasks more extensive attention wherever they are situated within the website. This approach fits into the growing importance of lower tiered pages relative to the homepage.

Background to Bottom-Up Design

The bottom-up approach has traditionally been adopted in areas such as software design, management and state organisation (see Wikipedia article). Another interesting application is detailed by Richard Feynman in his section of the Report of the Presidential Commission on the Space Shuttle Challenger Accident in 1986. In this report, Feynman details how NASA had originally engineered their space shuttles using a bottom-up or “component system”, thereby insuring a rigorously designed and tested space shuttle system. In the case of the ill feted Challenger, a top-down engineering approach had been taken.

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components.  Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes.

He goes on to explain another key problem in the top-down method:

A further disadvantage of the top-down method is that, if an understanding of a fault is obtained, a simple fix, such as a new shape for the turbine housing, may be impossible to implement without a redesign of the entire engine.

Such lessons could also be applied to web design, where components such as forms, social media widgets or video players are designed individually without the constraint of having to fit within predefined column structures or a position on a page.

Application in Information Architecture for the Web

For a typical website information architecture project, once the user flows have been created and key user tasks identified, the first stage of wireframing should focus specifically on the mini-systems to be built to satisfy these individual tasks. Designing these mechanisms individually and out of context can help create better usability and allow for speedy testing of these features. Usability issues are identified early and will have little knock-on effect for the rest of the site.

Once all these individual subsystems have been created, we can begin to link them together to create larger subsystems. Eventually a top-level system is formed, with multiple complex links and interconnections between the individual components. The layout, navigation and general page furniture are then constructed AROUND and FOR these systems.

Final thoughts

This approach, which I admit is still only a theory, does raise its own questions. Does such an approach increase the likelihood that the designer will miss the big picture or the overall context of the site? Testing individual components is great, but would this lead to a delay in testing the experience as a whole? And do we run a risk by not presenting the client with the big picture early in the project?

My initial impression is that these problems can be overcome as long as the user journey and sitemaps have been thought out properly. Testing individual components may uncover the main issues early in the project, meaning the test of the system as a whole, even though it may be late in the day, is likely to only uncover issues in page layout and not problems with the more complex mechanisms themselves. Client expectations can be managed, perhaps most suitably in an agile working environment for a case like this.

If any anyone has ever had any experience in designing this way, or if you have any thoughts please leave a comment or email me. Until then, I may just give this a go on my next project.