What to focus on in a wireframe

When pulling together requirements for a new software system I almost always focus on creating user interface wireframes. I use wireframes or mockups at different points of the requirements elicitation and definition process, as I wrote about in “Using wireframes or prototypes to elicit, analyze, and validate software requirements”. Many business analysts balk at wireframes. They take a fair bit of time and if you are not careful the focus on the user interface can take-away from other important aspects of the requirements.

I do a few things to make sure that my mock-ups do not become a distraction.

Treat yourself to a good wireframing tool

First, I use a good tool. Visio is simply not a good tool. PowerPoint can be a bit better, but both of these tools require a lot of finesse to build an acceptable UI model. Instead I use Axure. It’s a bit pricey, but try the download and you’ll be hooked. I recently saw an iRise demo and, although it is on the expensive end, it provides many features that make it easy to create not just wireframes but simulations. There are several other less expensive options to create user interface mock-ups including Mockup Screens and Balsamiq.

I like Axure because it’s easy to create click-through prototypes and the mock-ups open in a standard web browser. I can send a link to anyone on the business side to open the home page in their browser. With a small bit of effort, key elements are navigable to simulate actual activity.

Re-use existing elements in your wireframe

To save time on recreating existing screens, I use screen shots to capture the existing site. I copy the screen shot into paint, capture the relevant pieces, and copy them as a starting point for my new or edited screen. This can work even if you need to edit significant portions of the screen. Most prototyping tools have widgets that allow you to overlay a box on an image and color the background to closely match the original capture.

Once your base is in place, you can use a drag-and-drop prototyping tool to add in the new elements.

Limit the scope of your wireframes

For most projects, I focus only on what’s changing and not so much on what exists today and is not changing. This cuts down tremendously on the amount of prototyping work you need to do and helps focus your reviews. I apply this principle when bringing over an existing screen as well. While I’ll create click-through functionality for the new feature (say a new button on a page), I’ll leave out the functionality behind any existing UI elements that are not changing.

Keep the wireframe low-fidelity

For existing applications, I’ll grab the UI template from the existing site in my screen shots, but otherwise keep new features in the default fonts and colors provided by the prototyping tool.

For new applications, I stick to low-fidelity, exploratory prototypes in the early stages. Low fidelity means no colors, no images, and little bother with navigational elements. I keep the wireframes focused on fleshing out the work-flow requirements and functionality. This makes them easy to evolve as the team’s understanding of the application grows.

A few rules of thumb when wireframing

If a feeling of dread comes over you when a business stakeholder asks for a change and your development team hasn’t started implementing yet, then you are either using the wrong tool or have invested too much in a high fidelity prototype too early. The wireframing process is an enabler; never let it be a deterrent to getting the requirements right.

Focus on getting a few scenarios right in your wireframes. You can easily expend a lot of effort prototyping out multiple scenarios or flows through an application. Focus on the primary scenarios. I feel it’s OK to talk users through some of the alternate paths or add textual notes describing what will be different for a less frequently used scenario.

Stay focused on the value the wireframes are driving in the conversation. Are they helping people see the requirements in reality and ask good questions? Are they helping you drive alignment and understanding? Are they helping reduce confusion? If the answers are yes you are on the right track. If an answer is no, look for ways to change how you are using the prototypes to make them more effective or consider another requirements elicitation method.

Visualizing requirements is a powerful way to facilitate the discovery and elicitation process, but it can be time-consuming and distracting. I’d be interested to hear your input as to how you keep wireframes an effective part of your requirements development plans.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Using wireframes or prototypes to elicit, analyze, and validate software requirements
2. How to create a user interface specification
3. Requirements as the main focus of the business analyst work