While I find that wireframes help me elicit the right requirements and shorten requirements review cycles by giving my stakeholders a visual point of reference, many business analysts resist creating wireframes because they take can a fair bit of time. What’s more, if you are not careful, the focus on the user interface can take away from other important aspects of the requirements.
In what follows, I’ll share my tested shortcuts for creating wireframes, which I normally create right alongside use cases. These shortcuts ensure wireframes remain a productive part of the business analysis process and not a distraction for me or my stakeholders.
(Wireframes happen to be just one of many visual models created by business analysts. For a more comprehensive list, click here to read about 22 visual models used by BAs.)
#1 – Limit the Scope of the Wireframes
Software applications can be big. Does your wireframe need to capture every piece of functionality? Not hardly.
Most projects are updates to existing functionality. In this case, 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.
For a new software application, I focus on wireframing core functionality that helps my stakeholders get the intent behind the application. And if we are using an iterative requirements / development process, often by the time I get further into the requirements, I’m able to grab screen shots from the development environment that makes the wireframing process much easier, which leads me to my next point.
Rule of Thumb: 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. 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.
#2 – Re-Use Existing Elements in Your Wireframe
To save time on recreating existing screens, I use screen shots to capture the existing application. (In the absence of an existing site, I’ll copy and paste elements from applications with similar functionality.)
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.
Rule of Thumb: 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?
#3 – Keep the Wireframe Low-Fidelity
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.
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.
Rule of Thumb: If a feeling of dread comes over, you are working too hard. When a business stakeholder asks for a change and your stomach drops, 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 to elicitation, analysis and validation; never let it be a deterrent to getting the requirements right.
Learn to Create Wireframes
Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.