Introducing the Outcome Canvas

For a long time, while we were user-centric, we used that thinking to turn requests into features as quickly as we could—just like most design-driven product teams. 

We gathered requirements from organisations and users, and we put them into design documents. Those documents became clickable prototypes that were tweaked and tested until we found something that was easy to use and fit all the requirements. 

By working in cross-functional teams, we were able to work quickly, discover problems and questions more easily, and get feedback from the right stakeholders without too much delay. We could build, test, tweak, and launch satisfactorily. 

Don’t get us wrong, it worked fine. Clients were happy, customers were happy, and we even won some awards.  

But while it was satisfactory, we weren’t feeling totally satisfied. Something was missing. 

The what works, but what about the why? 

We were getting things done efficiently, but we found we were still building things that weren’t that useful. They were a strong and clear what but the why wasn’t loud enough for us.  

We were hearing different voices – the business, the customer, the brand, and the technical team – but we still kept our eyes and our minds on outputs, rather than the outcome we needed to achieve. How could we harmonise these needs and objectives without focusing on individual features? 

It’s not new to talk about outcomes but we wanted something that would concretise it for us. It was when we read  Jeff Gothelf and Josh Seiden’s Sense and Respond  that something really clicked. They talk about focusing on what you want to achieve, rather than what you want to make. In their thinking, outputs are experiments on the road to an outcome, and sometimes experiments fail.

Creating the Outcome Canvas 

This helped us move from thinking about prototypes that you test and tweak, to a willingness, early on, and throughout the process, to consider really listening to these four groups, and (maybe!) killing a feature entirely, changing focus, and thinking beyond the waterfall. But it also got us out of our designer mindset, and pushed us toward acceptance that these products have to exist in complex realities. We’d used Jeff Gothelf’s Lean UX Canvas and Jeff Patton’s Opportunity Canvas, and found them really helpful. But for our purposes, we needed something a little more.

We took this inspiration and developed this simple Outcome Canvas. You can download a template of the Outcome Canvas here.

It asks you to consider a range of questions that can’t be taken separately. What impact do we want to have on the business? Who is the target group and what’s the real problem we’re solving? Where and how does this fit into the brand story? What are the technical areas for improvement? 

When we started using this, we found our mindset became more experimental, the more experimental we were, the better result we got from the Outcome Canvas. As an embedded – but still external – team we can only innovate in the patch where we work, but this was a way to maximise innovation everywhere we could, rather than waiting for a whole organisation to change.  

The canvas asks you to articulate pain points, needs and stories in a simple, succinct way. For example, writing a tweet or the summary of a press release is important for breaking out of our silos. We might understand how everything works, and we might be able to explain it to each other, but how will we describe it in a compelling way for someone outside of the organisation?  

Achievements, not checklists

We’ve found that the canvas helps guide our efforts toward achieving something, and keeps us focused on learning and failing through experiments, without having to guess what works. We can quantify results, and we can act on them. With that much added clarity, the bonus is that working together is also a lot more fun (and yes, we think that matters, too).  

You can use this in any project, but in order to use the Outcome Canvas to its fullest potential, you need to be working in a truly cross-functional team. Otherwise you’ll spend a lot of energy running around trying to find out who can give you the answers to the questions, in the right way, at the right level. We’ve also worked hard to transform our processes on that side, by shifting toward something we call Feature Teams. We’ll cover those in a separate article.  

If you’ve tried something like this, or you try our Outcome Canvas, and you have feedback on it, we’d love to hear it!