Design Thinking for Business Analysts: An Introduction
/BABOK V3 defines the activity of specifying and modelling requirements as one that:
Involves analyzing the results of elicitation sessions and creating representations of those results. When that representation focuses on a solution, the outcome is known as “a design”.
This is where Design Thinking steps up. A Design Thinking approach enables Business Analysts to solve the wicked business problems they’ve always faced, but from a user-centric standpoint and following an iterative process. Design thinking is a way for BAs to create products that meet enterprise expectations by focusing on the right problems and finding the right solutions, all the while delivering products that users really love.
Let’s take a closer look at Design Thinking and how Business Analysts can use it to gather requirements, manage stakeholders and deliver on their objectives.
What Is Design Thinking?
Design Thinking as a concept dates back to the 60s, but it really started to be applied as a way to channel creativity in the 80s, when Rolf Fast and David Kelly’s work at Stanford taught “design thinking as a method of creative action”. Since then, Design Thinking has been integrated into product creation by the likes of IBM, Apple and Google.
Find out more about how IBM applies design thinking
With both products and user profiles multiplying exponentially, Design Thinking is a great way to ensure BAs maintain a user-centric approach while still hitting business markers. Essentially, Design Thinking is strong business analysis applied correctly.
Design Thinking, whether it’s being applied by development teams or business analysts, applies four basic tenets:
- Understand
- Explore
- Evaluate
How Does Design Thinking Work For BAs?
In an enterprise scenario, a Design Thinking approach involves using the sensitivity and perspective of a designer to align user needs with available technology, and tying that into a winning business strategy that has market value. If that sounds familiar, it’s because Business Analysts have been doing this for a while, despite the popular perception that BAs spend their entire time buried in requirements documentation. Design Thinking is good business analysis, applied appropriately.
However, where Design Thinking differs from traditional business analysis is its iterative, bottom-up approach. Whereas BAs might once have taken requirements documents as instructions to be followed more or less to the letter, a Design Thinking approach advocates taking time to understand the context, the motivating factors behind that context, and the complex business goals. Products are built from the bottom-up, not the top-down.
Perhaps most saliently, a Design Thinking approach requires iteration and collaboration: cross-disciplinary teams provide critical input throughout an agile process, supported by prototyping, crowd-thinking and cyclical workflows. The team then comes up with hypotheses, mocks them up in quick prototypes and then narrows the possible solutions down for further prototyping and evaluation.
Instead of defining a solution upfront based on requirements, BAs, designers and developers work together to understand the context better, consider core motivating factors and align them with business goals.
Three Areas BAs Can Apply Design Thinking
1. Scope Definition
Any BA who has ever worked closely with a project manager will have heard (a lot) about scope creep. Scope creep is when the parameters of a project shift after initiation – like when unexpected requirements appear out of the blue and schedules/budgets have to adapt. A Design Thinking approach can help minimize scope creep by implementing more thorough research and modelling of a product or idea in the pre-project kick off stage. For example, requirements elicitation could be integrated with a rapid prototyping workshop and design iterations, to help elicit all functional requirements in one fell swoop.
Involving internal stakeholders – those tricky customers who often come up with ‘surprise’ requirements halfway through a project – in design thinking brainstorming sessions will also squeeze more requirements out of them earlier on, and increase stakeholder engagement much more effectively than asking for feedback on text-based requirement documents.
2. Requirements Elicitation and Analysis
BAs in the requirements elicitation and analysis phase of a project will want to get a coherent idea of stakeholder and user objectives. At this stage, Design Thinking can help gather requirements, define functional requirements and gain a little empathy for end users along the way. Implementing a Design Thinking approach to requirements elicitation and analysis involves:
- conducting early-stage interviews with end-users about their needs
- defining the scope of the challenge
- setting up a cross-functional team of engineers, developers, stakeholders, end-users, functional analysts and project managers
- facilitating Design Thinking workshops – SAP has some useful tips on how to organize and run Design Thinking Requirements Gathering workshops
These Design Thinking-oriented activities work hand in hand with established requirements elicitation techniques, rather than supplanting them. Adding Design Thinking to requirements elicitation means BAs can have complete or near-complete requirements in their hands in a matter of days, not weeks or months.
3. Validation of Decisions
Design Thinking establishes an empirical approach to decision-making, meaning that when it comes to justifying decisions to the development team, or to stakeholders, BAs can present hard facts instead of hunches. Design Thinking ideation sessions allow the whole team to ideate and prototype as many solutions as they can, and then work to find the best solution for the business context. Using that evidence later helps cool the temperature of difficult stakeholder discussions, validate all choices and, eventually, deliver a great product.
The Design Thinking Process In Detail
For BAs, the Design Thinking process should be quick and iterative, whether it’s a single sprint cycle of a week to something more complex where you get customer feedback involved too. Logically, the length of the process depends on the project complexity and the proposed product solution.
Independent of the project length or complexity, a Design Thinking process for Business Analysts will look something like the basic outline below:
Phase 1 – Problem definition
Define an overview of the bigger problem and come up with a mission/vision or just a simple project objective
BA Toolbox: Mission or vision statement, domain mapping, context diagram
Phase 2 – Research and requirements gathering
Collect as much information about the product and business context as possible, elicit information from stakeholders and users, investigations conducted on small break-out teams.
BA Toolbox: Workshops, surveys, contextual analysis, requirement analysis
Phase 3 – Ideate
Create cross-disciplinary teams, present the problem or need to teams, generate ideas collaboratively based on research and requirements gathering. All ideas are valid during the Ideation phase.
BA Toolbox: Workshops, free association, brainstorming, idea generation games and improve activities
Phase 4 – Prototype
Transfer the ideas generated into low fidelity or high fidelity prototypes. These prototypes mean teams can dig deeper into the specifications, testing can be done either internally or externally with users and stakeholders, and a comparison criteria framework can be applied across all prototypes, and all possible solutions.
BA Toolkit: Prototyping tool such as Justinmind
Phase 5 – Selection
Each prototype can be judged based on the comparison criteria and kept or abandoned, and the best prototyped solution selected. Using the evidence of the Ideate/Prototype stage, this selection can be empirically justified to all stakeholders.
BA Toolkit: SWOT Analysis, comparison criteria
Phase 6 – Test and experiment
Test the prototype solution, but before testing, make sure you define key performance indicators and predicted outcomes. There are several ways to test prototypes effectively.
BA Toolbox: Surveys, user testing tools, KPIs, data and analytics
Phase 7 – Reflect
Mine data from the whole Design Thinking process for new findings about what works, and how. Examine test results, re-jig user scenarios, redefine market position and test cases. If necessary, go back to the drawing board ad start ideation/prototyping all over again – Design Thinking is agile enough to allow you that flex.
BA Toolbox: Root cause analysis, data sifting
Conclusion
Business analysts have to be analytical – it’s part of the job description, after all. But that doesn’t mean that creative thinking is anathema to the practice of business analysis. Gone are the days when BAs had to take a set of requirements as gospel and define a full solution upfront. As organizations become more agile and the consumerization of enterprise software continues apace, BAs are required to apply creative thinking to increasingly complex business problems to achieve user-centric outcomes. Bringing a purely business perspective to today’s ‘wicked’ problems just isn’t going to cut it.
Business Analysts should therefore, always look for ways to rise to the new challenges posed by product development and ‘wicked’ business problems. Design Thinking can function as a roadmap for BAs who want to maintain a user-centric approach while they keep stakeholders engaged and apply a business framework. By introducing a designer mindset into their analytical processes, BAs can manage requirements more effectively, define project scope more clearly, validate decisions based on evidence and, eventually, build better products. Design Thinking allows BAs to be more analytical and effective.
Are you giving it a shot already?
AUTHOR'S PROFILE
Cassandra Naji is Marketing Content Editor at Justinmind, a prototyping tool for web and mobile apps that allows you to create high fidelity, collaborative prototypes securely on your own servers.
Picture Attribution: Image courtesy of iosphere at FreeDigitalPhotos.net
