A Framework to Design for Impact

Design serves a purpose, solves a problem, addresses a need. This gives us the natural boundaries to create a design framework that we can use repeatedly to deliver results. To make an impact as designers, we must be motivated by delivering results. The good news is, there’s a repeatable process we can use that many designers before us have proven.

To design for impact, we need answers to three main questions:

• Whose problem is it?
• What’s the real problem we’re trying to solve?
• How will we know if we’ve succeeded?

Whose problem is it?

Our goal here is to build empathy: for the business, for customers, for the technical landscape. We’re seeking to understand what other people are going through and what the system is capable or incapable of in order to solve problems and find solutions. This desire will drive our commitment and creativity. But we don’t want to get so immersed that we lose objectivity.

We need to walk that mile in someone else’s shoes, then put our own back on.

To understand the problem we’re trying to solve, we need context: business and customer context, as well as any delivery constraints. Often, business stakeholders ask for a feature to solve a customer problem when, in fact, it’s a business problem. Or worse, a problem that customers experience is actually one that’s created by the business, rather than a customer need.

Understand the business context

Why is the business asking for a feature? They almost always frame it as a feature rather than a problem. It’s our job as designers to de-construct that feature into a problem statement in order to unpack the motivations.

• Why is the business asking for the feature / problem to be solved in the time frame that they’re asking?
• Is there competitive pressure?
• Is it a first-mover advantage that the business wants to take advantage of?
• Is that team’s funding dependent on this problem being solved?
• Etc.

For every “crazy” request, there are usually deeper reasons. Find out what those reasons are. As designers, we’ve been conditioned to have empathy for users. Go one step further: build empathy for stakeholders. This delivers a one-two punch: first, building empathy for stakeholders help us unpack the reasons behind the seemingly crazy requests, and more important, the empathetic relationships we build foster mutual trust and may actually empower us to dial down the crazy.

Understand the customer’s context

Dig into the motivations behind the requested feature or the problem statement from a customer’s perspective:

• Why are customers asking for the feature?
• What are the underlying motivations?
• What conditions generated the problems that customers are experiencing?
• Could the problem at hand be eliminated by resolving an issue upstream?
• Etc.

Understand the delivery constraints

Often, especially in enterprise settings, the most usable/user-friendly/customer-centric solution is not feasible for a variety of reasons:

• The existing antiquated technology infrastructure can’t support the solution
• The solution runs counter to the organization’s business model
• There’s no business appetite to pay for the ideal solution.
• The technology needed to support the solution doesn’t exist right now
• Etc.

We can sit around and bemoan the delivery constraints, or we can find ways past or around them. It’s not helpful to think in terms of ideal versus compromise. The real world is all about costs and benefits, pros and cons, give and take: our job as designers is to find a balancing point that delivers a user experience that the business can feasibly fund and that engineering can technically enable.

What’s the real problem are we trying to solve?

The business, customer, and technical context we gathered gives us the data we need to triangulate the real problem we’re trying solve.

The project might have started off with one request, but in digging behind the request, we may uncover something deeper. True story: once upon a time, the business asked for an ‘download PDF’ feature, but digging deeper revealed what customers actually needed was a spreadsheet they can manipulate for custom queries they need to run. Without the research, we would’ve agonized over a ‘download PDF’ feature that included trying to figure out how to message customers whose PDFs take 24 hours to generate, when all they really needed was a .csv export. In fact, because a PDF is a static artifact, customers are copying and pasting the data from the PDF into a spreadsheet.

Defining the right problem is more than half the battle. We can’t reliably deliver an effective solution if we focus on the wrong problem.

How will we know we’ve succeeded?

Building in a feedback loop is critical to the success of any design solution.

• Did we frame the problem statement correctly?
• Did our solution create any new problems?
• Did our solution solve the problem?

Always be testing

In the problem framing stage, we talk to customers to validate our problem statements. We believe our idea Y solves problem X. First, we need to be sure that problem X represents a real business opportunity. Many ideas arise out of problems we’re solving for ourselves. For our solution to be financially viable, we need to find out if enough other people share the same problem and are willing to pay for a solution. In other situations, businesses create problems for their customers and then try to sell a new solution for those problems; is it possible to eliminate the original problem to begin with? Perhaps the real problem to be solved is further upstream.

In the solutions framing stage, we test our solutions to identify any usability issues before we release our solution into market. If our solutions are complicated, hard to use, or otherwise unusable, we haven’t actually solved the problem. Testing solutions before we commit the time and resources to make those solutions is a gut-check: the goal is to identify as many usability issues as possible. Better that we discover and address usability issues than to have the support team be overwhelmed by customer complaints.

Analytics

In the delivery stage, we need to bake measurement points into our solution to feed us the data that tells us whether our solution worked. These measurement points can range from specific things we want people to do, such as calls-to-action, to behind-the-scenes tools such as heat map and click analytics tracking.

Often, we release and walk away. As designers, we should hold ourselves and our work more accountable. From a career perspective, holding ourselves accountable gives us credibility. If we work as consultants, holding ourselves accountable is also good for business: it presents natural opportunities to check in with clients after the project is done.

Conversion

If we can’t answer the following two questions, we need to go back to problem-framing:

• What do we want people to do?
• How will we know if they’ve done it?

Being clear on what we want people to do helps us understand how to measure success. Maybe it’s “sign up for our services”;  “buy our products”; “create better onboarding so that customers don’t have to waste time calling us for support”. Sometimes, it can even uncover business gaps or opportunities: for instance, if we want people to go to a brick-and-mortar store to complete an action, we need to be prepared to handle the increased store traffic or risk alienating hard-won new customers.

Easier said than done

Three steps. Is that all? Yes, these are admittedly three giant steps. And they’re not easy either. However, they offer a structured, foolproof way to get started. For projects that are complex, this 3-question design framework can help us manage the chaos. For projects that appear simple, this 3-question framework can sometimes expose underlying complexities early enough for us to organize around. It’s a framework that has served me well and helped me design for impact.