
How to create a product requirements document + free template
A product requirements document (PRD) is a list of design guidelines and functions that project managers write to ensure key features make it into the release.
Skip to main content
Design basics
All your design work, in one place.

Someone spent months perfecting a UI nobody wanted. Someone else shipped a feature users never asked for. Neither team thought they were building the wrong thing—they just never stopped to check
That tension between what’s possible and what’s actually needed is where product design lives.
Product design is the practice of shaping how a product works, feels, and fits into people’s lives, from the earliest concept to the final shipped experience. It sits at the intersection of user needs and business goals. A product that users love but that can’t sustain a business won’t survive, and a product that hits revenue targets but frustrates its users won’t last either.
If you’re wondering how to design a product that actually works in the real world, it starts here.
Read on to learn:
Most design disciplines own a piece of the product. Product design owns the whole thing—what it does, how it works, and whether it actually matters to the people using it. That means connecting user research, interaction design, and business strategy into decisions the whole team can build from.
“Product design is about the relationship that the designed product has with the user, but also addresses its competitive context,” says Nikolas Klein, Product Designer at Figma. “That includes user experience design, product strategy, and go-to-market planning.”
According to Nikolas, product designers do more than focus on UX design. They also need to assess whether a proposed solution is feasible from a business perspective.
Questions like how much design and development cost, how to optimize budgets, and how the product aligns with business goals are all crucial. Collaboration with cross-functional teams like product managers, researchers, and marketing ensures that the product not only delights users but also supports business objectives.
Get product design right, and it shows up everywhere—in how quickly users figure things out, in which features make the roadmap, and in whether the product survives long enough to matter. Get it wrong and no amount of polish fixes it.
“Product design helps drive product strategy and larger business goals,” says Nikolas. Product designers help define which goals matter from both user and business perspectives. “This gives you more leverage in creating a better user experience and a better product,” he adds.
Good product design also helps drive a company's success, positively impacting the bottom line. “You could say the impact of an effective product designer is a good product and a good business,” Nikolas says.

“There’s often confusion between product design and UX design,” says Nikolas. “Many companies use the titles interchangeably—product designer vs. UX designer—adding to the confusion.”
Product design
UX design
UI design
Ask a product designer what they did last week, and the answer might surprise you. Yes, they designed things, but they also ran research sessions, facilitated workshops, pushed back on roadmap decisions, and worked closely with engineers to catch issues early.
Consider a common scenario. A team is debating whether to add a feature that would satisfy a vocal group of users but complicate the experience for everyone else. A product designer’s job isn’t just to mock up both options. It’s to surface the tradeoff clearly, tie it back to research, and help the team make a decision they can stand behind.
Every discipline has guiding beliefs that help teams make decisions when things get complicated. In product design, these principles aren’t rigid rules. They help you think clearly when designing a product and making tradeoffs.
User-centered design is a stance, not a process. It means building around how people actually think and work, including their goals, mental models, and the constraints they navigate daily, not how you assume they do. That requires staying close to users continuously, because needs evolve, contexts shift, and assumptions that seemed solid at launch quietly stop holding.
The harder skill is learning to hear past what people ask for. Users describe solutions, not problems, because that’s how we naturally talk about the friction we’re living inside. Those requests are symptoms. The designer’s job is to follow them back to the root need and understand what is actually broken, and for whom, before deciding what to build.
Product design gets mistaken for visual work more than any other discipline. But a product can be visually stunning and still completely fail. Apple Maps at launch had a beautiful interface and sent people to non-existent locations. Nobody cared how it looked.
This doesn't mean aesthetics are useless. Good looks build trust and affect how accessible something feels. But you have to get the interactions right first. Pretty design on top of broken interactions is just a more attractive problem.
Consistency in product design means users can carry what they learn from one part of the product to another. When patterns stay predictable, and language stays clear, users can focus on what they’re trying to do instead of figuring out how things work. Cognitive load drops, and trust builds.
Scale is where consistency gets harder. en Multiple teams shipping at once, different platforms, different codebases. The same problems get solved in different ways unless there’s something holding it together. That’s what design systems are for—shared components, shared patterns, and shared decisions so nobody reinvents the button.
Consistency and coherence aren’t the same thing. A product can be internally consistent with the same patterns, same language throughout, but it might still feel like it was built by five different teams who never talked to each other. Coherence is harder to pin down. Do the pieces feel connected? Do features reflect the same underlying values? It's the difference between a product that works and one that feels like it was meant to exist.
Good product outcomes don’t happen in isolation. They come from designers, engineers, PMs, and researchers who work together, share context, and challenge assumptions. That kind of collaboration doesn’t happen automatically. It has to be built into how a team works, which in practice means bringing engineers into user conversations early and involving PMs in exploration, not just final reviews.
No product design survives first contact with real users. No matter how much research you do, something will break, confuse people, or need to change. The question isn’t if that happens. It will. What matters is how quickly you learn and respond.
Iteration means shipping to learn, not shipping and moving on. It requires strong feedback loops, like tracking behavior, running follow-up research, and reviewing support tickets. It also takes resilience. Letting go of a design you liked because it didn’t work is part of the process.

It’s worth saying upfront: the product design process is rarely linear. Teams loop back, steps overlap, and a late-breaking insight from user testing can send you back to the drawing board on something you thought was settled.
While different companies may have unique tweaks to a product design workflow, the essentials often remain the same. At Figma, product designers collaborate with teams through five critical steps. Consider this product design process to help guide your team’s progress:
Leadership and product teams often don’t agree on what the goal actually is, even when they think they do. One team hears “grow retention” and thinks about reducing churn. Another hears the same words and thinks about engagement features. Starting with well-defined SMART goals gives everyone the same definition of success before work begins.
Product designers conduct strategic research or support researchers throughout the process. This phase focuses on gathering information that challenges what you think you already know. This phase might involve assessing the industry landscape with a SWOT analysis, building a customer journey map, or conducting user interviews
Some of the most valuable outputs are those that challenge assumptions the team has been designing around. Strong research also clearly connects to next steps: findings shouldn’t sit in a slide deck that gets read once.
They should live somewhere the team actually looks, synthesized into a shared artifact so insights stay present during analysis rather than fading into institutional memory.
Working closely with cross-functional partners, product designers help distill research findings into decisions. From there, designers sketch out approaches to the user pain points the research surfaced. One useful tool at this stage is to create a persona to represent the key user segments.
A strong analysis phase ends with three things: what the core problem actually is, which user needs matter most, and how often they come up, and which assumptions survived the research, and which ones didn't.
This is also where things get most interesting because analysis is where assumptions are tested, not protected. The goal is not to defend hypotheses but to refine them in response to what the data reveals.
The product team proposes a strategy to achieve business goals. This process may include a detailed action plan for the first six months and longer-term goals. The planning stage can help align teams with company goals and customer needs from start to finish, increasing the chances of success.
The timeline is the least interesting part of product strategy. The real decisions are about which problems actually matter, which users to prioritize, and which features to build or cut. Teams that get this wrong build the right thing for the wrong people, or the wrong thing beautifully.
This is the point where product designers work closely with product managers and stakeholders to turn research and analysis into a plan that the organization can execute. The goal is alignment, with engineering, design, and leadership genuinely behind the same direction, not just signing off on it.
Launch is when you find out if the design actually holds. Not in a bad way, necessarily, but engineers hit edge cases the spec didn’t cover, implementations drift from intent, and someone always has a question at the worst possible moment. Staying close throughout the build is the actual job.
Review what’s shipping against what was designed. Make the calls that didn’t make it into the spec. Dev Mode helps engineers get specs and measurements without having to chase anyone down—which means fewer interruptions and fewer surprises at launch.
Every process has challenges, and product design is no exception. Here are the top five product design challenges you might face and how to overcome them to keep your team on track.
Nobody tells you upfront that half of product design is negotiating. Users want one thing, the business needs another, and the roadmap has room for neither. Compromises are coming, and the question is whether you make them deliberately or get surprised by them later.
Solution: Prioritize the most critical user needs using tools like user flow mapping, but expect to do this work in the room rather than ahead of time. Stakeholders with competing priorities are unlikely to shift their views based on pre-read documents.
The most effective approach is to make tradeoffs explicit in a shared conversation, what you gain by prioritizing one direction and what you give up in return. A strong decision-making framework helps the group evaluate those tradeoffs against agreed criteria instead of defaulting to the loudest voice.
Making your product accessible to everyone, including users with disabilities, is a critical challenge within the product development cycle. It may require additional design considerations—like color schemes to help with color vision deficiency or screen reader support (a feature FigJam added)—but it’s an investment that reflects your commitment to inclusivity.
Solution: Follow established accessible and inclusive design guidelines, but the timing matters. Building accessibility from the start means making decisions at the component level, like color contrast, focus states, semantic structure, and touch target sizes, as part of the initial design rather than a post-launch audit.
Adding it at the end often leads to costly rework because the underlying structure may need to change, not just the visuals. Involving users with disabilities early ensures their needs shape the design instead of being treated as exceptions later.
Poor communication can lead to misunderstandings and delays, and even impact team morale. Improve the quality of your product by making sure efficient team communication is part of your product design process. For example, telecom company BT used FigJam to centralize communication and design systems, which improved business continuity and design consistency.
Solution: The most common breakdown between designers, engineers, and PMs is not a lack of meetings but a lack of shared context. Designers make decisions based on research that engineers never saw, engineers flag constraints designers weren’t aware of, and PMs prioritize work the team doesn’t fully understand. Regular syncs, open communication channels, and shared documentation like FigJam meeting templates help keep alignment. The goal isn’t more communication, but a stronger shared understanding.
The technology available (or unavailable) to your team can impact the design process. Hardware limitations, software incompatibilities, or storage issues can slow down progress and affect output quality.
Gojek, an Indonesian startup with nearly 200 million users, chose Figma to help eliminate the technological restraints of other platforms that had left designers frustrated. Using Figma, Gojek’s designers could work in parallel on the same design files, helping them meet tight launch deadlines.
Solution: Prioritize the technological tools and features that are most important to your team. Work closely with your IT department to ensure your team has the resources needed to meet deadlines and deliver high-quality work. Get engineers involved in design conversations early—not to approve designs, but to flag constraints that would be expensive to work around.
Product designers combine craft skills like interaction and visual design with systems thinking, research, and cross-functional collaboration. Tool fluency (especially Figma) is expected, but just as important is turning research into decisions and communicating design rationale clearly.
It varies widely by scope and uncertainty, from a few weeks for a small feature to several months for new or complex areas. What matters more than speed is whether the team is testing assumptions early and making informed, iterative decisions.
They work closely throughout the process, not just at handoff, involving engineers in problem-solving, design reviews, and edge cases. Shared files and ongoing collaboration help surface constraints early and reduce surprises during build.
In the US, mid-level product designers typically earn about $100K–$150K base salary, with higher total compensation at larger tech companies due to equity. Senior roles can earn significantly more, while ranges are generally lower outside major tech hubs.
Understanding what is product design is one thing—putting it into practice is another. The principles and process outlined here don’t happen in a vacuum; they require tools that help teams think together, stay aligned, and move from idea to execution without losing what they learned along the way.
Here’s how to get started:
Help your team create their best work, from brainstorming to diagramming and planning.

A product requirements document (PRD) is a list of design guidelines and functions that project managers write to ensure key features make it into the release.

UX design is the creation of digital products around user needs and expectations. Learn key principles, skills, and how to use Figma for UX design.