The Product Design Canvas
Let’s communicate better, earlier, and more often with PMs, engineers, and our fellow designers.
I’ve been doing a lot of thinking of ways to improve the design process. A common theme that I’ve experienced here at Twenty20, as well as hear from other designers is around the topic of communication. More specifically the early communication that takes places as the design process starts.
Product designers communicating early and often with PMs and Engineers is a MUST. –tweet this.
The early conversations with PMs, engineering and other designers about a potential design solution are massively important. They will help facilitate collaboration and accelerate the process as a whole. However, all too often these “tap on the shoulder conversations” being informal by nature aren’t well contextualized nor executed to get the best feedback-bang for our buck. I believe we can change that. I believe a quick 5–10 minute conversation can yield great feedback vs. just a bunch of head nodding.
It’s all in the context.
Without further adieu, I present you with the handy-dandy 2016 Product Design Canvas [insert ooohhhss and aaahhss here].
Download The Product Design Canvas
Ok, ok… Maybe it’s not the most mind-blowing thing you’ve ever seen, but just wait until you have your first early design feedback conversation using this puppy. Life changing I tell ya. So good I’ll even throw in a money back guaranteed if you’re not 100% satisfied. Alright, enough with the hard over selling and back to the real value at hand.
The magic in using the PDC (yup, going acronym here) is added context alongside a proposed design solution, all in a single glance. The real issue with the “tap on the shoulder conversation” is the context switching required from the person we’re asking feedback from. Chances are the PM, engineer, or design teammate is focused on another user story or project entirely. The PDC will not only help us explain the rationale behind our design solution but will help our teammates context switch a whole lot quicker. All equaling the reception of much better feedback and/or buy-in.
The PDC is broken down into two main sections.
Context
- Problem we’re solving
- Who we’re solving it for
- Business goals
- What we know
Solution
- Proposed design
- Pros & Cons
Context: Problem We’re Solving
This section should be relatively easy to fill in as sometimes it’s already been written in the form of a user story by the PM. But that’s not always the case. Some user stories can be written in a task-oriented format. (ie. I, as a medium reader, should be able to download the nifty Product Design Canvas.) When this is the case, it’s still very important to identify and write the problem needing a solution. Before I begin any design solution I always make it a habit to ask…
What problem are we solving for our users?
How do we know it’s really a problem?
Are we solving the right problem, right now?
Why is this important? Because it will guide the conversation and position the solution from a place of user empathy.
Context: Who We’re Solving it For
In this section, I like to be specific without going into any sort of persona style of detail. Personas are for a whole other medium post… Typically, I find success in writing details such as “Users who have done X, Y, or Z” or “Users who are about to churn.” This will then tie together very nicely with the “What We Know” section of the canvas.
Context: Business Goals
A designer’s job is to marry a user’s needs with the business goals in a happy little union resulting in great product.
Any and every design discussion needs context of the business goals. –tweet this.
There are a number of ways to frame the business goals. From the top-line metrics your team is trying to move, to a more generalized key result that will impact the business positively. I prefer to leave hard success metrics off the PDC. For example, I’d write the business goals as “Increase retention” vs. “Increase retention by 15%.” Don’t get me wrong here, having clear success metrics in place is crucial. I just tend to leave that level of detail on the user story card in Trello or Jira.
The important piece is the simple amount of context that helps properly frame the solution.
Context: What We Know
I love writing in this section and frankly, wish it was a bit larger. It’s ok, just means I need to write a bit smaller and it’s time to break out the 0.3 lead pencil. (Quick nod to Ryan Nance.)
What we know and learn of our users is the crux of intentional design. –tweet this.
This section takes research, both on the quantitative and qualitative fronts which make it a very important piece of the PDC. What metrics can we access to help better frame the problem or strengthen our proposed solution? We know who we’re solving the problem for. What are we hearing from them through user interviews or customer support tickets?
Solution: Proposed Design
I’m a huge fan of using good old pencil and paper to start conceptualizing and talking through various design solutions. I’m thinking that this section doesn’t need much more explanation, so let’s move on to the pros and cons. Cool? Cool…
Solution: Pros & Cons
After sketching out a potential design solution, I find it very helpful to list out the pros and cons of the solution. This will not only show forethought but can also spur constructive feedback as you talk through it.
Often times pros & cons will be related to the product team such as the time to implement or other technical/design dependencies. Also, how the solution could positively or negatively affect the user.
When working through multiple solutions to the same problem, you’ll begin to notice how the pros & cons list will help you and your team quickly select a direction to iterate on.
Disclaimer:
The purpose of this PDC is in no way intended to take the place of a formal design critique. No way! Its main purpose is to help facilitate contextualized conversations early in the design process.
I’ve provided the PDC template as a reference tool for you to use. While it’s functional and works, you may need a bit larger of an area to sketch your solution. I normally do. Think of it as a framework that you can draw on the whiteboard or where ever else you choose to start the design process.
So, what do you think? I invite you to leave me a response and let me know if you find the PDC useful, or if anything should be added to it. I always appreciate feedback. :)
Personal disclaimer: One of my goals is to start writing about design and product a lot more in 2016. Admittedly, I have a lot of work to do in order to become a better writer. I’m very aware of that. With anything, practice makes perfect. Thank you for bearing with early iterations of my writing style. I promise to get better and try hard to deliver as much value with a side of personality as possible.
