Business analysts tell us how prototyping tools help them manage requirements, improve stakeholder communication and streamline the design-development workflow.
IIBA’s BABOK (Business Analysis Body of Knowledge) guide is a lodestar for every BA worth his or her salt, but sometimes even the BABOK doesn’t quite provide the information you’re looking for. Take the entry on prototyping, which BABOK describes as a tool to “identify, describe and validate” user interface needs. That’s a good jumping off point, but how do prototypes and wireframes actually fit into the day to day workflow of business analysts?
Here at Justinmind, we wanted to know how experienced BAs use prototypes to ship successful products, and whether there are any must-know rules for business analysts using high and low fidelity prototypes. So we reached out to business analysts in our enterprise network, and here’s what we found out.
What’s the main reason business analysts use prototypes?
According to our survey, over 40% of business analysts use prototypes as a way to validate features (hats off the BABOK’s definition here) – so BAs are reaching design solutions faster by testing them with targets users and relevant stakeholders. This kind of later-stage concept testing ensures buy-in and acceptance.
Next, split equally with 25% a piece we have requirements gathering and the mysterious ‘Other’ – from comments we glean that ‘Other’ encompasses things like validating user flows, defining user stories and collecting feedback.
Finally, it looks like only 8% of respondents use prototypes for reviews.
What fidelity prototype are business analysts most likely to use?
Exactly half of our BA survey respondents use high fidelity prototypes to facilitate their day to day tasks. But that doesn’t mean mockups and wireframes are left out in the cold – 33% and 17% still use these lower fidelities with regularity, either on their own or combined with higher fidelities at later development stages.
Our BA survey respondents gave us a ton of interesting answers about how and why they use prototypes. We’ve picked the 7 most insightful comments and shared them with you below. Follow their best advice for making the most of prototyping in product development!
Jeyakanth Kumaresan, Senior Business Analyst at Equitable Life
Prototyping comes in handy when BAs are dealing with requirements related to product design. The output is tangible (for visual people) and it cheers up the stakeholders. The cost of building the prototype is usually a fraction of the estimated cost for overall solution.
When I look a prototyping, I consider the following:
- Elements that go into building the prototype
- Level of detail needed on the prototype
- Nature of prototype (Throw away vs Evolutionary)
- Stakeholder acceptance criteria.
Something to watch out for is that users/stakeholders may start looking at the prototype as a solution/end-product. Focus on addressing the core business need/problem. And always remember that prototyping is a “requirement elicitation” technique
Ryan Yokoyama, Product Manager at XPO Logistics & former Business Analyst
We use prototypes for UX cognitive testing, customer panel feedback, stakeholder requirements sign off, design sign off. On some platforms it’s inexpensive to create prototypes. For expensive platforms we will resort to wireframes or mock ups. Many stakeholders have a difficult time visualizing a solution (without a prototype).
Julian Hua Ee, Application Programmer, Application Services Division, LADBS
- Elicit requirements
- Produce prototypes (when applicable)
- Validate main flow using prototypes with the client
- Define final user stories.
Top tip? Just do it, even it doesn’t look great at the beginning.
Laura Brandenburg, blogger at Bridging the Gap for Business Analysts & BA consultant
I actually avoid high fidelity prototypes as a business analyst. My preference is to use low-fidelity mock-ups that show one possible way to present information or organize functionality on a screen. This tends to be just enough to get my stakeholders’ creative juices flowing so we can get to the real requirements and workflow needs. Then, as a subsequent process, I’ll work with a user interface designer to integrate the requirements into a high fidelity, high quality design.
Sean Toscano, Product Manager/Business Solutions at Trail Appliances
Keep it simple. The point of prototyping, in my opinion, is to elicit discussion and reveal issues that may become roadblocks later on.
Khalid Ghazi, MOA
I don’t just use prototyping for requirements gathering. With prototyping, I have a tool not only to help with requirements but also to show give end users a more concrete understanding of agreed upon requirements and designs, and how the UI and UX will be, even before the application is completed. High fidelity prototypes help developers by making it easier for them to understand the requirements, functionalities, application process flow, and the UI aspect of applications.
- Wireframe – at requirement gathering & validation during F2F/Workshop
- Mockup – at requirement & feature validation
- Prototype – at all stakeholders final round feedback collection
And finally, we couldn’t resist including Åsa’s comments, even though she’s technically a Global Sales Operations Manager at Qlik and not a Business Analyst…
“Presentations without prototypes more often ends up in new discussion but presentations with prototypes more likely end with a decision.” Åsa Fröjd, Qlik
How business analysts use prototypes – the takeaway
Looks like experienced business analysts use a variety of wireframes, mockups and interactive prototypes based on where they are in the development process and who their target audience is. While lo-fi mockups work well for internal developer chats, a tool that can manage requirements and incorporate interactivity might be more apt for client or stakeholder facing activities. The common thread between all these different approaches is that wireframes and prototypes help visualize solutions, reduce misunderstandings and get business analysts closer to building stand-out products.