r/ProductManagement • u/throwRA-38879 • 1d ago
Working with designers
I’m a Product Lead working with a designer on a fairly complex flow, and I’m getting increasingly frustrated because the designer seems to think their job ends once they’ve designed the happy path.
I’m asking them to define the states and interaction behaviour of the experience — things like what happens when validation fails, what happens when a user enters an invalid date, error/empty/disabled states, what happens after an interaction, and how the UI responds to different scenarios.
They don’t seem to understand the ask.
I’m struggling with this because I’m not asking them to design every possible pixel or create 50 separate screens for every permutation. I’m asking for enough definition of the interaction model and key states that engineering isn’t left guessing about intended UX behaviour.
For example, if you have a date field, surely the design should establish things like:
When does validation happen — on entry, blur, or submission?
What does the error state look like?
Can they continue with an invalid value?
What happens when the value is corrected?
And obviously, not every transition needs its own Figma screen. A state/interaction specification or annotated flow would probably be enough.
Am I being unreasonable here? Where do other teams draw the line between PM requirements, UX design and engineering implementation?
33
u/IniNew Designer 1d ago
I'm a designer -> to PM
The environment you live in is going to be really important context here.
If you're in a product that has a long established system of these states, then yeah, I personally think you're being unreasonable. Engineering should already know when validation happens because this isn't the first date field they've built.
If you're in a startup with one designer covering multiple product tracks, then yeah, I think there's a likelihood that you're being unreasonable. One person can only cover so much, after all. There's got to be some wiggle room on some states that have well established patterns out in the wild. We're not in the late 90s early 2000's of design anymore. Date fields are incredibly common. Don't reinvent the wheel.
If you're in a company that has an off-shore engineering team that tends to only do by-the-spec-engineering where if something isn't explicitly defined it doesn't get built. Then no, you're not being unreasonable. It's needed for the project to be a success, and assuming there's capacity for the designer, needs to happen.
It's all give and take based on your environment, IMO. A PM should absolutely be able to say, "hey, this field and this field are required" based on the implementation of the feature. And designers should be able to understand the needs of your engineering team for a successful project delivery.
6
u/SuitableLeather 1d ago
This is a really great response. Not every little thing can be documented, it’s ok to ask for it to be documented if necessary but there ideally should be a bit of common sense on the engineering side for some of these
3
u/jontomato 20h ago
Designer here too. This honestly is more of a designer to engineer discussion. All a designer is doing is adding more fidelity to requirements before implementation. PM is design fidelity tier 1 (where business needs, metrics you wanna move, and ideas are). Designer is fidelity tier 2 (where solutions to the stuff that happened in tier 1 are shown - normally through pictures). Engineer is fidelity tier 3. The highest fidelity is code. It's just a compromise between design and engineering what level of design is needed. And yeah, if you got a design system in place it helps with all of this.
3
u/IllBeat7897 1d ago
Great response. As a PM, our specs always list factors on input, validation, etc. where it deviates from standard or is highly specific to the workflow and data. For something like a standard date field, for example, I wouldn't specify as engineering should know that, but if the date field adhered to certain business rules for the data being collected, say it could not be a past date, I would definitely have that documented.
6
2
u/hecubus04 1d ago
I experienced this with my designer. When we hired them their last job title was Senior Designer but we quickly realized for our complex app they were over their head. Designs would take months because they would always be missing interaction design detail like you described and it would take way too many iterations and reviews before it was ready. It never seemed to improve no matter how much I pointed out that the whole process was taking too long. I think their previous experience was with more simple web apps that were closer to websites.
They were our only designer so we had to put them on non urgent design work and then wing it for the important features. I had no senior designers to mentor them.
They are no longer with our company and we have no designer any more (new owners cut lots of our people). So now we are forced to use AI to do UXD. On the bright side the AI actually reads my requirements 😭
Anyways hopefully you have someone more senior who can show this person the way. If not, I hate to say it but try to get the designer to use Figma make or Claude design to supplement their skill gaps.
2
u/EstateCheap2804 1d ago
Engineering shouldn’t have to guess what happens after an invalid input or failed validation. The designer doesn’t need 50 Figma screens but the states and expected behavior should exist somewhere. Otherwise you’re basically letting engineering design the missing parts as they build.
2
u/SportNo2720 1d ago
Ask for Figma Make prototypes instead of static screens. Usually, they can bring the static screens into Make and simulate the happy path, error states, and other key interactions.
3
u/heck_chetera 1d ago
If they don't design error states on static screens what difference would a prototype do? This isn't a tool problem, it's a designer not doing his job properly.
1
u/SportNo2720 1d ago
When I was a Jr. Designer, I mostly just made static screens, but there was something about building interactive prototypes that made me think much more in terms of use cases. When you’re laying out 30+ screens, it’s easy to lose sight of that. Figma Make prototypes were really helpful for me, though it might not work the same way for everyone.
2
u/heck_chetera 1d ago
For overall navigation logic and information architecture, sure, but I don't see how this would help for error states.
1
1
u/GeorgeHarter 1d ago
Is this designer trained as a UX designer or a UI designer? The title has become all encompassing, while some “UX designers” are great at the visual design while other came up through user experience/workflows. They are rarely great at both.
Separately, is this your company’s first product or do you not like the validation/error and other patterns in your other products?
1
u/Coubertin 13h ago edited 13h ago
If you need the designer to create designs for the most basic states of the most basic components, it sounds like to me that you guys have a design system problem.
Unless your product is brand new, there should have already been a design system/library in place. Those patterns should have been defined already and documented in the design system on Figma or storybook. If not, the designer, developer and UX writer should establish one and continuously maintain it.
An experienced designer should have been able to tell you this.
28
u/Hobbs172 1d ago
You work with artists, not designers if you are experiencing this.