How to give product design requirements (and get what you want)
While I am not a Product Manager, I’ve worked with many over the past 9 years as a Product Designer. I’d like to share some of the best practices on how to better leverage your designer’s expertise by providing effective design requirements.
What does a product designer do?
If you just started working with a product designer, there’s one thing you need to know — Your designer is your partner on the journey of transforming an abstract idea into a real working product that people would love to use.
What can a product designer do for you?
Before you ask for anything, it might be a good idea to know what a designer can offer. It’s probably more than you think.
An experienced designer can…
- Level up the user experience beyond your imagination
- Accelerate the speed of the product development cycle with rapid prototyping
- Bring opportunities that you may not have thought of
- Get the buy-ins and funding you need by producing tangible visuals artifacts that allow you to pitch your vision to the stakeholders
Why is giving good design requirements important?
Does this sound familiar?
Product Manager: “I need design.”
Designer: “Sure…What do you need?”
When your designers are able to understand clearly what it is that you need, that’s when they can do their magic (job).
Good design requirements ensure that you get what you need on target, on time, and on budget.
What to ask for at different stages
In the product development life cycle, the team’s objectives would be quite different at each stage. Thus, what you need at each stage should be different. The deliverables your designer produces should be generated for a very specific purpose — getting the team to the next product development milestone. Not too little, not too much.
See below for ideas of what to ask for at each stage of the product development cycle:
Keep in mind that every designer has a different workflow, so please take this as a suggestion only. Talk to your designers to understand their unique processes and what their strategies are.
Common design deliverables
1. Concept Designs
Concept designs are generated for very specific purposes such as getting buy-ins from your stakeholders or consensus from your team.
For example, let’s say your product strategy is to bring true integration to your product. You drafted a vision:
The goal is to achieve true integration around data, workflow, user experience, capabilities and people, to provide a more holistic solution for our clients.
Sounds fantastic! But what does that REALLY mean?
It turns out, very often, people have very different interpretations of what that means in their heads. Without a clear understanding of what you are trying to do, you’ll not likely get the support you need to move forward.
This is where your designer comes to the rescue! Ask your designer to mock up a few different design concepts to help you kick off high-level discussions among the team, customers, and stakeholders. These designs may not be feasible at this stage because it’s only at the concept level. In fact, it shouldn’t be feasible, or to be more precise, feasibility is not what we should be spending time on at the moment. The purpose of the design at this stage is to get buy-in, build consensus, and set the right direction.
2. Wireframes
A wireframe is a mockup without the visual design elements.
The goal here is to figure out the user flow, logic, content, functionalities, and scenarios. By removing the visual design from the discussion, the team can focus on nailing down the content and flows that serve as the structure of the application. The idea here is to go through as many iterations as quickly as possible to arrive at the final solution. The deliverables should include just enough information your development team needs for user story writing and effort estimation.
3. High-fidelity mockup
Now that things are relatively stable, it’s a good time to polish the UI details such as the width of the text blocks, micro-interactions, and responsive behaviors (how UI elements behave in different screen sizes). This is the time to be pushing pixels, experimenting with different shades of grey, and playing with different typography combinations. The deliverables would be high-fidelity designs and design documentation that includes specifications tailored to front-end development.
4. Prototypes
A prototype is a design that is interactive.
Nothing is more realistic than a live, working product. But that can be quite costly to build. Luckily, your designer can quickly build low-cost prototypes which mimic the real thing. This is a brilliant way to bring the team to the same understanding of how the product works and spot any missing gaps.
What designers need from you
Your designers need some context to start the work. This information is critical in helping them make design decisions such as defining the user flows or choosing between a dropdown and a checkbox.
As long as this information is communicated to your designer, it doesn’t really matter how it’s delivered. You can write it down on paper, create a ticket in Jira, or have a chat over a coffee break (the last one tends to work the best for me).
Here’s an example of design requirements:
Let’s dive into each component:
- User statement: Start with a simple statement such as “As a user, I should be able to do X, so that I can accomplish Y.” By framing the prompt from the perspective of the users, it helps us stay focused on solving a real user problem instead of just spitting out features.
- Problem: What is the problem we are solving for? Why does it matter to the business and users? How is this problem being solved before this product/feature existed? Help your designer better understand the problem space by showing any screenshots, files, or sketches to support your story.
- Requirements: What are the must-haves and why? Why are they non-negotiable?
- Possible Solution: Do you have an idea of what the solution could look like? Can you share a rough sketch? I find this exercise to be particularly useful because looking at how my PM tries to solve the problem, it shed light on the problem lying behind the solution. It is also a great way to induce a constructive discussion.
- Scope/Constraints: How big is the problem/solution? What are the constraints around time, tech, or legal obligations? Setting the scope upfront helps your designer avert time wasted on exploring solutions that are just not feasible under the current time frame or limitation on resources.
Best practices
Do this:
- Be the expert on the problem
You want to know the WHO, WHAT, WHEN, WHERE, and WHY of the problem you are trying to solve. This should come from talking to the users, business, customers, and other stakeholders. What are their needs? Where do their goals overlap or conflict with each other? Show data, documents, testimonials, or artifacts that can help your designers understand the problem at a deeper level. You’d get designs that exceed your expectation if you spend the time telling the story well. - Define the scope
Designers have an infinite drawing canvas. If you don’t set some boundaries, most likely they can come up with a million ideas, but very likely, 90% of them are not feasible under the current situation or it takes too much time and effort to build. Setting the scope upfront before your designer starts the work can prevent the designer from going down the wrong path, which can save everyone a lot of time. Share any key dates or technical constraints. For example, you ask your designer to define the user experience for searching the inventory. Before your designers go off to exploring solutions that would require technologies such as ChatGPT, auto suggestion, and more, you can save their time by limiting the solutions to just keyword search because that’s what’s feasible given the development team have only one week to work on this. Explain to your team that other solutions are great, but we are making a conscious tradeoff on the user experience to prioritize delivering value to customers quickly at this stage. - Share your challenges
Let’s say your designer tells you that it will take X days to provide the design you asked for. If it doesn’t sound good, express your concerns and ask for alternative options. Sometimes getting the designer to see things from your perspective can help them help you. You don’t need to have everything figured out on your own. - Communicate with visuals
Design is a quite abstract and subjective topic, which makes it hard to articulate with words. Very often when we discuss designs, people have very different interpretations of terms such as “simple”, “big”, “loud”, or “exciting”. Therefore, showing some sketches or screenshots of examples can help you get your ideas across more effectively. - Keep it concise
“Nobody likes writing bloated, ultra-detailed product requirements documents. Turns out nobody likes using them, either.” — Jira. Designers are not necessarily looking for detailed requirements. They are just looking for something to hold on to ensure both parties share the same understanding of what’s expected. If one or two sentences do the job, keep it that way.
Don’t do this:
- Be careful not to prescribe the design solution
While it’s tempting to tell your designer “Just add a button here”, you may be putting your product at risk. Unlike designers who dedicate 100% of their time to thinking through the holistic user experience, user flow, design system, and page layout; as a Product Manager, you simply don’t have that luxury of time to do that. Therefore, it’s possible that your solution might not fit well with the user experience from a holistic view. Prescribing design solutions can jeopardize the opportunity to Wow your customers. Let your designer follow the proper design process and bring the solutions to the table. Your designer may also help you cut down the cost by simplifying the solution. Perhaps you don’t need that button at all, instead, a tweak in the visual hierarchy on the page can solve the problem. As a rule of thumb, hold the problem tightly, but leave the solutions to the professionals. That’s what they are here for — to solve design problems, making sure the user experience is simple, seamless, and intuitive. - Resist the thought of “I am the user”
Yes, you may be one of the users, but you are not the only user, (hopefully!) If you expect more than one person to use your product, then, you’d need to consider how different types of these users would interact with your product. People think and behave differently (you’d be surprised!). Let the user-centered design process, and not our own opinion lead the way. To be fair, your designers are not the users either, but they are trained to use various scientific means such as usability testing, tree testing, surveys, and user interviews to make sure the designs meet the needs of the different user groups. - You are writing to designers, not developers
Sometimes a set of product requirements don’t always work for your designer and developers. For example, this requirement statement is probably not relevant for a design task: “On clicking “forgot password”, the system will check for authentication on the ID key and match them to the EDP database…”. Instead, something like this is what a designer is looking for to start the design work: “As a user who forgets his/her password, I should be able to reset my password from the login screen.” - You don’t have to wait until you have everything figured out
It’s totally ok to reach out to your designer for help even if you don’t have all the answers ready. The market will not wait for you. Figuring out the design requires both the PM and the designer to go back and forth, just like dancing. As long as you are dancing at the same pace and moving in the same direction, it doesn’t matter how you get there. It’s ok to fill in the missing pieces during the dance. Just don’t sit on the bench because you don’t have everything ready! - Don’t get caught up by the formality
How the requirements are delivered to the designer is much less important than the quality itself. We should care more about whether the problem and solution have been well thought through. Is it based on facts and reasoning? Can you back it up when it is challenged? The way to ensure the quality of the requirements is to make sure you invest time in understanding the user and business needs, market, technical constraints, and resources. As long as your designer understands what you are trying to accomplish, it doesn’t matter what templates or tools you use. It’s even better if you can communicate through telepathy!
Key takeaways
“When the team and product owner share the same mindset, you don’t need ultra-detailed requirements.” — Jira
If you can only take one thing with you, I’d say go with whatever works best for you and your designer. It’s as simple as asking your designers, “What is your design process? What do you need from me to do your job?” Make sure it’s a two-way collaboration and not a strict top-down relationship. If you continue to reflect and adjust the way you work together, I have full confidence that you will build something amazing and have fun along the way!
References: https://www.atlassian.com/agile/product-management/requirements
