Ask HN: How to get developers and UI designers to work well together

Thank you for that explanation.

As someone who has worked in both fields for almost equal amounts of time I can have some thoughts, not all true all the time but certainly some common things I've come across!

I think the one key point is that developers and designers don't always have the same target user in mind!

- developers are often only brought in when something needs to get built, at this point everyone has it in their heads that the thing they've designed is perfect and totally technically feasible, it hurts when a developer tells them it can't be done. If this happens even once where a developer said no when it could in fact be done - every developer is affected!

- designers are perfectionists but so are developers! they just care about different things.

- designers perceive developers as lazy, that is they view the idea of taking a design and making a nice neat set of reusable components and layouts as lazy. To a developer its fun and a challenge and requires a lot of work to do so. Its also seen by some designers as a challenge to their design skills - why would you want to reduce something so carefully thought through to something so simple?

- developers have a bad reputation with designers usually because of outdated ideas about the sorts of people who become developers but also because I'm fairly sure a lot of the communication between developers and designers happens when a developer has been interrupted and no one is in a chatty mood when they're out of the flow state and have to start all over again.

- they don't always share a common goal - a designers primary focus is the user (and sometimes their portfolio), a developers primary focus is the maintainability and how neat the code is of the system (and their portfolio!). A lot of clashes seem to happen when designers implement something new and different or when a developer simplifies things.

- a hard one but both need to be less precious over their work. Pixels aren't perfect, code doesn't need to be beautiful, learning to let go of control of a design or a codebase is a skill!

Some things that help

- teach designers to code

I worked with a designer who was adamant about things being pixel perfect until they learnt to code, you could track their proficiency as a developer through their designs. When they first learnt to code the designs were boxy and simplistic, as they progressed they became more and more advanced and creative but they never went back to that same abstract style they had before they learnt to code

- teach developers to design

Teach design principles, research techniques, introduce them to the users and the clients. Designers often have more of a connection with the users simply because they've studied them to understand the users problems, developers are rarely given the opportunity to do that.

- include developers early in the project

have a system in place so that at least one developer is on the project from the beginning, the cost of them spending a day or two a week just attending meetings and maybe not even saying anything to contribute pails in comparison to the cost of a build up of friction between design/development teams.

- include designers in the tech project

depending on how your company is setup do the same as above with designers, the more often these joint ventures happen the more each learns and the easier things become

- don't hire developers who look down on designers, and vice versa!

One bad apple can ruin an already fragile relationship, don't encourage it. Asking questions about how do you like to work with designers or researchers or developers in interviews will give you an idea of what they think of their colleagues. If someone is the best developer/designer in the world they are not worth having on your team if they make the atmosphere tense and uncomfortable for everyone.

- have an index of terms and processes

some people don't like to ask what does something mean especially if they think they should already know it. Document your deployment process, explain why it takes so long to deploy a small fix to production. Explain why you decided on that shade of blue, what meaning does it convey how does it relate to the other parts of the design. Why is it important that only some buttons have 2px border and others have none - if its just for aesthetics say so!

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.

If you don't treat design as a collaborative exercise, then I suppose it doesn't matter.

I've generally only worked with designers in a mobile app context. A few of the things I do as a dev which has improved my relationship with the design side (Although the designers I've worked with have changed over time and that definitely is a part of the better dynamic. The initial designers I worked with came from print media and had no mobile app experience):

- Work in a Storybook-like sandbox for components. This is the single best change and a lot of other stuff comes from this in terms of standardization and common language. By working on components in isolation, its a lot easier to both flesh out edge cases as well as argue that certain edge cases need to be handled ("theres no guarantee about how this component will be used so we need to make sure we have some answer for X"). It also _massively_ speeds up iteration speed

- Put in generators/utilities that do things like generate your buttons/labels/colors. This lets you standardize on a smaller palette and also give you a choke-point to flag "illegal" values (e.g. trying to set a label font size to 8pt, or a button tap target to 36x36).

- Learn some UI/UX! Reading the material design docs gave me a much better understanding of grid layout and color design systems.

- Coach the designers on the platform expectations especially around tap targets, font sizes, and navigation patterns. You should usually stick to your guns on this stuff.

- Understand that your job as a dev is to _try your best_ to implement the design as presented. This means you should at least make an attempt to bring their creation to reality, after you adjust it to fit within the confines as described above.