Product Design Process

When we have a new product idea (and are lucky enough to have the skills and tools to execute on it), it’s often more than tempting to jump in with two feet and start building the thing. Before we know it, we’re pitching the hows before whys and problem solving becomes a battlefield of miscommunication. As a result, our product concept becomes more complex and less focused.

Over the last few weeks, I’ve been investing a lot of time and energy into a product design process that we’ll be using for an upcoming project.

I insisted we made investments in our process and put this case to the team:

We’ll Make a Better Product

The main reason for using a product design process is ‘to make a better product’. To query our definition of a better product: a product which outperforms its competition by solving its customers’ problems in a more simple and effective way.

We’ll See Where Value Can Be Added

Distilling the big problem that our product is solving into situations will help us visualise all the moving parts and figure out where value can be added.

Ryan Singer writes a brilliant piece on situation value:

Suppose a team is building a “file versions” feature. Two situations define the value differently and lead to different designs.

In one situation, a person catches an embarrassing mistake in a proposal and wants to know who to blame. In order to do this, they need to see information about intermediate versions. They value the product telling them who made what changes and when.

On the other hand, consider a situation where they want to send the latest version of the proposal to the client. They don’t care how it got to its current state. They just want to send the correct file. In this case intermediate versions have no value. The user just wants to know where the latest version is.

Different situations = different values.

Defining situations will align us as team and conversation will be more constructive and focused on the task at hand; getting users from A to B.

In the absence of code we can quickly iterate through our best ideas, fitting all of the moving parts together. This will maximise our potential of designing a product concept which is simple, useable and more effective in its approach.

We’ll Sing from the Same Hymn Sheet

We’ll waste less time and energy mis-communicating and voicing logical speculation. Instead, we’ll be solving real problems based on real situations.

We’ll know the right time to discuss problems and when it’s right to discuss solutions. Better still, we’ll be contributing ideas from our respective areas of expertise, which will open up new opportunities and unblock us.

We’ll Think Conceptually

Freeing ourselves from code will help us to problem solve in a more abstract way. Code is high fidelity; like cemented bricks. Better to think solely about the product in its conceptual form with something low fidelity, like paper mockups.

The beauty of problem solving on paper is that it’s quick and easy. We don’t need to be artists to present our ideas to each other. What’s more; we can quickly hash-out numerous iterations of a design pattern or technique and pitch them against our view of a better product.

We’ll Build a Better MVP

Once we’ve formulated our product concept, we can outline features that we want to exclude for 1.0; this will form our minimum viable product (MVP).

We’ll know that the MVP we’re building, is in fact, the foundations to our product concept. We’ll waste less time as everything we build will count towards the whole. We’ll loop through less iterations as the UX will have a solid direction, cemented on real world problems.

So far…

The process has already helped us in the areas above. We’re still learning though and adapting to a new workflow is always daunting. We’ll put the process through its paces a little more and I’ll share it on here once we have something to show how effective it is.

In the meantime if you’re working on software projects and care about what you ship, I’d suggest you checkout Rick Hickey’s talk on design, composition and performance as well as Ryan Singer’s post on the Vital Elements of a Product Design Process. Both have been central to designing our product design process.’