Back in January I shared some thinking on what we’ve called Visual Business Analysis. That post argued that holistic visualizations of the system are necessary during requirements gathering because a coherent picture changes how people think about requirements. In effect, requirements are never complete without a picture of how the pieces come together. And visualizations provide the common language that allows a team of people with different skills and perspectives to debate and iterate towards a good solution.
One common response to the post could be summarized as: “Interesting. What’s the process? What are the deliverables?” I have to confess that I’m the prototypical “it depends” designer. Each project has it’s own particular context, but I think there are five critical components in Visual BA.
1. Involve the designer in research.
It’s critical for designers to have direct contact with business stakeholders and end users. Broadly speaking, business analysts are oriented toward documenting processes and business rules. This is a critical skill, but it tends to focus on system and process as abstract things, not as places inhabited by human beings.
Experienced designers, on the other hand, are able to focus on how process and rules affect the people in the system. Scrutinizing pain points and building a picture of how users understand the domain creates insight that is key when exploring options for a future state. Designers search for opportunities to transform processes to better fit the people and context.
2. Model the big picture as soon as possible.
BA documentation tends to be text heavy, and after a relatively small set of user stories it’s easy to lose the thread of how all the pieces might come together. As stories accumulate they become harder to use as a common reference. Subject matter experts, being unfamiliar with development processes and deliverables, often struggle to understand the big picture. This can create an unintentional power imbalance, with BAs and developers having greater influence over decisions.
Visualizations of screens and flows level the playing field, allowing subject matter experts to contribute on an equal footing. It’s important to get to this common language quickly so that expert knowledge and experience can be used effectively. My experience is that, while user stories initially lead the design, there comes a point where the thinking that is embodied in the visuals starts to lead. When that happens, user stories start to be generated from the visuals.
3. Get sketchy – and fast.
Confession: I’m still learning to do this. As one who comes from a visual design background, I care (too much) about the quality of the visuals I produce. Designers tend to want to their work to be polished, with well-considered layouts and thoughtful typography. But the early business analysis stage of the project is not the time for such precision.
Early on, the visual business analyst’s job is to help the team build a common understanding of the problem space and to explore possibilities for solutions. Because these represent uncharted territory, you need to move quickly and iteratively to figure out where you are and where you want to go. A visual business analyst needs to dedicate energy to understanding the problem and exploring multiple solutions, not to aligning elements on a grid. Designers need to think of their work as visual conversation starters rather than deliverables.
4. Include the entire team.
The challenge of teamwork, as noted above, is that people with different experience and skill-sets lack a common language for discussing problems and solutions. The power and beauty of teamwork is that focusing a variety of skills and perspectives on a problem leads to both richer and more realistic solutions.
Depending on the process you follow, there may be a tendency to leave technical people out of early business process discussions. Or to leave subject matter experts out of conversations on technical constraints. But this would be a mistake. The more developers understand the business problem, the better technical advice they can offer. The more business people understand the technical landscape, including constraints, the more they’re able to adjust their approach and expectations.
When people understand problems and issues outside of their area of expertise they’re able to leverage that expertise in service of the big picture. It takes a village to raise a complex system. Invite them all.
5. Throw away your work early and often.
This is much easier to do if you stick to point 3. Sketchier work is usually viewed as less complete, so easier to critique. The whole point of visuals as business analysis tools is that they are used to explore the problem and possible solutions. They’re sometimes meant as a question – “Is this how we all see the situation?” They’re sometimes meant as a provocation – “What if we thought of it this way?” But they’re never intended as a declaration of what the final design should be – at least not in the early going.
This might be a different way for designers to think about their work – especially if they’re used to taking mockups through to final visual design. It may also be a different way for team members to think of a designer’s contribution. But in order to build a culture of critique within project teams it’s important that design artifacts not be treated with undue reverence.
While these points may not satisfy anyone looking for the Visual BA “process” (and heaven knows we don’t need any more prescriptive processes), they are key markers on the road to understanding problems and defining better solutions.