By Stewart McCoy

Wireframes as clear records of clear thinking

Originally posted on the Mule Blog:

At Mule, we approach information architecture as a team-based activity. Our designers, developer, researcher, and project manager all sit down with our information architects for internal work sessions. We want to do thinking and design work together, so that afterward our IAs can document the decisions that come from discussion, whether through site maps, concept models, user flows, or wireframes. This approach allows our researcher to bring in knowledge from the discovery phase that can inform IA decisions. It also keeps our designers and developer in the loop, allowing them to forgo additional meetings to ask clarifying questions. Potential problems in visual design and technical implementation can also be headed off earlier in our process, reducing chances for project delays.

Our IA documentation process captures discussion as it develops, which is why our approach is rapid and iterative. Documentation is only “finished” when there is internal agreement that it is a clear record of clear thinking. The details included should be only those that represent actual recommendations or decisions to be made. Wireframes are often a large part of our documentation process. As such, they focus on structure and hierarchy.

During our work sessions, some core decisions we discuss that are documented by wireframes include:

  • Actions: What are users’ goals and tasks?
  • Content: What is the purpose of the content? The purpose has implications for presentation.
  • Behaviors: What functionality will best serve up content and accommodate user actions?
  • Navigation: What paths will users need to successfully act on their goals and tasks?
  • Instructions: Occur before user actions.
  • Feedback: Occurs after user actions.

Our wireframes begin as page description diagrams that provide a high-level overview of key page types. As discussion moves toward agreement, wireframe fidelity moves toward the layouts that will be comped in Photoshop. Still, you should keep in mind wireframes don’t need to be pretty—they just need to communicate. If you put too much emphasis on wireframes as beautifully-crafted deliverables, you’ll often waste a lot of time: client conversations usually result in rethinking, which means documentation revisions. So make sure you are documenting design discussions rather than moving around and garnishing the food on your plate.

You should browse more of my posts and find what's worth reading