Practical design for products (Introduction & Validation)

Published in

Bootcamp

11 min readSep 8, 2020

Whether you are a child dreaming of a game that will change the world or a seasoned designer with a revolutionary app concept, the capacity of our ideas is near infinite. Unfortunately, somewhere between putting the pen down to a page to the final solution, our vision at best will inevitably change to user or stakeholder feedback, and at worst becomes a Frankenstein monster, forever trapped in endless feature creep. Products thrive or die on millions of micro-decisions directly and indirectly affecting your consumer, architecture, and team. How could we possibly manage this mountain of never ending challenges? Fear not! In this article you will learn a variety of practical tips and tricks to verify if your idea is feasible and identify what the “seed” of your idea needs to flourish. By the end, you will have a clear process to proudly present to an investor, boss, or team.

What Do I Need To Know To Be A Product Designer?

Let’s start with what a product designer actually does. Product designers come from a wide variety of backgrounds and skillsets. However, there are three core skills that are consistently observe in experienced product designers:

UX Research. Understand and critically analyze your audience, their requirements, existing user flows, and validation through usability testing.
Design Theory. Visually communicate design principles and mockups.
Business Development. Identify and translate user needs to a produceable, scalable business model.

Combining these together gives us the ability to empathize, create, and validate a product throughout its lifecycle. We can theorize with our design and then use our experience with our research and operational knowledge to continually improve our process.

Product design is to be treated like a science. The more effectively you ‘define’ each step of your process, the more valuable you will be in your career.

Your job as a product designer is to show marketable improvement to a human centered problem. How effectively you quantify both the analysis and solution around that human centered problem defines your success in this line of work.

How is Product Design Different from other roles?

Product Designer is often used interchangeably with other positions, but what really makes a product designer different?

The jobs of closely related roles:

UX designer. Specifically focused in the customer journey process (UX Research and Design Theory).
UX Researcher. Specifically dedicated to understanding and analyzing user behavior (UX Research).
UI Designer. Specifically dedicated to guiding the user’s eye to content as well as the creation of visual and interactive elements (Design Theory).

Aspects of each of these are used in product design, but primarily lack the business model side of the equation. Product designers validate and balance UX goals, research, and visuals with the needs of developers/project managers creating the “minimum viable product” and “go to market” strategy. Great product designers are experts at understanding prioritization of impactful features for their customers.

Now that we know the basics, let’s get started!

Steps To Building Your Product

Before getting to a sexy, beautiful, usable application, a variety of steps need to be taken to lay the foundation that will guide you. In traditional UX Design, we would utilize the following workflow:

Plenty of excellent articles have been written on research methodology (see the links below or click here), however as a product designer we have the additional responsibility of building our business methodology in conjunction with our research. Therefore we will utilize a modified version of the traditional UX process.

Design Process Pyramid

There are five primary steps to product design, from the initial validation of the app all the way through the finalized design. This is the design process pyramid with each element below building from the last to make a hierarchy supporting our soon to be product. We will briefly cover each part of this pyramid before diving into the first process “validate”.

Validate. Prove out the market you are targeting. Identify areas for disruption and build a preliminary understanding of your customer base.
Ideate. Craft your initial offering for your audience. Identify a variety of potential solutions and rapidly iterate on low fidelity wireframes. Identify the “flow” of your design/application. Test this on participants.
Business Model. Transfer your value into the business model canvas. Identify how you reach your audience and the toolkits utilized. Identify your costs and your revenue streams that will make your idea viable.
Design Philosophy. Documentation describing what your solution stands for and the principles that will guide you to design the most necessary features.
Design/Iterate. Create your initial high fidelity wireframes and test your results on your participants.

Note that changing a lower element of the pyramid will require changes to those above it. For instance, if I am building a website and my ideation changes the core flow of my application, I may have to revisit my business model to ensure my ways of communicating with my customer, or the tools I need to build my design, aren’t being modified as well.

Let’s say we are building a food ordering application.

If I change the core flow I ideated for my application such that my users can now order pick up rather than just delivery to their door, that significantly changes my relationships with the driver partners(Business Model), my assumptions and principles now that the user is actively navigating to a store (design philosophy), and finally the look/front end of the application itself (the design).

These steps do not live in isolation and depending on your needs will have to be mixed and matched to the situation required (especially in teams). Additionally you will need to revisit your previous findings often. Don’t dwell on sunk cost as being agile and admitting to your mistakes will save you or your team the time and heartache of doing slow modification to poor solutions.

Now that we have that out of the way, let’s take a deep dive into our first step: How to validate your concept.

Step One — Validate

The validation (discovery) phase is the foundation of your design process. Much like the concrete under a building, the assumptions created at this early stage drive the rest of the product design lifecycle. Your Research, Synthesis, and Problem Statement exist in the validation phase.

Research

Before you create your problem statement it is imperative at this early stage to understand the underlying need you are trying to solve for. We want to avoid focusing on any technology at this phase as we are purely interested in observing the current problem our prospective users are engaged in. Let’s use a real world example of a problem digital artists could be experiencing. We start with a hypothesis:

Digital artists want to share their artwork, but don’t have any good management tools to do it.

Our initial reaction is to think about designing a sharing platform and all the features it could hold, but we need to focus on understanding the user-centered issue we are trying to solve. Some immediate preliminary research questions we may ask ourselves:

Is there a sub demographic of artists we are targeting?
What problems are these artists experiencing currently?
How much does my target demographic value the problem I am trying to solve?
What is the variability in how my audience interacts with the existing problem space?

We are first identifying the underlying profile of our artists. Always try to narrow your initial target down to the smallest possible group you can qualitatively or quantitatively analyze. You will suffer from less variability as well as focus your target needs. Choose research methods best aligned with the goals you are trying to achieve (for more specifics on different research methods, click here)

An important distinction here is to focus on not what the problem being experienced is, but why they are experiencing it. For instance, let’s say we are questioning a participant about the sharing habits of their artwork and he says:

“It is hard for me to share content with other local artists”

It is easy to take this at face value (what) and assume that the user wants to have a sharable content system for local artists in the area. This is ineffective as it is validating only our own perception of what the design should eventually be.

If I take that response as why, I iterate to new questions/theories outside my perspective:

Does the user feel social pressure sharing their work?
Is it because the other artists have a different style so it’s hard for him to get local artists with the same interests?
What does he believe is subjectively “local” for distance?
What does “sharing” mean in this case (Critiquing? Support groups?)

My follow up questions should be attempting to dig into the deeper context of the reason the action of “sharing” is being performed with these theories in mind, being careful to avoid leading the participant (“so you are telling me you think…”) and instead leaving it open to their explanation (“Can you tell me what you meant by ‘sharing’ just now?”)

Synthesis

Once you have collected your data you can synthesize user pain points into a sharable document. For an in depth analysis on breaking down your findings in steps I recommend Marion Baylé’s excellent article “Synthesis: How to make sense of your design research”.

Synthesis can be broken down into three distinct steps:

Get it out. Write as many thoughts or ideas out as you can, during or in reviews directly after your research sessions.
Organize Chaos. Start to build relationships around the context of your work.
Interpret. Define and synthesize down to the most important insights of your research.

For product designers, I recommend note taking in an excel document or google doc to get out your thoughts. Use comments to highlight insights you find interesting. Make distinctions in what was observed and what was asked that drives cross compatible themes you see.

To organize your relationships, using affinity diagrams to help categorize your work into insights. Tools like Miro are great for this and if you want to persist your affinity diagram beyond one meeting full of sticky notes.

Finally, using journey maps or personas to make the final important insights stand out can be your guiding source of truth for future research and problem statements. Using journey maps in our case would allow us to provide direct mapping of the artists’ themes to each step of their sharing process, where overlap occurs, and disconnects in the current experience open for product disruption.

I recommend this template for figma which provides an interactive standard for stakeholders and your team to explore your most impactful findings.

Problem Statement

A problem statement is a short but highly detailed statement that synthesizes exactly the problem(s) your user is experiencing. It comes after the initial research phase as you are moving from defining user pain points to synthesizing them into a single statement that can be explored and ideated upon in the future steps. Always perform this after research and synthesis so as to not bias your research questions to point to the conclusion you expect.

An example of a really well written problem statement from Nielsen Norman Group:

Alieda, a multitasking, tech-savvy mother of 2 needs to quickly and confidently compare options without leaving her comfort zone in order to spend more time doing the things that really matter

Writing an appropriate problem statement is critical as it will inform both the direction of the ideation process as well as the value proposition that makes you stand out from competitors.

Case Study: How Poor Validation Can Ruin A Product

To understand why building the right research, synthesis, and problem statement are so important, we can look at a short case study on the failed music product known as the Pono Player.

Video by Linus Tech Tips

Prior to 2012 the famous musician Neil Young had the idea of a portable music player that would allow for the same lossless audio quality as studio recorded music. A kickstarter was created that raised over $6.2 million dollars sold on the technology of a lossless audio quality device, the Pono Player. The product solution was completely engrained with Neil Young’s idea in terms of its marketing and technology for years of development. There was one problem: the evaluation of how much the target audience wanted the lossless format was highly overvalued. The result was that many users did not feel the product was worth the value it was so heavily pushed on.

This product is deeply attached to flawed research and a flawed problem statement.

If we ask a prospective user:

“Do you value lossless media?”

the vast majority will be inclined to immediately say yes, who wouldn’t like studio quality music in their devices?

However, if we focus on the “why”, and we ask users:

“Are there any struggles you currently face in your music listening experience?”

they are more inclined to mention headphones or the UI/ergonomics of the device itself over lossless compression. In this case structuring the research around what users fail to mention (lossless compression) can be just as much an indicator of what a target demographic values in their product. In this case, no matter how much time, effort, or design went into making the product selling point as sexy as possible, the Pono Player was doomed to fail.

To conclude, the validation section is the core building block of every touch point in the process beyond it. Your validation should be the base building block of your product and needs to qualitatively & quantitatively identify a real user centric problem. Build a science of sustainable research methods and “tools” that you can rely upon to master this first step of your product creation journey.

For more “practical design for products” or for feedback and questions, feel free to contact or follow me.