The product designer is a difficult role to fill and a difficult one to define. A product designer’s skill set requires the intersection of many different disciplines. Here are the roles product designers need to fill.

Visual Designer/UI Designer

This is the role most commonly associated with product design, as the user interface decides how the users interact with the product. The challenge becomes placing information and interactive elements in a way that makes sense.

Interaction Designer

Once a product’s UI makes sense, it’s time to look at the design of behaviors. How is the user interacting with the product? How does the product respond to a user’s input? The interaction designer decides the behavior of information in reaction to user inputs.

Experience Designer

The user experience is defined by how the user feels about his or her total interactions with the product. Change makes people uncomfortable. A designer’s job is to help people experience change as comfortably as possible. The goal is to create an experience that is both understandable and meaningful.

Product Owner or Product Manager

The best way we’ve found to describe this role is a quote from Etsy creative director Randy J. Hunt’s book “Product Design for the Web“, which describes a job ad seeking a product manager “who would not only ensure the trains ran on time, but also would help build the track,” an analogy that illustrates the scope of this essential role. Our product managers or product owners balance

Content Strategist

The words that explain a product, feature, button, error message, or welcome email can be just as important as the interface and interaction design that show it. Content Strategy creates the tone, influences the user experience, and can do as much good (or damage) for a product as a logical (or illogical) flow.

Researcher

Testing is critical for understanding how users think, and being able to analyze results and anticipate their needs is a key component of product design. Product designers must do market research and user research to understand their audience before they build. They also go further and test and track analytics to see how those hypotheses work out after they’ve launched a product.

Marketer

No matter how brilliant a product is, no one will use it if they don’t know about it and have no way of finding out about it. A good marketer knows how to get a product into people’s hands.

And a little bit of code…

Developers will always introduce constraints, so product designers must learn how to speak their language and work with them early and often. The more code product designers understand, the better they can anticipate how design will be implemented and where it may fail, as the development team is ultimately responsible for bringing the product to life.

The product designer is there to help identify, investigate, and validate the problem – and ultimately craft, design, test, and ship the solution. Present a product designer with a solution, and he’ll tell you what’s wrong with it. Classically, these have all been individual roles. All of them still are. However, they’re also all necessary components of an individual product designer.

We work in a highly reactive space. Good design is invisible, yet always adapting to ever-evolving platforms. Data informs everything we do, user research checks our assumptions, and we measure our success through business and engagement metrics, but most of all, product design is about people. Good product design takes user needs and solves them to best suit the business goals of a company.

This post originally appeared on the Yeti blog.

Fortunately, there’s an easy safeguard, and it’s one that top-dog technology companies use before building many of their most successful products: the design sprint. Facebook, for instance, recently used the design sprint method to examine assumptions behind its foray into chatbots. Uber, for its part, wanted to figure out why families weren’t biting on its service. Its new Uber Friends & Family feature is a direct result of a fruitful design sprint.

The design sprint was pioneered by GV’s Jake Knapp, who recently published his methods in “Sprint,” a book about how nearly any design challenge can be solved in a week through rapid prototyping and user testing. So when Yeti first read Knapp’s blog posts detailing his design sprint methodology, we couldn’t wait to try it: The sprint felt like a natural, obvious evolution of our design processes. Design sprints aren’t just a Silicon Valley fad, though: They’re the latest innovation in problem-solving that modern companies are using to move from frustration to solution, catalyzing the creation of products that customers truly want.

What Happens Before a Sprint?

At Yeti, the groundwork for a design sprint is simple but incredibly important: It begins with defining the client’s vision. Simon Sinek’s speech “Start With Why” offers an excellent approach to this. The client’s “why” focuses everything that follows it: Why are we building this? Why should we believe in the idea? Why will users want it?

Establishing the client’s “why” prior to the design sprint is just a starting point, though. We dive deeper, ensuring our clients have clear business goals, understand the competition, and pick a metric by which to measure success. Most important, we strive to understand who their customers will be. This is crucial to the fifth day of the sprint, during which we test a working prototype with real users.

If you feel overwhelmed, don’t worry: We host workshop sessions to prepare each client for the sprint. In the workshop, we help them define their vision and procure the knowledge needed to make the sprint effective. We also offer in-person consultation and preparatory surveys for clients who might already know the problem, their target customer, and their measurement for success. Once we’ve obtained all the necessary information, then we ask clients to pack their bags — or we pack ours — and join us for five fun-filled days of product workshops, prototyping, and testing.

The 5 Stages of the Design Sprint

We conduct design sprints across five days and in five stages:

1. Understand
The first day is all about getting everyone on the same page and choosing a target challenge for the sprint. This is when the product owner rallies everyone around his or her idea. We encourage domain experts to speak on more technical topics associated with the challenge or product, and we check out competitors’ solutions. We also coordinate with product testers for day five. Choosing a target is a big commitment, so we leave it to the product owner to define what assumptions he or she wants to validate and test.

2. Diverge
On day two, we consider solutions to the challenge from every direction. This phase requires participation from the whole team, as we want a host of different perspectives to ensure no solution is left undiscovered. It can be a little intimidating for non-designers, but we’re collaborative and supportive, encouraging even the most hesitant product owners to put their ideas to paper. You never know who’s going to come up with the winning solution, so we don’t discard even the craziest ideas at this stage.

3. Converge
On the third day, we decide which ideas are feasible and make sense to prototype on day four. By this stage, we often have multiple promising solutions in front of us, so it can be tough to narrow the field to the ideas which will be most valuable to prototype. Because we can’t test everything, we let the product owner decide which ideas we should move forward to prototype and test.

4. Prototype
Day four is always exciting: It’s the day we turn ideas into reality (or even virtual reality, such as Tiny Eye, Yeti’s take on VR seek-and- find). Once we’ve defined the challenge and chosen the most promising route through which to solve it, our team gets to work on building a prototype. While this isn’t a particularly busy day for the product owner, it’s an intensive day for our designers and developers. The whole Yeti team pitches in to build out the product owner’s vision, and we begin readying our testing space.

5. Test
The final day comes down to the users. We conduct five tests in one-hour blocks over the course of the day, during which a facilitator interviews users while the rest of the team observes remotely. We listen intently, scribbling furiously to capture the day’s insights and share them with the client.

Design sprints can end a few different ways, all of which are helpful: If the test is a smashing success, then we’ve validated the idea, and the heavier lifting can begin. If some elements of the prototype work but others don’t, then we know which ideas are valid and which need more testing. If an idea was a total bust among users, then we return to the drawing board with valuable knowledge: The design sprint is one of the most efficient ways to discover that we’re focusing on the wrong problem or that we’ve identified the wrong market for the idea.

Whatever the outcome of a design sprint, we pride ourselves on helping the client take a giant leap toward their next great product. This five-day methodology saves companies from months of product design headaches and — best of all — untold thousands in product development. Regardless of what product your company is building, let Yeti accelerate the process through a design sprint.

This post originally appeared on the Yeti blog.