Product designers can some time be tough to work with. How do you work with them?
Do you bring them the problem and/or user stories, debate solutions and ask them to present you some wireframes?
Or do you usually arrive with a solution in mind and ask them to wireframe it?
Or other methods?
Would love to hear your thoughts on this one. Cheers
Hello,
Product Design Manager here.
The best way to work with product designers is exactly the same as youâd work with any other skilled professional - bring everyone together around a problem, then get out of their way to let them maximize their skills. The best Product Managers enable their colleagues to be better practitioners.
Here are some examples:
Discovery - bring your designer into discussions early - discussing OKRs? Your PD (and EM!) should be an active part of that conversation. Building a vision? A designers input and perspective is invaluable here. Setting the strategy? Get your PD to run ideation workshops to help set out what an high level journey or experience could look like, and work backward together to a strategy.
Ask your product designer to bring UX research into those conversations. That insight combined with the data and analysis that the PM often discovers helps paint a perfect picture of customer problems to solve.
Delivery:
Build stories and epics together. DO NOT come with a list of features and ask the PD to wireframe it - youâre not making the best use of your designer by doing that. You want to enable the product designer to, ya know, design the experience collaboratively. Maybe itâs some high level happy path mapping? Or a experience blueprint?
Donât suffer from ârockstar PM syndromeâ (which sounds borderline what youâre talking about in your OP!) - you are not the expert on everything, including design and experience. The best PMâs are humble. The best PMs understand that to really be successful they need to enable and accelerate their colleagues potential and skills. View your PD (and EM!) as an equal to yourself in your team with a different perspective. You should be working so close together that you finish each otherâs sentences.
The common âbeefsâ I see between PM and PD is when the PM views the designer as a delivery monkey, who exists just to crank out wireframes, prototypes and visuals at the whim of the PM. This is not the role of a product designer. Enable your colleagues to have the impact they are capable of.
I hope this helps 
@JoelSchulman, PM here, over multiple platforms. Thank you for nailing it. I canât tell you how many times a designer caught something dumb in our initial designs. Ends up saving a lot of time in the dev lifecycle and makes for generally happier customers.
How do you balance working in Agile with design working in the way you describe? Iâve run into lots of issues trying to move quickly while working with PDs. I either feel blocked by them or feel nervous investing so much time into research before building anything, especially when priorities could change by the time the research is done.
I feel like creating a prototype quickly and seeing how it performs or getting feedback from users is going to provide more insight than extensive research done ahead of time.
Do you commit to design work or research as part of sprints, or should PDs exist âoutsideâ the sprint process? My team tries to represent design research and work as tickets and bring them into a sprint like we would engineering research and work, but this means design always has to be at least a sprint ahead of engineering, which feels way too slow when we need to move fast, like building a small but urgent new UI feature.
@Arnie, Thatâs an interesting question that Iâll try to unpick.
First thing to challenge is why do your priorities change often? Why do requests for âurgent UI changesâ come in? This kind of reactive, pivoting work is possibly the most destructive thing that can happen to a product team besides maybe a key member leaving suddenly. Iâve seen teams brought close to tears because Product Design Manager and Director level management kept changing their priorities, forcing through features that werenât prioritized and generally screwed up with the teams flow. Try to cut this out immediately with proper vision, planning/OKRs and commitment to strategy - youâll find it solves almost all your problems immediately.
The next thing for me is your reluctance to invest in research. A personal bugbear for me is that a lot of people equate agile with âgoing fastâ - this is wrong - building software is complex and takes time. No amount of management frameworks or whatever will change that. What agile/lean/etc does do is derisk software. You should be thinking of the amount of risk at play. If you get this feature wrong - how much revenue do you put at risk? How much is the cost of acquiring customers if it goes wrong? Iâm all for shipping MVP and getting stuff out quickly - but ultimately if what youâre building fails to provide value for customers then youâve built the wrong thing. No amount of pivoting will get back that time. Consider the priority of de-risking your product. Sure, sometimes that can be a prototype - but often a prototype gives feedback on the experience of the prototype only - not if the problem exists or if itâs really providing value. Using lean and agile properly enables you to build the right thing, sooner. This enables you to move faster in the long run. But building the wrong thing is always building the wrong thing!
What you say about being a sprint ahead is common, but slightly outdated. Look up âdual track agileâ - SVPG have a great article on the concept. We build a discovery track into our OKRs - both technical and Product/UX. One of our OKRs per quarter is to run discovery on a problem which includes the design and research work. That gives you more than enough time to properly derisk your product through research, testing and design iteration.
The other option is to run discovery in the last few weeks of the previous quarter, to be set up ready to go for the next. This means design can get a two week or so head start, plus the time for technical discovery. Which can often be a month total to run a proper process.
Hope that helps!!
Thanks @JoelSchulman, that was super helpful! Dual track agile feels like a much better mindset than trying to treat discovery the way we do now.
@ArnieSilvers, I can help with that one: phase your projects. Talk with the Product Designer and agree some baselines and quick wins. Divide your projects in phases. Phase one should be the most obvious and quickest stuff to solve the problem. Then you should define some goals and stuff to measure. Those measures will determine if you need phase 2 of the project and go into the wireframing and development of the rest of the experience.
@JoelSchulman, This is exactly what I was looking for. I sensed that many have the rockstar syndrome. I do not. I tend to believe every single word from the Product Design Manager when they build the experience or wireframes. But that also worries me sometimes. Iâll try to work with them and read some research data from them. Thank you so much for taking the time to write that elaborate response.
@AngelaBlue, No worries - glad it helped. Really designers are a friendly bunch that love to shoot for the stars with what they design. Itâs your job to figure out what the reality is and they in turn work together to build awesome things!
As a Product Design Manager, who used to be a Product Designer, Iâve been on both sides of the table. I bring in our Design Research Lead (PD) as early as possible so he can be as effective as possible. I typically do not arrive with a solution in mind - rather the problem and have a discussion around it. If I have a solution in mind, I check myself and call it out as a hypothesis for our discussion. You will ultimately create a much better product if you partner with - not dictate to the PD. This works if youâre working with a senior level designer. If not, the approach could be different.
Define the problem as clearly as possible. But it helps to have some tools such as the following already created. These help not only your designer but yourself as a Product Design Manager and the rest of the team.
Having a target persona with clear Jobs to be done written down.
Creating the constraints with the designer, leads to the best outcome faster.
Make some leading principles. For example âspeed over perfectionâ will help the designer understand the user wants to get to the end result quickly rather than spending time with lots of options etc.
Encouraging your designer to start with writing also helps. If your designer summarizes the above and shares some scenarios then a discussion and feedback is much more productive at this point rather than with a polished mock-up.
If you have a good designer, donât go with a solution in mind and expect them to simply execute. If you do that, youâre wasting them as a resource and the results will probably not be as great.
I usually like to come with a broad problem and then we can break down the problem together. Once we have more manageable and specific problems, I do the work to prioritize what to focus on first along with inputs from my team (UX and ENG).
Once weâve decided on the specific problem to focus on, weâll often do some conceptual brainstorming on how to solve the problem and come up with a direction together (often in the form of a text which explains how the experience should be)
From there, the designer does their magic and comes up with a visual representation. There will then be round(s) of feedback as it approaches the solution we will implement.
A new thing Iâm trying is to incorporate the engineering voice in the design process better. Itâs great to make sure the solution can be feasibly implemented.
This is the process I use more or less, refining it each quarter
How are product designers tough to work with?
Curious because I am dealing with one and Iâve had no problem at all.
@ChristieDook, Personally, product designers are tough to work with when they have less experience.
I used to be both a product designer and a developer so I have a good foundation on best practices and whatâs possible.
I always go over the problem weâre trying to solve with design and donât try to push one solution on them.
However, much to my dismay the senior designers I work with arenât so senior so I end up giving my reasons why certain UX would work better. The problem comes when they are too stubborn to take any advice and end up in a feedback loop with the design team thatâs hard to break out of. It ends up with them pushing their design through and having to redo it with best practices later.
Itâs all push and pull and sometimes thatâs hard to remember.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.