Hacker News Reader

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).