Outcomes vs. Outputs
#46: Why should you focus on the outcomes of your work
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community.
Outcomes vs. Outputs
Have you ever stopped to think whether your work actually makes a difference? Are you improving users' lives, increasing your company’s revenue, or making collaboration within your team smoother? I hope the answer is yes.
But the truth is, as designers, we often get too caught up in the artifacts of our work. We rarely stop to ask what kind of impact they have, if any at all.
We talk a lot about the visual results: beautifully crafted interfaces, polished branding, slick animations. Don’t get me wrong, I believe these things matter, and I personally love that part of design.
If we don’t stop to ask why we’re creating them, what value they bring to the organization, and what user problems they actually solve, then they’re just pretty pictures. And making pretty pictures alone doesn’t create value.
But it’s not just about visual artifacts. In our daily work on a product, we often spend time on things that don’t really bring meaningful value. From too many workshops, excessive documentation, and inefficient internal processes to launching features or even entire products that don’t solve any real problems.
As a result, we as designers fail to bring real value to the product and the organization we’re part of. And that becomes especially visible in today’s challenging times for our industry.
Outputs vs Outcomes
Let’s take a closer look at the difference between the work we deliver and the outcomes it creates.
What are outputs
Outputs refer to all the tangible results of the work and tasks we perform. For a designer, typical outputs might include:
Mockups and prototypes
User flows
Information Architecture
Research reports
Personas
Design systems
Documentation
In a broader product context, there are many more outputs created during product development, such as:
Completed features or the product itself
Roadmaps
Product specifications
Data analysis reports
Sales landing pages
Advertising campaigns
Knowledge base content for users
As you can see, these are concrete artifacts that are easy to show and count. They are part of the process of achieving the intended outcomes. While outputs are necessary, they should not be confused with the actual results of our actions, as they are merely a means to an end.
What are outcomes
Outcomes are the real effects and value that our outputs bring to users and the business. Examples of outcomes include:
Users find what they’re looking for more quickly,
Increased conversion rates,
Reduced cart abandonment,
Better understanding of new features by users,
A 20% increase in customer satisfaction,
A 15% reduction in user errors,
A 10% increase in website conversion rates,
Improved accessibility for people with disabilities.
As you can see, outcomes, unlike outputs, don’t focus on the artifacts we’ve produced but on what we’ve actually managed to achieve through them. They often relate to things like customer satisfaction, engagement, loyalty, or other indicators that improve business performance and user experience.
Even though outcomes are harder to measure than outputs, they’re what truly tell us whether our work delivered real value.
Of course, we’re focusing here on the positive changes, but it’s important to remember that not everything we create will lead only to the intended, positive results.
The Output Trap
At first glance, once we understand the difference between outputs and outcomes, it seems obvious that the latter is far more important. So why do designers so often fall into the output trap, forgetting about the actual results of their work?
There are a few reasons. First, outputs are easy to measure and count. It's much simpler to show that "we did something" by pointing to the number of outputs, wireframes we designed, or features we shipped. The organization sees activity, and the team looks busy.
As designers, we also enjoy creating visually appealing things. They’re easy to showcase in a portfolio. Many junior designers don’t yet realize that nice images alone aren’t enough to make a solid case study.
There are also other factors at play. Limited access to data, lack of clear success metrics, or pressure from the organization to deliver fast rather than effectively. In such environments, it’s much easier to focus on what’s visible instead of the results that may come later.
Another issue is the general product mindset within the organization and among its leaders. Even when teams work in agile frameworks, many habits from the waterfall model remain, with design, development, and delivery treated as a one-off process, without iteration or analysis. In many corporations, there's also a “busy culture,” where generating artifacts is a more visible way to show you're working.
Why we should focus on outcomes
Let’s take a moment to consider what would be more valuable for the organization: the number of designed mockups or the percentage decrease in cart abandonment?
This is exactly why, by shifting our thinking from outputs to outcomes, the work of designers and entire product teams becomes far more valuable to the organization, which in turn will deliver real value to users instead of unnecessary, unwanted features.
The time spent creating artifacts will no longer be wasted on actions that don’t meet goals or improve anything for users or the company. By focusing on results, we continuously plan the next steps that are meant to improve user experiences and increase the organization’s revenue.
This shift also allows us to design more thoughtfully. We will no longer create artifacts that don’t bring value, but will start asking ourselves which specific artifacts are needed to achieve the intended goal. As a result, we’ll be able to better justify our design decisions when presenting our ideas to stakeholders. Wireframes alone may not be appreciated, but the results we can achieve with them definitely will. As designers, we show that we’re delivering value that enhances user experiences and helps meet business goals, not just creating aesthetically pleasing mockups.
Focusing on outcomes also helps with prioritization, as we determine what truly matters and will bring real benefits to users and the organization, instead of implementing trivial ideas collected in the backlog.
Working toward a shared outcome also strengthens cross-team collaboration. Product managers, designers, and developers no longer work solely within their individual competencies, but play together toward a common goal.
It’s also worth mentioning that outcomes can be measured, allowing us to track whether our efforts are achieving the desired impact and to iteratively develop the product based on real metrics and data.
How to go from outputs to outcomes
If your organization is still primarily focused on outputs, the first step is building awareness of the difference between these two approaches and the benefits of working with an outcome-oriented mindset. Without that, it will be very difficult to make any meaningful change.
It’s also essential to ground the projects you start in the results you aim to achieve. Don’t begin with a list of outputs to deliver, start by identifying the problems you want to solve, and defining how you’ll measure whether your actions had the intended impact. What user behavior or business results will signal success?
Only after that should you start thinking about the artifacts you’ll need to reach those goals. It’s far better to begin with a hypothesis like: “Simplifying the checkout process will reduce cart abandonment by 15% within a month of release,” than to jump straight into designing a new checkout flow. Of course, such hypotheses need to be validated first, through quantitative or qualitative research and analysis of existing data, before jumping into solutions.
It’s equally important to monitor what happens after changes are implemented and to respond if they don’t deliver the expected results. We don’t want to spend weeks on something that doesn’t actually move the needle. Instead of shipping a solution and immediately moving on to the next thing, we should continuously test our hypotheses, track what works and what doesn’t, review the data regularly, and adjust our actions based on what brings us closer to the original goal.
It’s also worth noting that this mindset shift shouldn’t apply only to designers, it needs to happen across the entire product team. Too often, designers are expected to simply deliver polished outputs, rather than being empowered to think in terms of outcomes.
This mindset isn’t just relevant to product development, where we focus on improving user experience and business metrics. In our day-to-day work, we also deal with internal challenges like poor communication, messy documentation, disorganized files, and inefficient meetings or processes.
In these cases too, we should think in terms of the outcomes we want to achieve. I’ve often seen or heard from other designers about well-intentioned changes within teams, whether big or small, like reorganizing Figma documentation, that didn’t lead to any meaningful improvement. That’s why before introducing a change, we should first clearly identify the problem we’re trying to solve. Only then should we think about how to solve it, not the other way around.