Crossing the Imaginary Line - Design Thinking in Business Analysis

Featured
26549 Views
4 Comments
62 Likes

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.


 


 

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.

Like this article:
  62 members liked this article
Featured
26549 Views
4 Comments
62 Likes

COMMENTS

Martin_L posted on Tuesday, June 6, 2017 9:15 AM
Thanks for the interessting article.
In my opinion, especially in an IT-World, which is getting more and more agile, it is very important to use prototyps in addition to textual requirements (like use cases).
At the beginning of my role as a BA I didn't do that. So, the customer often had the problem to understand how the requirement really works at the end. If you have a prototyp in addition, you are getting in my opinion faster a commited result and feedback of the customer. Especially, the customer has (most of the time) a lot of fun in the workshops creating a prototyp.
So, whenever possible I do both: writing down the requirements in a textual way (or using a graphical representation like BPMN) and create a prototyp (with the methodology Rapid Design Visualization).

Martin
Martin_L
Steve Andrews posted on Tuesday, June 13, 2017 9:53 PM
I also think that there is only a conceptual line between requirements and design. I find that when we speak to the business about their requirements they have already designed their requirements because they have visualised what they want which pushes us down a design path. The issue as I see it is if we don't push back against 'design' then all we end up building what they have conceptualised which may not be what they NEED. I suppose the question is - do we want to eventually build what they want or what they need.
snugman01
David Wright posted on Thursday, June 15, 2017 8:33 AM
Hi Michael,
Borders between countries are also imaginary lines but crossing them can often trigger a vigorous response. I once went down path of using UML for requirements/business modeling, only to meet with designer resistance: "That's our thing." (was a good response actually, UML is not good for business modeling, despite books that say it is.) ... but visualization is indeed helpful, as long it is stated that actual solution may look different when delivered.
dwwright99
Jordan123 posted on Tuesday, June 20, 2017 1:48 PM
Great article! Thought I also agree with snugman01 and would add that if at all we start thinking 'design' during the requirements stage we should make sure we state it against the requirement as a 'design suggestion' rather than as the actual underlying requirement. I still see lots of value in the original concept of trying to stay design-agnostic as it should be left to the solution team to design the cheapest, and hopefully best solution(maybe with additional benefits the user hadn't even thought of!) that meets the requirement. requirement. In addition go back to user with the proposed solution before implementing it so they can compare it with their original design option and see for themselves which is better.
pit2009
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC