UI/UX has to be treated as an iterative process. Collaboration between multiple parties (eng/dev/design/pm/etc) is almost orthogonal to the root problem I've seen: "design" gets treated as "this is it" and the moment you start being 2-3 pixels off, or a shade of red isn't what was in figma/ps/etc, "you're deviating".

"These were already signed off/approved/whatever".

"But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile."

"Stop deviating - we already interviewed customers!"

"But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc"

"Stop deviating".

I've had a couple of good experiences working with a couple design folks in the last year, but EVEN in those cases, "design" was sort of treated like "one and done".

Once the product is in the hands of real users, feedback - implicit and explicit - comes in, and there should be processes in place to make rapid adjustments - possibly multiple iterations - to deal with the feedback.

That's one of the biggest hurdles I've seen, even when there's decent collaboration and respect.

I've found that there is a mindset issue with designers that needs to be addressed if they are working closely with software development teams.

If you come from an agency background then you are conditioned to only show perfect/close-to-perfect stuff to your clients because you don't want to leave poor first impressions. It's why there are multiple reviews and approvals before you show anything to the client. You want repeat business and a "failed" design would be treated as a strike against you.

When working closely with teams there is no need for that and you can bring in low fidelity artifacts like sketches for feedback without fear of the whole design group being judged. This is a big change to how designers generally work when they're employed by agencies. Unlike agencies, this is a safer environment (all things being equal) where imperfection might be rewarded by engineers, but unfortunately, the agency mindset is retained.

There definitely are ways to improve how we work together by playing some games, doing activities like assumption busting, diverge-converge design sketches etc. but the organization has to prioritize this mindset shift. The chance of it happening organically is limited.

There are issues the other way as well: developers are often conditioned to expect perfect designs for fear of "re-work". I find good software design, solid testing practices and EMs with an eye to ways of working (not just technical stuff) can help address that.

My previous company almost exclusively hired designers from agency backgrounds - it was a huge problem.

Part of this isn't designers, but "stakeholders" and managers and such wanting to put their stamp on things. They often do this through design, I suppose because you can show anyone a screenshot in a powerpoint and they can appreciate it, but you can't show everyone a program logic flow chart and have them appreciate it.

One way to push back, if you use anything like story points for estimation and scoping, is to point low-design and high-design options separately, for any elements where design choices may have a major effect on that. "This is a 5-point feature with a basic button with the correct brand colors and a spinner for busy state—but a 13-point feature with what's presented in the designs, including a bouncing hover animation and the button morphing into the company logo as its busy-state et c."

Part of the problem is the cost of design on the development process, not just making initial mockups, is often ignored or not correctly accounted for. If you make it explicit, lots of times it turns out a simpler version (which is going to be better for users anyway, 90% of the time—but being good for the users isn't the reason for a lot of UI design, see: constant user-hostile but flashy redesigns across the industry) is in fact acceptable if it means you can fit another feature or two in a given sprint. "We can come back and do the fancier styling & behavior later when we have less feature development to do" but then, as with most things that get deferred, you never will, which is for the best.

> "These were already signed off/approved/whatever".

> "But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile."

> "Stop deviating - we already interviewed customers!"

> "But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc"

> "Stop deviating".

I've worked with a lot of designers in my career. It has never gone the way your examples went.

A conversation between colleagues with context provided is enough to allow us to work through differences. Explaining that the animation they're suggesting is bespoke, requiring more work across different browsers to ensure behavior and performance is what we want is enough to move us to something more simple, for example.

What I do run into often is developers without an eye for detail, who don't understand things like white space, padding, colors, and assume they're unimportant who then are told they're not and get upset that they need to go back and fix CSS and layout.

I'm not saying every interaction has gone this way, but it's happened more than a couple times (over the course of... 15+ years).

The last interaction I had like this was a few years ago - someone had done lots of mockups in... figma (but it wasn't figma - I can't remember the tool, but it was relatively well-known). I had 100+ "screens" with example text/input/labels on every screen.

These were done by an agency, then handed off, and... there were multiple people who had worked on it. Screens/slides 1-40 had some font label in 12px, slides 41-95 were at 13px, and the rest were at 14px.

I pointed this out, and kept getting told "stop deviating - we've already approved these - we've spent weeks going over all of these - stop thinking you know better than an award-winning design agency!"

Making screen 41 and 40 look the same was "deviating" because someone reviewing "41" against the mockup was 'wrong'. So... I made each screen with same fonts as the mockups.

Two weeks later, in some review, someone 'complained' because jumping through all the screens, the font sizes kept changing. I pointed out this was exactly the same behaviour as jumping through all the mockups, sequentially. It was obvious, but ... it was only getting reviewed holistically weeks after everything was 'approved'.

Probably the worse 'designer-led' experience I've had, but a couple others have come close (just not as stretched out). But it reinforced that the 'design' portion really needs to be involved and iterative (and... they need to be open to feedback just as much as I have to be).

Agree. In my experience, the design team tends to work closely with the client and the dev team is either silent or left out. Silent, because offering opinions on how something affects the backend may be completely moot when the next iteration is developed; or left out, because the dev team can't communicate "you can't do that" to the client in a way that doesn't sound annoying.

The project manager's primary job is to keep the client happy, so they tend to overpromise. Which is weird, because (especially in Web design) they client was more or less happy with the limited set of functionality that Facebook gives them. They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit.

> They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit.

I, for one, am extremely skeptical that the intense focus on making sure every little thing on every page or app is "on brand", and the significant costs that preference incurs, has positive ROI. Nonetheless, every company seems to have become obsessed with it.

>Nonetheless, every company seems to have become obsessed with it.

You don't have to know much to have an opinion about it, therefore everybody does, and it's the most important thing in the world to them.

"Normalizing the database? Wha? I'm not technical, guys, I'm more customer focused. We really need that sidebar to scroll with the page, let's work on that."

I agree with this. I always tell people that the designs aren’t carved in stone or written in blood, and if something looks or feels wrong to bring it up. There’s no point in the process where the design can’t be improved, and anybody can be the one who finds an opportunity for improvement. And there’s also no shame in changing a design to make it easier to code. Ultimately no design is ever finished, and anything can be adapted or improved.

> The root cause I have found is getting designs done in isolation and then treating the Figma/Sketch/whatever file as a hard business requirement, instead of treating the user experience as a collaborative exercise that is a tradeoff between usability and feasibility.

I've actually seen this happen when the development stages of either part are wildly out of sync. The design folk finish a mockup of the UI and figure out how the components should look... while the developers are struggling to get the back end up and working properly, talking with the front end etc. And so the developers can't feasibly put the design demands in place, without ignoring other important needs.

So while one part of the team is talking about how the dropdown components and multi-select components should look, the other is struggling to get all of the API endpoints up, the DB migrations done, the server/container configuration working properly, put package updates in place and fix various bugs and issues, as well as write tests.

Some companies do distribute those responsibilities amongst multiple teams, but I've definitely seen cases where there are designers whose responsibilities are way unbalanced with those of developers, who are putting out fires a lot of the time and doing other stuff, creating friction and complicating communication and collaboration between them.

In those cases, making the dev team 2-3x larger may help (or may make everything worse, it depends), yet it doesn't seem to occur to anyone working on the project.

I feel like the biggest problem is the lack of "tooling" (not necessarily in the strict software sense) for doing iterative designs.

In software development, we've already developed approaches on how we can iteratively deliver features (sometimes half-baked or "unfinished", but still delivering "value"), and we've developed an understanding that this is how we get to a final solution (and an understanding that we might need to cut scope, and any one of those iterations might be the final result for the time being).

Even with all the rage tools like Figma get, it still requires each designer to come up with an approach that will effectively communicate intermediate usable design steps on their own, and it feels like that's still missing with most designers.

Perhaps the agency background that a sibling comment mentions is what's part of the problem, but just like with "design systems", I am sure even better "tools" are going to come soon as this problem is better articulated and taken upon by designers working embedded into software teams.