In recent years we’ve worked on a number of projects in which one of our designers has partnered with a client’s business analyst. Going into these projects, our rough approach has been for the BA to document requirements while we research end-users to build an understanding of their context. Then we design the UI to meet the requirements in a way that fits users.
One of the intriguing things we’ve observed in these situations is that, no matter how skilled and detailed the BA is, we always end up reopening the requirements discussion once we put screen designs in front of people. We think this is because of a gap in the traditional BA approach.
A gap in the BA approach?
BA methods, as described in the Business Analysis Body of Knowledge (BABOK Guide), focus on breaking complexity down into small, manageable pieces. Although a reductionist philosophy isn’t explicitly stated, it’s apparent that the essential method is to reduce big things into their smaller components.
When dealing with large, complex systems this is both logical and necessary. BAs have a wealth of methods for gathering and documenting requirements in a granular way. What’s missing from their toolkit, however, are methods to visualize how those requirements will come together into a coherent solution.
This, as it turns out, is a problem.
A coherent picture changes how people think about requirements
What we’ve observed is that people engage in a deeper way with UI visualizations than they do with text-based requirements or abstract diagrams. This is especially true when dealing with stakeholders who aren’t intimately familiar with web or application development. In order for these people to assess the completeness of a list of requirements, they need to see how everything comes together.
We believe the main reason requirements discussions reopen once design begins is that visual representations of the whole system reveal new requirements.
This has major implications for how requirements are defined. In complex systems, the traditional reductive BA process can never yield all the requirements because large lists of requirements have no collective meaning. Each requirement can be evaluated on its own, but it can’t be evaluated in relation to others unless you know how they fit together. This makes it virtually impossible for anyone looking at the list to know if the requirements are complete.
In addition, people can’t walk through realistic usage scenarios using a list of requirements. This means they have no way to assess whether the proposed system will function adequately in a realistic context.
As a result, we’ve come to believe that requirements analysis is essentially incomplete without modeling a coherent picture of the whole. And what could be more risky than incomplete requirements?
Requirements and risk
One could spend days debating the most challenging and risky aspects of complex application development projects. However, you would likely find consensus around the topic of requirements. Incomplete or changing requirements are among the most common risks teams face, and may be the greatest cause of project failure. We use visual models of the system during requirements gathering to solidify requirements and reduce overall project risk. We call this method Visual BA.
Visual business analysis
Requirements gathering and analysis are really about answering the question “what does our new _x_ need to do to be successful?”. In traditional application development projects, BAs answer this question by gathering requirements. Designers tend to be engaged later in the project.
Others have written about the need to include designers early , but we think Visual BA goes beyond ‘soaking up business context’ or ‘influencing scope’. In Visual BA a designer actively participates in defining and analyzing requirements by providing visualizations that allow team members to test scenarios and build a shared language.
Visual Business Analysis is the deliberate use of sketches, wireframes and prototypes to model how a system will work in order to learn more about what is required for success.
Visuals are used to ask questions and to build a common understanding of what success will look like. They’re used to deliberately provoke discussion, and to help people think about the problem in new and unexpected ways. They’re used to evade the trap of gathering requirements that pre-suppose a certain kind of solution.
It’s important to recognize that these visualizations are used as tools to dig deeper on requirements. They are not just steps on the path to the final design. They inform final design, but their primary purpose is to test known requirements and expose new ones. They are visual tools that help focus and test the team’s thinking before what would normally be thought of as the “design phase”.
Our Visual BA process includes both an analytic component (usually performed by a BA) and a synthetic or design component (usually performed by a designer). One person could perform both tasks, but we’ve had success pairing BAs and designers throughout the process. Subject-matter experts, technical architects and business stakeholders are also key contributors.
Iteration is a critical part of our approach. The team works through successive rounds of analysis, design and review by stakeholders to refine requirements and model a system that meets everyone’s needs. This is true regardless of the development methodology (agile, waterfall) being used on the project.
Is visual business analysis for you?
We think visual business analysis would benefit any project. Whether a big, small, complex or simple project, modeling how things come together helps people decide what should be in and what should be out.
But Visual BA is especially important when dealing with large, complex systems. Increased complexity brings special challenges that are best met with visualizations.
If you have more requirements than you can hold in your head at one time, Visual BA can help you understand how everything will come together, and give you a tool to assess the completeness of your requirements.
If you need to untangle competing business drivers, Visual BA will allow you to test different scenarios and to see the on-screen impact of specific trade-offs.
If you’re dealing with complex internal stakeholder relationships, or working with people who have different levels of technical sophistication, Visual BA will provide a common language that will ensure everyone has the same understanding.
In these and other complex situations, long lists of abstract requirements become a barrier to understanding and good decision-making. Visual BA fills the gap in the traditional, reductive BA process by modeling how things might come together. This helps teams develop a better understanding of what success requires before development starts.