By Stewart McCoy

Design Thinking and Degrees of Wireframing

Design Thinking and Degrees of Wireframing

This diagram represents three stages of design thinking during the wireframing process. The mock-ups are for the Account Details template for the fictitious Cash Money Bank. Please note that the interface specification is just that, a specification, and not indicative of visual design or layout.

As a designer who produces wireframes on a regular basis, I’ve experienced confusion about how design decisions are to be documented. I would like to share some clarity I now have on this issue by discussing how progressive stages of design thinking can be captured by different degrees of wireframing. From low-fidelity, in which it’s about sketching some boxes and writing down the goals of those boxes, to high-fidelity, in which interface and functionality are diagrammed and annotated for designers and developers to create comps and prototypes. High-fidelity wireframes are optimally created through collaboration with visual designers and developers.

My way of thinking on the wireframing process has evolved a lot since I first read books on information architecture. Those books discussed how to prepare and present deliverables like wireframes, site maps, and user flows. Before starting at Mule, I hadn’t worked on a complex application design project and I approached IA in terms of what deliverables would help me to create a system. (Note that I wrote “create” and not “document”; it’s an important distinction). I would start with a site map to nail down the structure. Then I’d move into flows to better understand the decisions users would need to make in order to accomplish their goals. Then I dove into wireframes. I’d lay out the navigation, paying attention to tab and/or list order, as well as label nomenclature. I’d designate where images would go, describing both the size and kinds of images that were and were not acceptable as part of the design. I’d also lay out places for editorial photos, thinking about optimal aspect ratios, whether captions were needed, and annotating recommendations for the editorial team on how to choose photos that would be published on the site. I’d worry about button placement. I’d worry about page hierarchy, what content needed to be emphasized, what needed to be on the left or right of the screen, what needed to be below the fold. I was putting lots of attention into details that didn’t address the strategic goals of the system.

I was doing the job of the visual designer and not as well as they’re able to. It’s an easy trap to fall in to. Part of my difficulty was conflating content structure with visual hierarchy. Structure is about priority, whereas hierarchy is about placement. Structure is the responsibility of the IA and should convey the strategic importance of an element and address the level of emphasis a visual designer should give that element. Whereas hierarchy is the responsibility of the visual designer and is literally how elements should be positioned one above the other.

Thankfully, Erika Hall has been a great mentor that’s helped me to grasp the importance and process of design thinking that goes before documenting decisions in the form of wireframes. The importance of design thinking is also addressed by Dan Brown in Communicating Design on page 266:

  • “The purpose of a wireframe is to communicate initial design ideas. Therefore, the team must have a solid understanding of the design problem.”
  • “The scope of a wireframe is content and structure, not layout or visual design (though wireframes may be used in deliverables later in the process to document those issues).”

However, rather than communicating “initial design ideas”, the purpose of first-draft wireframes is better explained by “initial design goals”. After understanding the design problem with your team, you need to discuss and come to an agreement on design goals. Then you document those goals in wireframes and present them to get buy-in from stakeholders. Talking about goals will keep both you and the client on the strategic level, thinking about why you’re designing the system and what the system needs to accomplish, rather than getting into the weeds about interface elements and visual design. Those strategic decisions are ones you and the client need to collaborate on. Design recommendations that deal with content and structure, interface, and functionality are the ones you make because the client hired you for your expertise.

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