And how problem-focused design can help.
A popular diagram showing how the complexity of a project rapidly increases as the number of stakeholders grows, looks like this:
Still, stakeholders are a layer of a larger cake that includes things like culture, priorities, timing, feasibility and research:
The user is in that stack—but there’s a bunch of other stuff too. How do all those other factors affect the design of a product? How can over-indexing on the user be a deterrent to the ultimate success of a business?
The fundamental job of a designer is to bring stakeholders through these layers to a shared vision of success while establishing alignment on the inputs and outputs of a project.
User-centered design has led us to be hyper-focused on individuals, perhaps at the cost of appreciating a wider range of inputs. So, let’s take an in-depth look at problem-focused design so you’re better equipped to solve problems in a way that brings consensus across your teams and business.
Every good solution requires a problem and any analysis that doesn’t begin with the definition of the problem runs the risk of developing into a string of opinions.
Problem statements link different perspectives to shared, objective goals – without them people would interpret based on feelings and emotions.
However, what is the best way to describe a problem and how can you be sure that it is actually being resolved? Enter Full Problem Perspective (FPP), a tool to see the full range of causality for any given attribute.
FPP uses the wildly popular job-to-bead framework to transform research on users, jobs and barriers into actionable workstreams and success metrics.
research tells us about our users And this Jobs they also need to complete obstacles preventing them from completing those tasks. Then, we make hypothesis how to beat those odds and matrix Which will tell us if we have succeeded.
Depending on the scope, a job may map to a smaller facility, a larger project, or an entirely new business unit – from there, user stories are derived from the work required to validate the hypothesis, whereas Constraints can be used to construct problem statements.
An added benefit of FPP is that it can also be applied to internal stakeholders and we need meta jobs within our companies to be successful.
This framework lends itself well to workshops or whiteboarding exercises because the layers of the framework serve as a wonderful template for filling in sticky notes.
Once a full perspective of a problem has been created, it is easy to fabricate statements that can be traced back to agreed-upon truths of a project. The result are user stories or problem statements that are far less esoteric:
“As a [persona] i need [obstacle to overcome] So that [job I need to do],
It is quite common for fragments of the above phrase to be omitted – for example, people often exclude the “so” at the end. However, remember, without a full perspective, any analysis of the solution becomes subjective.
Building a UI is one of the most expensive things a development team can do. Therefore, most of the designer’s work should be done before reaching the UI solutions so that the team can ensure that the UI solution is absolutely needed.
Ways designers practice invisible design:
- first principle thinking – Ask how you think of a way to solve it until you reach the most atomic description of a problem
- relevant inquiries— Observe users in their real environment to see behaviors that are not observable via telemetry or video
- paradigm shift – Consider ways to fully leapfrog in the emerging direction to provide innovative solutions that save money and time
- harm reduction – Develop solutions that introduce the least amount of negative consequences relative to their potential value to the business
As an example, during pioneering design for enterprise products at Chime, I developed a cost inefficiency (COI) model that is able to project the cost per second of bad processes in our call centers.
The COI model enabled our team to detect inefficient processes and redesign related workflows, saving our company money while not engaging our R&D teams with a UI-based solution.
It is rare that the design process should involve an immediate visit to the design tool. First, consider all the ways you can solve a problem so you can be sure you’re arriving at the most efficient solution.
Read almost any job description for a product designer and chances are it says something about dealing with ambiguity – successful designers seek the unknown, answer it, and bring order to the uncertainty.
Chances are the half-baked PRD you got two weeks ago is the best you’ll ever get until you help out: Roll up your sleeves and lean into the void; Ask tough questions and find good answers.
- Try to improve processes, communication and time use
- Bring people together in teams, organizations and silos
- Understand the scope, feasibility and limitations of technology
- Document decisions, deadlines, and assets for posterity
- Make sure everyone is using the same nouns and verbs as the project.
- Bringing together all stakeholders, ensuring alignment and consensus
And the best hunter-gatherers find gaps that no one else sees, working diligently to fill those gaps so that the project can be successful – ultimately translating to a wicked web of complications. Given all the available inputs, this is the most useful experience possible for the user.
Much has been written about the value of design and how good design has been shown to be a competitive differentiator for companies. However, good design can happen only if the rest of the machine is well oiled.
Companies like Apple seem to have caught up to the design process. Although for every Apple, there are hundreds of less well-tuned companies that employ thousands of designers in the world.
The reality of product design is that most designers are more likely to work in environments that require them to be more than just experts on users—and it’s now more important than ever that those designers are problem-focused. Start practicing design.