Should designers have a seat at the table? It depends on the organization and design maturity—some already do, while in companies with low design maturity, designers are merely decorators late in the process. But what does it mean to have a seat, and what’s expected of designers who create value beyond producing deliverables?
At its core, strategy is choosing what to do and what to leave out. It’s about deliberately prioritizing limited resources (time, money, people) to create value.
Not all designers will engage in strategy. Typically this is the domain of product managers or senior-level designers. Some designers might even eschew strategy altogether in favor of being a master at craft. There’s nothing inherently wrong with that, but if you do want to grow your influence in a company, then understanding the business, how it makes money and how design can help, will help you advance rapidly in the organization.
When you’re interviewing, demonstrating that your work has led to success will make you stand out. Yes, it’s hard to get crisp data and many designers struggle with showing results of their work beyond the deliverable. If you are in this situation, follow up with your team. Get the data. Get the information you need; not only will it be important for interviews—it’s important as a feedback loop overall.
Figure: Scale of Impact
Scale of Impact
One way to determine your level of strategic prowess is to look at the scale of your impact—how effective was your work and who benefited from it?
Team(s). You made your team more efficient by bringing in new tools or by holding training that helped everyone ship new features faster.
Department(s). You shipped a feature for an internal tool that has made everyone’s lives in this department easier.
The company. You created an outsize impact for the whole organization by either reducing costs or increasing revenue and profit.
Industry. Your work is known outside of the company; you’re a regular speaker at conferences and have created strong brands.
The impact of scale is also relative. For example, improving a particular feature may affect a small population of a company’s user base. However, if this feature dramatically improves their experience, then that impact can be still considered significant.
Outcomes and Measuring Success
Design exists to solve issues, but measuring efficacy of solutions is often fraught with complexity. It’s not as simple as showing that doing Y improved a metric X by 10%. That said, ideally before engaging in any project, you have a rough sense of baseline measurement and understand how the experience is currently performing—what parts are working well and which aren’t.
In your work, ask yourself:
When and how do you define success for your projects?
In absence of data, how did you define a baseline and success?
What types of data do you use to measure progress—qualitative or quantitative? Are these the right measures? Why?
Sometimes it’ll be impossible to get any quantitative data, or you may have already moved on from the company. If that’s the case, you can reach out to the company to see how your projects have fared. Alternatively you can also find other ways to measure success, for example by including a customer testimonial or playing back clips from research participants delivering a similar message. Don’t constrain yourself to quantitative feedback alone.
This one is natural to all design processes. Understanding the problem that you’re trying to solve for and the opportunity that’s ahead of you will help you make appropriate decisions when you’re deep in the design process. Waiting too long on gathering all the problems will hinder momentum, but not taking the time up front might also cause you to solve the wrong problem and not make any progress on the underlying issue.
Consider these questions:
Do you approach a problem from first principles?
Based on your previous experience, did you accurately represent the problem? What did you get right? What was missing?
How do you push back when the problem is not accurately portrayed or framed?
How well can you prioritize problems so that the most important one is solved first or addressing one can address many of the subsequent pain points?
Problem framing is a whole exercise unto itself. Many times, it’s not as simple as writing out a problem statement, agreeing on it with the team and calling it a day. Oftentimes additional problems come up, and as a designer you’ll have to come back, reassess, and make calls of when to pause and when to execute on the work.
Solution Framing and Exploration
Framing the problem is half the battle. If the solution to the problem isn’t well thought out or built, then in some ways the steps that come before that were a waste.
What type of solution are we going for? Should this be a quick-win MVP?
How does this solution overlap with other solutions? Are we shipping the org chart, or is this a meaningful way to solve a customer’s problem?
Is this solution feasible to build? Will it take significant resources to build and launch?
In the professional world of design, as mentioned previously, quality varies depending on what you want to learn. Sometimes it’s paramount to launch fast with minimum features in order to learn; other times it’s important to have the final polish to stabilize the experience and potentially solve for new issues that customers may not even have encountered yet.
Strategy is a big topic and resources abound. You might find these useful: