Crossing the Imaginary Line - Design Thinking in Business Analysis

A core belief in the traditionalist viewpoint of software development is that Business Analysis focuses on “what” the client wants while design concentrates on “how” to deliver the solution. As a Business Analysis practitioner, I can discover and describe a requirement that specifies the ability of a user to capture their state (or province) of residence. However, I dare not mention where on a screen or the usage of a drop-down list because that crosses the imaginary line between requirements and design. For some, a requirement must be design-agnostic in order to be considered a good requirement. A requirement should not specify aspects of physical design, implementation decisions, or system architecture. This is traditional thinking, and many contemporary Business Analysts see this as a truism.

I can respect and appreciate how this viewpoint originated. It is largely reflective of a waterfall perspective of software development where we needed clear hand-off points. I suspect that some designers viewed this distinction as necessary to preserve their domain of control. Yes, there is a territorial component.

I have a different perspective. I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking.

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.

1. Create Models to Examine Complex Problems

Use visual models, to discover, specify, and communicate the business problem or business opportunity.

• Consider adding Mindmaps to your toolkit of Business Analysis techniques. Mind mapping makes it easier to decompose the elements of a complex problem into separate components to facilitate solution discussions. Mindmaps can show the relationships between different elements of a problem domain and trigger the identification of gaps. This tool allows a group to collectively get a better understanding of challenges, generate more solution ideas, and reach better results. 

• Leverage models to describe processing when there are differences of opinion on how the current state operates. Consider using models when there is a lack of clarity regarding the context leading to a business opportunity or the context causing a business problem. 

Design thinking as a Business Analyst to examine complex problems will typically receive little resistance from business or delivery partners on a project. Design team members generally take a hands-off approach because the model is built without consideration of usage from an implementation perspective. To illustrate this point, I can relate a true story at a client site where I once asked for access to a product called ‘iRise.' There was some contention about this request from the UI/UX team. When I explained that I wanted to draw the current state, the resistance evaporated.

2. Use Visualization as an Elicitation and Analysis Tool

With design thinking, we frame the details of the user journey using a visual context.

Visualization is a useful technique to collaborate with our business partners in the discovery, understanding, and description of their needs. It is a way of giving context to needed functionality. Whiteboards and wireframes allow us to engage our stakeholders in a manner that allows them to see a little of how the solution might look and behave. Visualization moves elicitation past an approach of using questions to trigger the discovery of needs into a dialogue with an interchange of ideas. It is about ideation.

Visualization can:

• Challenge assumptions made when high-level business needs were presented using textual statements

• Provide an understanding of business needs in a rich, tangible context

• Confirm the completeness and accuracy of needs previously presented

• Trigger the identification of missing requirements

The outcome of using whiteboards, storyboards, wireframes, and simulations is a happier client and better requirements information.

Using visualization as an elicitation method can result in some challenges if there is an organizational unit dedicated to the UI/UX practice. In this situation, the Business Analyst needs to partner with skilled resources and take a collaborative approach to the usage of visual models.

3. Respect the Primacy of User Experience Needs

Thought leaders in the design thinking arena point out the empathy must be treated as an obsession when developing customer-facing applications. As Business Analysts, we need to place ourselves unreservedly in our users’ shoes. This requires a mix of immersion, observation, and dialogue.

Business partners in the delivery lifecycle have a valid right to articulate components of the “how” that affects the user experience. People want their interactions with technology to be simple, intuitive, and pleasurable. User Experience requirements can make the difference between a product that fulfills a need and a product that delights the customer.

The outcome of empathy and immersion requires a rich description of business needs beyond textual statements. Visual and interactive models are a necessary artifact to successfully define and communicate those needs. The days are long past when we can reference platitudes such as “easily” update a field as a legitimate expression of a User Experience requirement.

4. Utilize Prototyping

Consider utilizing prototyping as another way to represent business requirements. This is a value-add technique listed in the Business Analysis Book of Knowledge (BABOK). Prototyping is a way of bringing abstract requirements to life in a manner that allows stakeholders to get a feel for what is required. This is for the purpose of fact-finding and not dictating system design.

Prototypes can be quite effective as a route to:

• Confirm discussed business needs as well as

• Uncover potential gaps and areas of conflict

• Reveal items that are really superfluous

Prototypes can start taking a low-fidelity approach such as producing a quick sketch. Prototypes can be elaborated by using a high-fidelity approach that reflects look and feel as well as elements on a screen. This would be closer to the final solution but could set unrealistic expectations about the look and feel of the solution.

Using prototypes needs to be balanced with understanding that the amount of resources committed to building the prototype should not exceed the level of detail required. As Business Analysts, we cannot treat prototyping as a design exercise to illustrate the final solution. We need to leverage prototyping in the context of our role.

Conclusion

No matter your background, age, or experience, we all share a desire to be successful. As noted in the beginning, we need to embrace design thinking in Business Analysis and not be afraid to cross the imaginary line between requirements and design. To some, this is new thinking. To others, design thinking has been part of their toolkit for a while (implicitly or explicitly). What has your experience been? What advice would you provide? Cheers to your success and future learning.

Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.