When designing for digital transformation, it’s crucial to understand how you can add value both for customers and for your business. Accomplishing these goals means having the right human-centered design processes in place.
In the first part of this two-part series, we’ll talk about how to ground design in the right research processes before explaining how to make the transition from design to production in Part 2.
The Danger of Overlooking Business Outcomes in Design
There are plenty of examples of beautifully-designed products that solve real customer pain points, but still fail. The problem often lies in over-focusing on human-centered design and failing to recognize the importance of business outcomes.
The reality is that the wrong business model can cause even the most well-designed products to fail. As an example, look at the Bento app that recently shut down because of business-model issues.
Even though the Bento team developed an on-demand Pan-Asian food app that customers loved, the company struggled to keep up with demand and the increasingly consolidated food tech space.
Despite a $100,000 VC investment and a wealth of customers, Bento’s business model wasn’t built to sustain ongoing demand and ultimately failed. If the company had designed for business outcomes in addition to focusing on human-centered design, this might not have happened.
Avoiding a potential business-model problem similar to Bento’s requires, first, the right research processes before anything is ever developed.
How Designers Can Research for Business Outcomes
Conducting design research and grounding design in a well-rounded understanding of project goals is what will help you develop products that truly solve problems.
Your ultimate goal should be to conduct research that leaves you with a journey map that can take a project from concept to execution. There are two keys to creating this journey map:
- Unifying Stakeholder Vision/Strategy: Getting stakeholders together before a project begins is essential for design teams to map out a product that balances business and customer needs. We’ve found that the Business Model Canvas helps us best understand everything from cost structures to company resources to customer/business needs so we can lock down an effective business model for a new product. While some stakeholders may excel at company messaging, others may be stronger in understanding the competitive landscape. This is why we need to unify stakeholder vision.
- Understanding the Users: This is the step where ethnography research is everything. When possible, it is important to look beyond how users answer questions and see how they behave in given scenarios to gain the best insights. However, observing behavior can be time consuming. If you can’t do ethnography research, conduct interviews and validate answers with activities, recording interactions for further analysis. Digging into user behavior has two-fold benefits. First, designers gain insight into pain points that a new product can solve. Second, recording these reactions for the development team can create a sense of empathy in the build phase so everyone involved in working toward solving real-world user problems.
There are many different activities and specific tasks involved with each of these two design research components, but proper execution will leave you with a detailed journey map.
With your journey map in hand, you know that everyone involved in an upcoming project—design, QA, development, project management, etc.—will be on the same page and understand how to drive valuable business outcomes.
Proper Research is just the first step Toward Designing for Business Outcomes
Your research goal is simple:
Carry out research activities that give shared understanding—not just shared documentation.
You could spend 6 months developing documentation that intends to get all stakeholders on the same page. However, a week of in-person research with all stakeholders present can accomplish greater results than 6 months of documentation work ever could.
Now that you know about the research phase of balanced design, we can talk about the transition from design to development in the second part of this blog series.
Thanks for reporting a problem. We'll attach technical data about this session to help us figure out the issue. Which of these best describes the problem?
Any other details or context?