Product Planning Series: Information Architecture

This is the seventh post of my Product Planning Series.

I’ve worked with development teams who were “too busy to generate design documentation”. They say: planning is guessing. They say: a design is useless unless it can be represented in code, therefore you ought to start in code. Many of them then start writing the GUI code one component at a time without having developed an information architecture that provides context to each component.

I say to these friends of mine: action without planning in this case is not so smart if you care about the quality of the outcome. A great user experience comes from a holistic view of the application and an information architecture that accommodates not only the UI needs of components of the application, but the cohesiveness of the user experience as a whole. This is up front work that takes time and effort, but it is absolutely worth it. It saves you from having to do gut rehabs to your GUI to accommodate new features and use cases you haven’t properly anticipated before.

One way to capture the output of this design process is with flow charts and wireframes. A high level flow chart for a web app (or any software application for that matter) explains the functionality of the application and how you get to each part of the application at a glance.

I’m going to use the web site of the Trust Center for MIT Entrepreneurship as an example. Since websites change all the time, here is a screenshot of the home page of this site as of January 2012, featuring my good friend Bill Aulet (the current Managing Director of the Trust Center).
Example Web Site

Somewhere during the design process of this site, a project manager had decided on the content that would be presented to the users. An information architect would have worked closely with the project manager to develop a top level site map, easily depicted in the form of a flow chart. This flow chart shows how major content is organized in different pages, and how a user might get from either the home page or a landing page to their content of choice.

Once this high level view exists, the designer would have come up with a wireframe of each key page in the app. Now what is a wireframe in this context? The Wiki has an excellent explanation:

A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together. The wireframe usually lacks typographic style, color, or graphics, since the main focus lies in functionality, behavior, and priority of content. In other words, it focuses on “what a screen does, not what it looks like.” Wireframes can be pencil drawings or sketches on a whiteboard, or produced by means of a broad array of free or commercial software applications.

Thus, we are NOT talking about wireframes in CAD-speak. We are talking about a fairly specific form of design output.

Continuing the example above, the home page wireframe for the Trust Center website would likely have looked something like this.
Example Wireframe

As you can see, a wireframe is not a graphical design. It is instead a concept for a page layout that contemplates the information to be presented to the user (e.g. title, subtitle) and the actions the user need to be able to take (e.g. subscribe via RSS or email) and arranges things in such a way that a user can accomplish most of the mainstream workflows they came to your site to achieve (e.g. read the latest post).

The wireframe is intentionally very stylized in presentation in order not to confuse the reader with any graphical treatments that may cause him or her to latch on to something irrelevant (e.g. the quality or choice of the banner image), instead of focusing on what is the most important at this stage of development (e.g. the user workflow and use case scenarios). It communicates key technical requirements to both the project manager and the developer and helps them negotiate and plan the development work that implements this design.

Now if someone was to plan out a website in its entirety and inventory all of the screens, they would come up with way too many screens to design in this manner. So how many wireframes are really needed? I believe one should at least make as many wireframes as there are unique templates.

A template is a webpage layout that specifies what content goes where. There can be many pages with different content that uses the same template. Going back to the Trust Center website, you can see that several subpages all have the same layout, but different content within each block of information. For instance, if you were to browse the Trust Center site, you will quickly discover that with the exception of the home page, all the pages accessed with the top navigation bar (e.g. Activities > Curriculum, or News) share the same 2-column template.

Example Template

Since they are all the same, they can be depicted using the same wireframe.

Hopefully this post has helped demystify the front end of web development. The organization of information into different pages is an information architecture exercise; the wireframe design for each unique template starts to pull in interactive design. Once that’s done, graphical design comes next – that will be the topic of another post.

Leave a Reply