Ask HN: How to get developers and UI designers to work well together
For those working in tech/software development teams - do you also find that there's a lot of tension between developers and designers?
They need to work together but it always seems like a challenge. From the tools they prefer (Figma vs. Github) to the pace/workflow to the language and communication.
What are the biggest pain points you've seen?
What are some great tips for bridging the gaps during a typical workflow?
Thanks!
140 comments
[ 2.5 ms ] story [ 202 ms ] threadWhat planet do they live on? I've never been in a corporate culture that was like this, usually the opposite. Upper management is completely detached from reality, relies solely on metrics, and cuts costs as much as possible, which leads to dramatic churn. Engineers are too overwhelmed with doing the jobs of 3 people to do proper collaboration. That's the norm in Corporate America.
He must work with very different designers than the ones I have, whose eyes just glaze over when you try to explain even in relative layman's terms how it works under the hood and why there are particular challenges implementing exactly what's been asked for. I can't readily imagine the quality of my code ever being improved by the opinion of someone who's never written a line of code in their life. Just as it would make little sense for me to have opinions on how to achieve particular shading effects or to improve the readability of a font or the optimum amount of negative space needed for all possible device dimensions in order to provide a rewarding experience for various categories of end-users.
I’ve been remote for about 5 years.
What are specific examples of friction you’re encountering ?
If you see FAANG+ they might be referring to companies like Data Dog or SalesForce or Crowdstrike, companies that pay extremely well but maybe not as much as Meta or Netflix.
At least that's how I read it.
We realised we were using the word design for like 4 different things and often two or more interpretations were valid
acknowledge that. decide that you serve the customer.
sometimes the customer cares to be dazzled others time they just want the thing to work.
often details of design and technical implementations don’t matter so it’s easy to bikeshed.
as trite as it is the solution is honest and open communication
Now, if you want to talk about systems/devops teams or IT departments..
All have been exclusively iOS users, with no feel for how the two platforms differ, and I have had to take it up on my self to translate and adjust the designs given to me so that they follow norms and practices on Android.
It appears to me that they also do not differentiate between screens and modals and just pick at random which flow will be which. I am not faulting them for that, as Apple has gone pretty wild with modals lately too, but still, at least some consistency would be nice.
- "Just do the same as iOS" when asking about Android
- Hardcoded assumptions about layout size (less an issue now since iOS is more fragmented than before)
- Not handing edge cases, especially long string lengths
- Way overusing opacity (or blur before apple gave tools for it) which tanked performance for an absolutely minimal visual flourish
- Terrible tap targets
See if you can get your designers/developers to install Google's Accessibility Scanner[0]. It brings tap targets and accessibility to the front of their minds when working.
[0] https://play.google.com/store/apps/details?id=com.google.and...
Generally, the further a design strays from native UI elements the more difficult it's going to be to implement in a way that covers edge cases well and is accessibility-friendly. Sure I can bodge something that looks like the mockup but it's not going to feel half as nice to use in practice because it required me to write a lot more bespoke widget code, and there are considerations that went into the stock widgets that the designer probably isn't taking into account.
In these situations a little bit of leeway to bend designs to be closer to the OS baseline help quite a lot (e.g. do you really need that custom typeface which isn't built for use in UIs? Probably not), and so I greatly value designers who have the skill to build around what's already there instead of trying to replace it outright. That kind of design work isn't as sexy but it's far more practical.
- get to know each other
- get a better understanding of each other's work: what is important in the design and what is not, why is the design like it is, what is difficult to implement, how much effort certain tasks are, etc.
Another trick is to ask engineers for design input, e.g. in sketching sessions or design reviews.
As an engineer, I think Figma is a great tool. I can see exactly how the UI should look like, including all the details like colors, fonts and margins.
* no global text search
* no way to anchor comments to elements (so if content is moved, comment context is lost)
* no way to quickly compare versions of designs
* no way to "subscribe" to an element so you get notifications when it is changed
There are definitely some advantages to Figma. It's mostly better than sharing MS paint drawings. But it has a long way to go for it to become a good tool for developer/design interaction. Again, IME.
Having cycled through different design tools, it is my experience that Figma is the best (or least bad, depending on how you see it) tool out there. They have been slowly, but steadily, adding features that have a legitimate value add for designers and engineers both. I read this as a signal that they understand the pains of both parties and they are cooking up features that will eventually solve these pains.
No one else is doing this. Sketch has been a total disappointment in this regard. I was a Sketch user for years until I switched to Figma. Sketch is an example in contrast - they release features that are either late to the party, or don’t have significant value add.
tl;dr I believe patience will pay off. I think design tools are on the right trajectory.
[1]: https://flycode.com
- designers who want things to be "pixel perfect" while devs may cut corners to ship it quickly
- devs who unilaterally alter the design without discussing it with the designer, because they think it's better
- designers who design overly elaborate, customized UI solutions when simple, existing ones do the trick, and then are frustrated when devs push back
- designers with little technical understanding of things like react designing things that seem simple to them, but are complicated to implement, and then are frustrated when devs push back
- designers who feel like they have the final say over UI, while devs view it as more of a suggestion
I don't think I've really solved these super well in larger companies, but where I've observed it not be an issue is when people are closely connected to the product being built, and understand it (even better if they are users), and are working together directly (without product managers as a go between). Not to be like a Marxist, but I think it might actually be caused by alienation from one's labor. Designers design a thing in a vacuum, not fully understanding it, hand it off to devs. Devs code it, not really participating in the creative process. When they are an integrated team solving a problem they understand, collaboratively, it works better.
Have those two teams work together.
Also, foster a culture of continuous self-improvement. I’ve now seen a bunch of “it’s good enough to ship, go for it” and now whatever work arounds and bandaids are permanent. Don’t be so fast, don’t try to iterate so quickly, and focus on quality over quick ROI.
Imagine if Boeing behaved like a SaaS operator. The first version of 737 would be glued together, and in turbulence the wings would snap off “oh, I guess we should use more glue in the next version - alright guys, iterate!”
Slow down, do a good job, and the product will come.
Boeing also cut corners on quality, hence the issues with the 737 MAX. It's obviously not a direct comparison, but skimping on certain things to get something to market faster is not a uniquely SaaS technique.
Although it could have quality problems; stories of 787 quality problems are concerning. But quality skimping was not the cause of the 2 fatal crashes
When it was time to fly there were slight differences and this caused the pilots to react in the wrong way for the new model's behaviour.
While I understand the reasons you mention, I do not clearly follow the distinction between cutting on costs and cutting on quality. It seems like two sides of the same coin.
[1]: There is very low heat cap on middle tank to catch fire inside and be exploded and then there is an air compressor right below it. The security practice is to fill it with nitrogen if it's empty.
That quote is from an interview I did years ago when Cap Watkins left Etsy to become Buzzfeed's VP of Design. It has stuck with me ever since.
He's speaking about designers, specifically. But I think it's important for all parties to understand as much of the process as possible. The better the understanding, the tighter the feedback loop.
The interview for anyone interested.
https://solomon.io/portfolio/cap-watkins/
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.
Sorry for blogspam but I sketched a model of the two approaches. https://bitbytebit.substack.com/p/waterfall-design?sd=pf
"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.
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.
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.
> "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.
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).
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.
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.
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."
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.
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.
Designers don't understand the hardship of developers at first, they think they can do whatever they want to you. You gota teach them. Threaten to leave on a conflict. Make them understand those roller coasters are hard on you. Teach them easy rules like: a dev gota finish what he started, some things are virtually impossible to do (spaghetto code is real), you can't get pressured to deliver every day, etc.
If you are thinking about work outside working hours for a long period of time, people are probably hard on you. On average a designer don't think much about work outside of work pretty sure about that. They drink, they fool around town and they get laid. As a developer you deserve that as well.
Once that's understood, from my experience you should have fun together.
Depending on the size of company you're in there is a specialized role that bridges the gap. At Google it's called a UX engineer, other companies call the roll Design Technologist (DT).
DTs have a technical understanding of what's possible but work in UX and typically produce prototypes to assess technical feasibility of solutions. You can use these prototypes for stakeholder reviews, usability testing and they really derisk the build process.
We had a really bad time of changing things in production multiple times which would take forever before we started prototyping and practicing iterative design and design thinking.
In short, I can talk the business talks while designing and finish off coding the designs. So, here are what I think.
The war between Designers and Developers will never end, and it is OK. The designers will blame the developers that they are supposed to be smart enough to code the design. At the same time, the developers will scorn that the designers have no clue how things work. The situation aggravates in bigger companies and environments where separate teams by function, not by products or features/modules.
There was a documentary about Aston Martin making the One 77[1]. The engineers, designers, and everyone work together. There are no separate teams that come together later to fit in the final car. A few friends and I used to refer to this analogy when explaining how to get designers and developers to work together -- think of the product/feature/module and then bring the team together from the start.
There should be one person in the team who can walk between the designer and developer world, even if s/he can only either design or write code. S/he should have that empathy to understand both sides of the stories. Once you have that person and the team begin to learn to dance around, the intricacies of interaction between the two different minds will be the time when things get smoother. There will still be friction, but it should become way more manageable.
1. https://www.imdb.com/title/tt2289553/
Here is a helpful guide on the role:
https://www.designbetter.co/design-engineering-handbook
This should be a blog post or even one of those mini pay-what-you-like eBooks sold on Gumroad. Let me try a quick and short starter for you.
It is easier to teach designs to developers than vice-versa. "Design" is not what most people think -- artistic. To me, design is more about knowing the key aspects of arranging objects based on symmetry, sequences, and patterns. Once you understand these nuances of spacing objects to form a cohesive and meaningful flow of information, tackle the idea of how typography works. If you grasp these two essential items well, then others will keep flowing on their own, or you will be exploring automatically.
Now, since you can dabble in the front-end, play around and apply your understanding of "design" and experiment. Learn the basics and do not start from "frameworks" such as Bootstrap, which most impatient developers start with. It is indeed OK to be using the likes of Bootstrap but know that someone else wrote that, and you too can write one.
Once you are comfortable with the two worlds, it is then up to you to go deeper and specialize in being the Product UX Engineer or stay a generalist and work/lead other aspiring designers and developers.
I have a friend far better than me in both design and development. He is an engineer with an additional degree in design from one of India's prestigious design institute. When we discuss things, we tend to complete one another, and can dovetail fast enough while I never fail to be amazed by his insights every time we talk. Unlike me who have moved much further to the dark-side of the Business world, he remained a deep specialist in that beautiful realm.
1. https://brajeshwar.com/2011/desingineer-the-mythical-person-...
Just wanted to call this out as ABSOLUTELY SPOT-ON!
One additional concept I'd throw at developers is that design is not about making pretty pictures alone. Sure that's a part of it - nobody wants to use something that looks like ass - but in addition to that obvious requirement, you have to convey meaning without using words and do so with patterns, layout, and flow that people are already used to.
For anyone wondering "WTF is he on about here?" check out the study of "iconography". Think of the old school Windows system tray network icon. Two screens with a "link" thingy between them that blinks. Notice how that conveys the idea of computers communicating - aka, a network? That's a fundamental, critical element of UX design.
Now couple that with the need for layout, aesthetics, Gestalt theory (humans like visual symmetry), simplification of the interface for a very wide variety of audiences (elderly, Gen Z/millenials, boomers, everything in between), multiple device types, color theory (in some cultures, for example, colors have different meaning than they do in the West. In China, I've read, you wear white to funerals, not black; what other variances in color meaning may exist worldwide?), various linguistic idiosyncracies in various cultures, etc.
Once you put all that stuff together in your head, it becomes much clearer that UX design is a hell of a lot more than pretty pictures. It's a research discipline, and a field worthy of respect in its own right.
If the software is hella capable but a pain in the ass to use, it's worthless. Why do you think Windows is so much more popular than Linux?
Either way, this was a very informative post. I'll be googling these terms as soon as I'm at my desk. Thank you.
Another important aspect to look at sometime would by typography. In traditional print medium we always used to hear that serif fonts (the ones with the itty bitty hooks on the ends of letters - e.g. Times New Roman) were useful because it helped the eye move along the line. But on computing devices, used to be that the best practice was sans serif fonts (e.g. Helvetica, Arial) because of something to do with the way the fonts get rendered on a screen. That was long before the availability of 4k monitors though, but supposedly it reduces eyestrain and helps with clarity.
I never looked too much into that, and just went with what all the design specialists out there recommended (again, I'm a crap designer). But from this little example we can see that even the shape of the letters themselves plays a role in communicating a variety of things.
Imagine all caps, serif-font, white background, dark blue lettering:
Comes across as authoritarian, right?Now imagine the same in sans-serif, black on white, and maybe "for office" laid out beneath the name on the next line, spaced and sized so that the width of each line is identical:
Comes across as more formal and respectful but less fear inducing, doesn't it? (HN doesn't let me design here so you'll have to use your imagination of course! ;-)Anyway, this is just a simplified example of how typography not only conveys the words themselves, but an emotional sense along with those words. There's subtext within subtext possible here, and this entire field is dedicated to communicating more than data, and doing so at a very high rate of efficiency - including the things that don't get communicated well through words.
Until everyone gets that message, it can't work.
The best way I've found to get designers and developers to produce 1+1=3 outcomes is to show developers the design system (styleguide) and show designers a development process (functionality > fixes > finesse) that works.
Inertia slows team progress when designers hand off fully-finessed, high-fidelity screens that would take considerable time to implement.
Instead, ask your design team to start with functional lo-fi designs so engineers can have a basic UX/UI to dev against. The audience for the lo-fi is mainly internal, think pre-release/private alpha.
Some of the early development work is around feasibility, which doesn't require all the finesse designers value.
After you have functional lo-fi's, the design team can ship mid-fi screens that have fonts, colors, etc. Hold off on gradients, shadows, and micro-interactions. Lottie animations can come later.
At this point, you can start user-testing features and validating each hypothesis. It's much easier to iterate development on mid-fi's vs. hi-fi's. Especially when you need to make changes. Making changes at the mid-fi stage de-risks your startup.
Now you've done design and development in tandem and you don't need long design cycles that take forever to implement and de-motivate developers.
Nothing will motivate developers to implement your polished hi-fi screens more than having a validated product.
Hope this helps! @erikkjell
The typical workflow is that someone creates a work item to track some improvement or new feature. There, the idea is explored before any design or code work is done so that everyone involved understands what the goal is.
Then our designer will go and create some mockups and in figma (and link the figma in the work item). We'll then have discussions about the design, one nice thing is that the figma comments appear in the activity panel of the work item in kitemaker. So even if designer asks a question in figma, the rest of the team can see that in kitemaker (since programmers rarely live inside figma).
Once we've addressed as much as we can at the pure design stage, we'll start implementing the feature in code in a branch (that's linked to the work item). If anything comes up in development that we didn't foresee, we'll discuss it in kitemaker/figma/slack (if it's slack, we make sure to mention the work item so that it's picked up by the integration and shows up in the kitemaker activity feed).
As soon as something is even remotely "working", we create a w.i.p PR which spins up a test environment in Cohesive[1] (no affiliation, just a customer) and link to it in the work item. This lets the designer play around with the feature as it's developed and start giving feedback or adjusting the designs as early as possible.
The key is really just communication as early as possible and throughout the entire process. To make this more tool agnostic:
1) Make sure everyone understands what problem they are trying to solve for the user.
2) Get designers to share the designs as early as possible so that engineers (and others) can provide feedback.
3) Have a way for engineers to share the w.i.p in a test environment as early as possible so that designers can adjust designs or give feedback to developers.
4) Have a way to keep references to all the discussions in one place and visible to the entire team.
[0] https://kitemaker.co/
[1] https://www.cohesive.so/
If a designer exports their design in something like figma, sketch, or xd, where the developer can access the css values for the colors, then why would it matter how it looks on the developer's machine?
I'd guess that far greater than 99% of the people using (most) products do not have perfectly color calibrated monitors. If it doesn't look good on the developer's "kinda close" monitors, that seems like a decent indication that the design needs to be updated to allow for "rougher tolerances" so to speak.
I think I would disagree. And I'd disagree on the grounds that a large swath of users mostly use a tablet or smart phone. These devices do tend to have wide color gamut and pretty good color accuracy. A lot of mid-tier and gaming laptops and monitors purely focus FPS and these are the devices coders are often coding on (obviously there are exceptions, especially anyone using an Apple device, but other OEMs too like ASUS who has been putting out 100% DCI-P3, Pantone-validated OLED panels on even mid-range laptops).
Calibration, part II, is important too. Having calibrated monitors for friends that were lower-end, they remark on how big the difference is for them, meaning calibration is still valuable even if the monitor itself wasn't of good quality.
A monitor is an important part of IO and aside from aspect ratio and resolution, developers don't tend to care about the other specs of the monitors. A good calibrated monitor would be like using the same code formatter--everyone is on the same page at least about a specific category potential issues. By eliminating color as a factor, you can now focus on having different arguments.