Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How to get developers and UI designers to work well together
116 points by zevir on July 19, 2022 | hide | past | favorite | 133 comments
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!



I think this is largely a personnel & hiring problem. Stop hiring people who can't work in teams. It takes more than just Developers to ship good software. Stop hiring designers who cannot design software.

> do you also find that there's a lot of tension between developers and designers?

To be honest, no, not really. Only ever at one job have I experienced a problem with developers and designers working together. One designer (out of two or three) was very ego-driven and was focused on producing a piece of art to hang on a wall, while one developer (contract, out of five) just flat out didn't respect anyone else (developers, designers, or PMs) and it was "his way or the highway". There are ways to work around this (mostly around setting clear guidelines for process and expectations), but ultimately the problem is with those people. Let them go.

Good designers are those who recognise that you don't ship PSDs (or Figma designs, as it is now) and are aware of the iterative approach to developing software. Good developers are those that actually respect the design process and set aside time for it.

If you structure your project/team/company where developers and designers are separated, and designs are "chucked over the wall" you will forever be running into problems. The best teams will be cross functional and have design's included in every step of the process.

Design Systems can be a huge help here - when everyone (designers and developers) have a common vocabulary of how a product looks and acts. Get this mature enough and you can just design your product with wireframes.


While yes non team players on the design side or dev side can be an issue, just as much it could be project / product managers.

I think the key to a well oiled machine is good direction from product, getting everyone bought in on the vision / roadmap (or at least understanding the priorities). From there working on the Information Architecture (I call it data design). Having the data design clearly defined alleviates many issues. It shows that there is clear definition and both sides can start working on their parts even though the final design blocks the final UI.


I have a fair bit of experience here as I work with many teams struggling with this.

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


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.


Don't just let your designers hand over the results. Make them pair on work with the engineers. This way, they will

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


IME Figma lacks crucial features that make it less useful than it could be:

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


Product designer here. Yes, I agree with you. I would also encourage a longer-term view.

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.


Is there anything that offers what you are looking for?


Zeplin allows you some of these things.


But Zeplin loads Figma files (and others)? I assumed zeplin was a different part of the pipeline.


As a mobile developer, the main pain point with collaborating with a designers over the years has been their complete lack of knowledge when it comes to norms on Android.

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.


I would take this further to say that as an engineer, my most frequent issue with designers is lack of technical understanding in general. As you've noted, platform norms are often overlooked, but so is what's feasible to implement on the platform in question.

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.


Are you in the US? I seem to be having the same problem, but in reverse - Android-isms in iOS; I am in central EU, designers/client are from Ireland.

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.


My last experience in mobile dev was that everyone wanted everything to look like Material UI everywhere, because that's what was trendy on the Web. And that even Android had, bizarrely, pretty poor support for Material compared with the Web, so it ended up being a huge pain on both mobile platforms. I guess it's like how you used to have to call out to JavaScript on Android to get a decent Google Maps address & location library because the Web versions were better than the native Android one, which made no damn sense but seems to be part of a pattern with Google of treating their own mobile OS as a second class citizen compared to the Web.


Yeah for mobile it was always:

- "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


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


You're lucky, some I've worked with seem oblivious to mobile platform conventions altogether. Is it that hard to sit down and spend some time reading the HIG?


I've worked as both, for many years now.

It obviously varies by individual and by team, but in general the solution is more communication, earlier in the process, and frequently throughout it.

The thing designers often don't understand is how their design needs to work within the larger system, which has many complex interactions, tradeoffs, and constraints. Changing one thing entails changing many other, non-obvious things, and did you think about that when you drew a picture of it working perfectly in Figma? No?

The thing developers often don't understand is that designers work without the benefit of certainty. They may get a set of requirements from a PM, but often they don't, or they don't get a very good one. Do all the user interviews you want, you're still just guessing about a hundred times a day. And there is no automated testing or static analysis. There isn't even syntax highlighting. You just make something you hope is right, then show it to people, and have them point out all your mistakes. Of course they get defensive and protective of their jobs.

So developers and designers need to be in communication with each other frequently, to spot problems early and fix them. And it needs to be so common and lightweight an interaction that it doesn't feel like a committee meeting, but like a collaboration between partners with the same goal.


I've been working 15+ years as a UX developer, with varying results. From my experience, the best way to get developers and designers to work well together is to have frequent short demos/reviews (ideally weekly). That has helped solve random problems like:

1. This user flow does not match backend reality, let me explain why.

2. How does this screen design handle XYZ usage?

3. I cannot export this asset from figma, please share.

4. Would you mind verifying that the fonts/colors/spacing look okay?

5. Are you sure about not reusing an existing icon from our library?

6. How should we handle error and loading states?

7. How important is this design feature? It'll take me a while to build it.

8. Did you expect this desktop layout to be full width or 1600px?

9. Can you give me an overview of what changed since the last design version?

10. This is how I implemented the design. Is that correct?


> How should we handle error and loading states?

This should be the title of every designer/developer interaction meeting.


LOL. True..


Thanks for these insights. I think this is a great approach. The question is, how to best facilitate these short/demo reviews without creating too many context-switches and interruptions for everyone. We're actually working on a platform that tries to solve this (https://livecycle.io/) by generating instant, collaborative PR preview environments. So the kinds of reviews you describe can happen async and in context. Do you think this approach would work to facilitate the reviews you outline here?


This. Your process also highlights that developers and designers working together is a process that is interlinked and takes time.

Another comment highlights that designers work often without the full picture. I'd add to this they are responsible for bringing solutions to the table as the catalyst to collaboration, exploring compromise and iteration. The best engineers bring solutions to the table too. The worst is when the developers and the designer are bullshitting each other on why things aren't possible with reason from their own domain that the others don't understand or can't reason about.


The big pain points have been...

People that feel strongly about the solution but don't have much evidence it's right for the user or business. I've seen that from both ux and engineers. Getting both groups more exposure to user feedback and customer feedback helps. Dogfooding also works great when applicable.

Focusing on details over the big picture. For ux I mean the emphasis on pixels over interaction design. For engineers I've seen it too. Exposure to user feedback helps. PMs help. A calm discussion of tradeoffs involving delivery dates help too, or budgeting post launch time to improve the feature helps smooth out the initial debates over scope. Doing rapid iterations with limited groups of users also helps.

Some people feel that they've had unfair compromises so many times that they're no longer willing to compromise at all. I've seen that from both ux and engineers.


I'm usually the guy called in to make peace between designers and developers. I have consulted with large enterprises, major IT providers, etc., and my job was to bridge the gap. I have also been one of the Creative Directors at Razorfish, but my job usually starts with presales and meddles with the product managers, designers, and developers.

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/


The role you described as a bridge between those two domains, how could I go about pursuing that as my career?


Over a decade ago, @cdixon tweeted, which has since been deleted, "Desingineer" - mythical person startups are looking for who can do UI, UX, and excellent front-and back-end coding.[1]

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


> "Design" is not what most people think -- artistic.

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?


Not to take away from your great post, but that jab at the end felt unnecessary and reductive. There are a million reasons why Windows is more popular than Linux, and while user experience is one of them in my opinion, I'd say it's not one of the most relevant.

Either way, this was a very informative post. I'll be googling these terms as soon as I'm at my desk. Thank you.


It wasn't intended as a jab at all, but I can see how it came across that way. No offense intended, and I do apologize for that. Still, the end-user desktop UX for MacOS and Windows is a major piece of why people use those over Linux as a desktop computing environment. (Nothing wrong with Linux itself mind you, more the ongoing fragmentation, but that's another topic entirely...)

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:

    =  S  M  I  T  H  =
         FOR OFFICE
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:

    =  S  m  i  t  h  =
        For Office
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.


I guess UX also explains why Windows is way more popular than MacOS, too. ;-)


It's called UX engineer, Design Technologist or Design engineer depending on the company.

Here is a helpful guide on the role:

https://www.designbetter.co/design-engineering-handbook


Lookup product management. They typically do this.


"It is critical for a designer to go all the way through the process. Even if they aren’t actually the ones shipping production code—that knowledge about how things work tightens the relationship between them and those they work with. Designers knowing how to code and talk to users cuts down on wasted communication. It creates a tighter connection with other teammates and ensures that design is part of the process from start to finish."

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/


I’ve found that most misunderstandings between UI/UX and front-end devs can be resolved by having the UI/UX people read a book on CSS. Once you start designing to Flexbox and Grid, instead of reinterpreting/porting designs using Flexbox/Grid, most of the problems disappear.

I can’t overstate how much easier life got once my teams started using CSS as a shared design language.

Designers get really excited when they see what Flex and Grid are capable of. It’s really empowering for them to design something that they know they can be built. Keeps developers honesttoo: No more “this is hard to do on the web, wontfix” if the designers know how to do it themselves.

If you’re a designer working in the web in 2022 and you don’t know the ins-and-outs of modern CSS layout technologies you’re at an impossible disadvantage.


You're missing the word "web" in there a lot of times.


I've been both, currently a developer. My 2 cents. Designers work in the "What we would love to build" space while developers work in the "What can we build" space. Those worlds are incompatible.

Paraphrased comments I've heard in the past month.

"Yes our small margin is always 8px but it didn't look good in this confirmation modal so I changed it, that's no big deal right?" (a designer that doesn't design based on the design system is a joke)

"Here is a link to the figma file ... no not that one, it's the 5th one from the left after you scroll way to the bottom" (I've never told a designer to start up a dev environment and figure out where the code is for whatever feature they are designing, why do I have to open figma and hunt around?)


Designers love to come up with contrived examples, that they know will never work with user provided input, but they want to get the design done.


If 'design' and 'development' are entirely separate it's pretty much impossible because the two sides have different goals. You have to align them. This entire process gets a lot easier when you have one team who understand that their job is to deliver value to the customer (or user) rather than "design pretty things" or "write clever code".

Until everyone gets that message, it can't work.


exactly this, what is good code if not well-designed. I don't buy the population idea of "different sides of the brain either". Anyone who works in software are generally particular, detailed people at the very least. Clarity is generally a good objective — for both designers and developers.


I've worked in the field for 20 years and I've struggled to find something that works consistently. My frank opinion is that design (particularly UI design) as an industry has a perfectionism problem - designers are encouraged to strive for the platonic ideal in their work and are unwilling to budge after their ideas encounter reality. Software engineers on the other hand are encouraged to ship and not make perfect the enemy of good, because the product of their work is often immediately delivered to customers and turned into value for the business. This puts design and engineering at odds with each other, with engineering often being able to play the trump card because they're self sufficient in developing the end product.

Exacerbating this issue is the fact that design teams often don't report under the same organizational departments as software engineers, and aren't incentivized the same way as software engineers, which produces a lot of organizational strife. Design organizations often consider their final output to be the mockups/wireframes that describe the product, which is thrown over the wall to engineering, at which point they step away from the process and from that point serve only to criticize the end result or ignore it entirely.

The above is my experience and subjective take on the issue, I'm sure others have experienced different. But the above strikes me as somewhat commonplace based on my own conversations with folks in the industry.


Very much similar to the problems we have in SRE/DevOps/Platform world.

This is why we put so much emphasis on trying to hire people willing to talk/collaborate.

It's by far the hardest part of the job for everybody and WFH has amplified these frictions as building trust is best done daily not in annual offsites.

I haven't seen any company do this well but I suspect one way to help is in better defining the definition of done. No local celebrations of done (I've shipped my design - blocked on dev) - but done is celebrated collectively with all parties who contributed (including dev/design/platform/even legal). Put another way, no celebrations of work done, only celebration of business value delivered.


I find a few sources of tension

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


At my company we have never had an issue between design and development. Our designers are on the same team as the developers, so we all talk to one another throughout the day.

The tech difference between using Github and Figma isn't a big deal, Figma for the most part put the right buttons in the right places so developers can glean all the right information from a piece of UI to build it (at least in my work building webapps).

I would say the biggest thing we do differently than other places is collaboration with design is happening before any lines of code are written. Design will ask us what UI framework we are planning on using, or if we are planning on just using regular CSS. From there designers will create designs based on the principles of that framework. From there we start building the project and import all the colors, spacing, and other variables from Figma. The actual development is the last step but by then we already know what we are building and have the building blocks in place to make building it straightforward.


I'm a developer and I've seldom or never had any problem with designers. It's cliche to say it's communication, but that's what it is. How? Nothing is ever just handed off. We talk about everything. Not only in meetings. We spend plenty of one on one time at each others desks. I don't condescend to them, I explain things from my end. They don't condescend to me, they explain things from their end. We're both working on the same thing, not different things. The way I look at it, you've either hired people who give respect to other people, or you haven't. If it's the latter, oops.


I come from a different industry before moving into this one, but there’s a chaotic and abysmal lack of teamwork between departments in this industry that I’ve seen this far.

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.


I agree with your overall point, but I think your example might be a bit off.

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.


The max issues weren’t corner cutting on quality, it was corner cutting on investment in a new design and type rating and available pilots.

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


If I remember correctly the problem was the new models were imitating (with software) the old ones to avoid having to be certified again.

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.


This is getting finnicky, but generally I would consider a quality issue to be something to do with the build (ie substandard materials, poor riveting, trash in the dead spaces in the walls - as has been alleged on the 787) as opposed to what happened, (in my view) which was cost cutting - as you point out, they basically tried to do a software emulation of the previous 737. The issue isn't flight worthiness - the 737 MAX can be a safe plane - but they cut costs by not wanting to do a recertification or retraining. I guess that is a quality and safety issue, but not what i'd normally consider quality?


Since I looked into 737's middle tank bug that was used in assassination attempt (Thai PM) in 2001. I couldn't believe how stupid its design is [1]. Professional design of airplane is quite overrated TBH.

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


I don't have to imagine https://www.justice.gov/opa/pr/boeing-charged-737-max-fraud-...


Align the teams on things they both value: system thinking.

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


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.


What are the friction points? I’m a UX designer (15 years experience). I love working with engineers on solving problems, QA’ing and releasing high quality products. Maybe your designers are more fresh and junior ??


IME the primary friction point is constantly having to ask designers to consider transitional and error states, and constantly having to ask for image files to be shared in a consistent size (including consistent padding).


Interesting. How big is your company? Are you in person or remote? I wonder if it depends on the setup and profile of the company...


I’m at a FAANG+, in a team working on B2B enterprise products (SAAS). Previously I was in consumer electronics and B2C, but even then there was a healthy relationship between design and eng.

I’ve been remote for about 5 years.

What are specific examples of friction you’re encountering ?


What is FAANG+ I know the acronym but not the plus? Is it some kind of formula one league within FAANG?


FAANG has evolved from the acronym about rising stocks into a term representing companies that pay high salaries in SWE circles.

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.


Thank you for that explanation.


It means that they don’t work at FAANG.


I’m No longer at a FANG but somewhere that has same pay/perks but I can WFH always!


I have a "systems" business analyst who works with designers. They are the first guard to prevent a design that looks right, but makes no sense in terms of entity or data modeling. If I think things are getting too complex from my weekly check-ins with the design team, then I will send a developer to sit in on the meetings.

What I do probably won't work for you, because team communication is incredibly political. You need political power to have your "guy/gal" sit in on another teams development/design process. Again I want to hammer home, the political nature of this. You need to cultivate good relationships first and foremost. The problem isn't tooling like Figma or Github, its relationships and trust between teams( assuming everyone is competent).


I have rarely butted heads with designers. Most of the time it's mutual respect for what the other does, and both sides have at least casual interest in the other side's profession, so collaboration usually goes well.

Now, if you want to talk about systems/devops teams or IT departments..


Have you read this article https://www.smashingmagazine.com/2022/07/resolving-conflicts... ?


"For example, a corporate culture that is collaborative and open can have teams that are hyper-focused on metrics and productivity that misconstrue the intent of the culture to meet productivity metrics."

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


"[D]esigners should have opinions on the applied technical solution"

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 didn't see it until now - thanks for sharing the link!


Agree with a lot of comments here about more/better communication.

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.


Personally in my dev career I've only ever really had friction with design teams when they did one or more of the following:

1. Changed designs offcycle without updating tickets.

2. Be oblivious/ambivalent to accessibility requirements of UI, or what standard user interactions with existing sites is like.

For 1, I don't even mind as long as the changes are small. There have been times that I've met with designers, we settle on a plan of action, I start working on it, and then they change the whole layout because of some sort of need from higher up. I wasted a few days working on a non-finalized design when I could have been working on something finalized. Solution was to make sure that the higher ups are in the initial design meeting so we don't get any surprises. Yes, their schedules are always packed and it means we have to push back meetings all the time, but it also generally means that we get 1 meeting to get everyone in agreement (even if it's agreement by force at the hands of the hippo)

For 2 there wasn't much I could do other than push back when they present a design that is inaccessible or a dark pattern. If it's an external application I always lean on "I'm trying to save us a ADD lawsuit", but it's always harder with internal tools. I get things like "We don't have any blind sales reps" or "no one at this company uses a screen reader" but I don't let up. Accessibility when done right doesn't just make an application usable to a group of people who would otherwise be excluded, but it also makes applications easier to use period. No I'm not going to rotate that text. No I'm not going to have the text be an svg unless it's a logo. No I'm not going to make the text that light on a light background. Designers generally don't like when they're told a design flat out can't be used but in my experience any application that is written without accessibility in mind, will be rewritten for accessibility.

There's always exceptions but this has been the bulk of my experience. Most designers I've worked with understand where I'm coming from which is a big help, I can only count on one hand the number of times the relationship has been outright adversarial.


I haven't really had this problem (I'm a developer) because I used to try to do some form of UX design way back in the day. And the more I did it, the more I realized I suck at it. So I can empathize with their needs and truly appreciate someone who can do it well.

My recommendation would be to have those with a problem do the other person's job for a week and "sorta" hold them accountable for the outcomes. Give them the mere threat of some minor wrist-slap should they fail to meet a seemingly reasonable objective that the other could do in a week, and then after the exercise explain that you never had any intention of actually delivering on that - in this case - just to make them have some skin in the game so they didn't dismiss the exercise.

After about a week of the shoe being on the other foot, I think the appreciation for the other discipline will become genuine, and then you can start working on having the right conversations about tooling, concerns, workflow, language, and so on. But developers have got to understand that UX design is so, so much more than "pretty pictures" and UX folks have gotta get it through their heads that engineering is FUCKING HARD, and we're way more than mere "code monkeys" over here.

Until that mutual respect and appreciation is established, none of the other stuff matters.


If you're familiar with Clayton Christensen, he has a theory called "jobs-to-be-done".

The basic premise is that you "hire" an object/person for the "job-to-be-done" which is usually the outcome you're after.

I like to use this thinking in problems like this.

Developers are not designers and vice versa. You don't want them doing each other's job in most cases.

You cannot give too much of a solution to these two specialties or it makes it near impossible to work together as there isn't enough slack / autonomy to do their actual job.

What they both can share is a common "vision" for the sought respective outcomes. With the stage set, it is usually worthwhile to have the developers consult the designers and vice versa throughout the process. The more each side educates each other, the more "correct" and "true to the design" the result is.

The one thing I have noticed in a big tech career is that people simply just don't communicate with each other. Majority of these problems can be solved if you put the two disciplines in the same room and give a challenging problem to solve with the common vision set. You'd be surprised at all the amazing ideas each party has when they can express them to each other.


As a frontend developer I've found the best designers have some development experience and likewise a good UI developer should have some basic understanding of UI design.

As a quick example at one place I was working a designer came up with this beautiful new site menu which I was asked to implement. Lots of animations. Items would slowly disappear depending on the space available. Things would resize and move around the menu necessary to look right. From a design perspective it worked great, but as a developer I knew it was going to be a nightmare. I knew even if I could build it as intended it would be overly complex, prone to bugs and difficult to maintain. A good design (and designer) is one that considers the limitations (and possibilities) of the technology and designs with those in mind.

Similarly I've seen great designers who understand the technological constraints well have their designs ruined by developers who implement them without care. For example, making sure things line up correctly or that padding and margins are correct and consistent are things that I see bad frontend developers miss a lot.

In my experience the best way to work is by sitting the developer and designer next to each other. It's less about tooling and more about communication. Ideally a designer should be asking questions about how easy something will be to implement as they're working on the designs, and a developer should be asking questions and showing their progress as they implement. This way you avoid situations where designers are building things that are overly complicated to implement and developers can implement the designs as intended while being able to flag up any challenges that might arise during implementation.

The absolute worse way to work is to ask a designer with little understanding of the system to design something. Then once they're done send that design to a developer who has no direct line of contact with the designer to build it. I've seen this done before and every time it results in bad designs and bad implementations - regardless of the ability of the individuals involved.

In my personal experience there's zero tension between myself and designers. The tension for me is when I'm not able to work as closely with a designer as I'd like to because I know I'm going to produce substandard work which I don't really want to put my name to.


This is what PMs are for. A good PM should have the skills and knowledge necessary to turn engineering limitations and design lofty goals into an achievable plan.


They can't work well together because they speak different languages (like React vs Figma), thus the friction.

One thing they can do is they can come up with a design system. Let them do the case studies together and came up with the solution together.

A design system, in essence:

- is a common language they can communicate with.

- is their consensus that they could agree upon.

- if they do the case study right, it will be a set of sane designs that works great on the target platform (Web, mobile, etc.)


I work at an ad agency designers design up a visual its looked over by a developer before it goes to the client to make sure they don't design something that can't be built.

> do you also find that there's a lot of tension between developers and designers?

Nope the designers can use what ever they want I take photoshop, illustrator, indesign, xd, figma what ever and build it thats my job. Designers make the decision on what tools they use for their job I decide what tools I use for my job. Let's face it once you learn one design tool the rest are fairly similar.

Any pain points I have seen have been from a lack of communication, designers don't know what developers know and they need you to tell them. This is a two way street I see developers turn their nose up at designs or give criticism on the design like the choice of colours when they should feedback on the build ability of the design.

Respect your designers they have a very impressive skill one most people lack and under appreciate. They are not like clients they understand their skill and industry as well as a developer does, treat them with the respect that skill and understanding deserves (don't talk down to them).

Once built designers can come across as critical of developers they designed a masterpiece and they want it pixel perfect. They often feedback that it needs more spacing or on small alignment issues. I could hand wave this as unimportant it won't look any better if I do what they say but I don't I take their skill and feedback seriously I fix the issue and it always looks better and they appreciate my attention to detail, the client is over the moon.

Work with your designers and they will make you look great thats their skill use it.


> For those working in tech/software development teams - do you also find that there's a lot of tension between developers and designers?

Quite the opposite: I typically tend to get along quite well with designers. Perhaps one reason is that I am myself a little bit on the "artistic" side of programming (e.g. with respect to elegance in code).

So, assume that in most cases the designer knows a lot more about what (visually) does look good and what does not and trust his judgement.

This, of course, assumes that you work with a designers whose artistic style is a good fit for an artistic style that you, as a programmer, appreciate for the project (e.g. should the GUI have a minimalistic, or skeuomorphic, or abstract, or realistic design?). I think that sometimes conflicts between designers and programmers are rather about having a very different opinion/vision on this topic.

What value does a designer bring to a project if he is not trusted in his design judgements and design drafts (at least in most cases)? He is intended to be the expert on this topic, and this is part of his role in the project. If such a trust does not exist, the designer simply cannot fill his role in the project.

Just to be clear: a quite similar statement holds in my opinion for choosing suitable programmers for your project(s) (even though I think that the very different programming styles that do exist are much more difficult to distinguish for non-programmers than visual styles are to distinguish for non-designers).

P.S. "Managers", on the other hand, are often a lot more difficult to handle for me than designers ... I can imagine that my "rather hands-off and trust" approach that works well when working with designers might violate some vanities of some managers. ;-)


It really depends on your company processes and culture. I've seen most trouble when SaaS companies expect frequent/incremental delivery of features from engineers, but UX is not part of team but some thing apart that hands over pixel perfect mockups worked on in isolation from the dev team, and that doesn't consider incremental delivery.


In my opinion, design tools like figma or adobe xd are abstractions away from the tech stack in which perpetuates more roles in which there doesn't need to be.

A UI/UX Designer should be competent in CSS in which the browser should be their whiteboard / canvas.

Abstracting the design portion away to other platforms only furthers that gap between design and development.

An optimal and streamlined design regiment is pen and paper straight to css.

Hire designers that are good with css in short.

To bridge the gap between design and development is not to find ways in which those teams communicate better, but rather a fundamental change in how we look at designers and their competency.

To further that point, if we take a look at motion design and animations, it should not be the case that a designer comes up with a wireframe and leave it to the developer to build that for building animations is out of scope for a dev task, but rather these tasks should be soley on the ui/ux designer themselves.


I work on a small startup team of 3. What makes my team unique is that I come from a Ux background but pivoted into development about four years ago. As such much of the friction between development and design is eliminated because I speak a common language. My teammates are pure devs. The senior dev has a decent sense of design. Early on we clashed because I felt that I needed to be the final say in design. That was my ego. When I stopped thinking this way, everything fell into place. All of us have a say on all aspects of the project. An inevitable consequence of this was that my Figma designs became a jumping off point for feature discussion rather than a blueprint that was religiously maintained. We iterated in code rather than Figma and we moved faster and smoother as a result. Every day it's a pleasure to work with my team because egos have been removed from the equation.


Ego can be such a hindrance for all kinds of interactions, professional or otherwise


The answers here focus a lot on improving collaboration. Almost all challenges in running a company come to this and there definitely is a lot you can do there. But it's hard and few companies pull this of and no one really wants to admit it. You usually get vague suggestions like "better communication" or "work less in isolation"

I've taken a different approach and I have become extremely conservative in extracting out responsibilities in a dedicated role.

I no longer try to build teams with the design role externalized in someone else, I just focus on finding developers who are also good designers. This is hard but I'd rather fight this battle than the collaboration one

If there truly is a 10x designer that wants to work with me then it's worth it, otherwise it's synergy of having one person be able to fully ship on their own outweighs the overhead of collaboration


From my experience. If you are a junior developer, you are screwed. If you are senior you have leverage.

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.


I'm a UX Engineer and although that means I deal with technical discovery, user testing and the effective implementation of design - It is true that the most challenging part of my day is facilitating communication and helping to resolve misunderstandings and challenge priorities between Design, Engineering, Research etc.

I do this in-person, and also with tools, technology, and documentation.

What I have observed..

Firstly

There is an historical divide and a sense of importance on the part of both disciplines. Each thinks they should have priority.

Secondly

In a Start-up or any company that is working like a start-up to get a product off the ground, we build for MVP and we use Generalists/T-shaped people and we work expediently with a flexible process.. ever heard of a JFDI?

When teams grow and products scale, we tend to hold onto this expedient way of working, because stakeholders do not want to give up the rush of getting what they want ASAP.

Nobody really wants to slow down in order to perform user testing, or implement a healthy process between design and engineering - we have formed bad (although appropriate once upon a time) habits and it's not expected that you will say 'no' upwards.

Thirdly

Having worked expediently, there is likely design and technical debt, this cripples the ability to form processes / better habits because there are almost always things to fix, and changing to a more considered process starts to look expensive when there are alway live bugs to fix.

Finally (Although probably not)

When a way of working needs to change, it is very, very hard to not sound critical of the work that has gone before.

No matter how I have approached it, whether I've met with groups or individuals, if I've been soft or stern.. People are sensitive and resistant to change, and if you are unlucky they will collude and actively work against the effort.


An actual answer..

How to get developers and UI designers to work well together?

1. Expect to implement new ways of working as you scale and communicate this. 2. Manage expectations with stakeholders and have them champion change. 3. Centre your efforts around Users, not any one persons or departments ideas.


I love designers! Especially when they listen to devs, or even better, can write CSS themselves. Devs should be in design review meetings, designers should be in the conversations about functionality. If you want a smoother workflow, make the communication happen.


Problems between "designers" and "developers" are usually symptoms of larger problems on the team. People lack trust in each other, and there's an adversarial mindset vs. a collaborative one and a shared goal of solving customer problems.

Well functioning teams don't have a magic guide on how to handle designers. You speak with your colleagues, share context and data, and make the trade-offs together. It's the same with developers who disagree.

Tooling? Pace / Workflow? These are trivial, and in my experience, are not the root cause of why your designers pushes back so hard on everything.


> there's an adversarial mindset vs. a collaborative one

I think this is what I am most sick of in most shops. Folks afraid to be vulnerable. And/or afraid to share their status / power by sponsoring other people.


I played both roles in different companies. One thing I found wasting a lot of time on in past companies was the back-and-forth around minor changes like UX copy. Every time I would want a different text in the app I would have to ask the dev to do so and vice versa, I had designers sending me minor changes they need me to fix in the production app. (Shameless plug: this is why I joined working on FlyCode[1] S22)

[1]: https://flycode.com


I really wish there a setting in browsers to disable animations. I think it’s a ux anti pattern.


The teams I had worked with since ‘16 had not had that tension. I think it is because there is a shared common ground of getting to product fit and developing a great product together. I see the developers respecting and valuing what the product team brings to the table, and the product team respecting and valuing what the developers bring to the table. It helps that there’s a strong mission, a worthwhile product, and that attracts people who want to contribute to society in that way.


No, not really. I've worked all hats and never really seen much disconnect, except when there was no communication - which usually starts with ineffective (ignored) comments from the people not communicating. This usually implies the other team is not paying attention and should, before the complete disconnect happens.

yeah I've seen both front end (user interface) and developer (backend/hardware/...) groups do this. And slightly more often - but not exclusively - the latter.


I'm going to shill a little bit, at Kitemaker[0], we use Kitemaker to solve this problem ;).

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/


It's only one tip, but if both developers and designers are in color-calibrated environments with color-accurate monitors, you can eliminate some it-looks-good-on-my-screen arguments with technology (colorimeters). Many developers that are working pretty close with designers are using really bad, not-calibrated panels and aren't seeing the same thing as the person giving them the design.


How useful is this in practice though?

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.


> 99% of the people using (most) products do not have perfectly color calibrated monitors

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.


> you can eliminate some it-looks-good-on-my-screen arguments

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?


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


I've lived in both the graphic design and engineering world and this is true. Most computer screens are way off in terms of color accuracy and it can result in wildly different results depending on what computer you are using. Viewing angle also has a huge effect on some screens - particularly the cheap ones.


This has been an issue at every team I’ve worked at.

My current team spontaneously started using FigJam for a variety of things (it’s like a real time multiplayer whiteboard) and I’m starting to think a cross between FigJam/Figma and JIRA/Trello would be a useful product. Basically tickets are directly associated with or “on” mocks, perhaps like annotations.

Maybe a good weekend project for me haha.


The fact that front-end developers and UI designers use different tools leads to them working separately, which is the actual problem.

Unfortunately, this is ultimately a talent/hiring issue, as it's easier to hire developers who have zero design experience and vice versa. When you treat people like interchangeable cogs, you don't get good collaboration.


technical beauty is rarely visually beautiful

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


I’ve been working very closely with one over the past few months and the biggest improvement is clearly defining terms and making sure we always stick to them

We realised we were using the word design for like 4 different things and often two or more interpretations were valid


Resolving Conflicts Between Designers And Engineers https://news.ycombinator.com/item?id=32160398


as a dev, i hate working with obsessive ux or ui designers.

they don't seem to care that i have more pressing concerns than whether something they've been staring at for 6 hours is 1 pixel off.


Calmly explain to designers, that their purpose is to serve the developers' needs and they should refrain from bombastic designs and focus on technical feasibility.


Common goals, clear processes, trust, and open, well-developed lines of communication.

Like everything else in life involving more than one human.


I find that when there is tensions its almost always indicative of the overall mismanagement of the project.


Stop hiring designers that can't code up what they design. Seriously.


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!


This is normally where a quality Product Manager can shine.


Well, UX is bullshit (otherwise there would exist software made after 2000 that has at least a decent GUI instead of complete nightmares) so you'll need to fix that first.


Sympathy is what it all boils down to.


Try https://www.specifyapp.com and thank me later!


I think there are a couple dimensions to this problem, and I've observed the balance points vary wildly from company to company.

Probably the largest axis I'd consider is "What do incentives look like and how does someone know if they're doing a good job?" Many software eng companies I see bring designers in later in their cycle; they aren't seen as an essential skillset for a young company proving out technology with alpha adopters, but that means by the time they're added, they're working on projects with histories, ingrained UI metaphors (often chosen by the software engineers), and a culture that already sees them as default-superfluous. Google used to be notorious for this, and they burned through UI designers at an alarming rate as a result.

This is not an impossible situation, but you have to frame the problems the designers are solving to make them winnable. Designers want to see their ideas implemented (obviously), so it stings if they put in a lot of work to see the idea tossed because it doesn't fit the (crappy) design that had historically accreted. So a couple of approaches I've seen work alright:

- get your designers on greenfield projects (and rotate them; spread the love so that designers don't end up pigeon-holed playing patch-the-crap while other designers are enjoying seeing their work out in the open)

- give designers the freedom to explore novel ideas outside of the current model, but make sure when they do so they have the understanding that they're trailblazing and the final product may not look like their trail. This benefits both sides; engineers are freed up pondering the UI side of things, and designers have the opportunity to create something aspirational for the engineers to pursue. Note that to pull this off, your designers need to know how to user test a design, and should probably be operating off of either existing stories (what problems users try to solve today with the current implementation) or new stories the company wants to implement in the not-too-distant future.

- pull engineers into the conversation early, but make sure the designers are driving the conversation. However, make sure both sides settle on a comfort level for blue-sky design vs. discussion of implementation and nuance. Left to their own devices, engineers have a tendency to dissect, pick apart, and deconstruct a design because, hey, that's their job, they have to build this thing.... So if they drive the conversation, you tend to end up with a design that looks like what's already there. But designers may lack both the technical knowledge of how things work under the hood and the historical / cultural knowledge of weird corner cases that the existing warty design grew support for. Designers are in a prime position to pull those needs out of the existing solution and consider if there might be a better solution.

If you're a software engineer interacting with a designer, the best approach I've seen to make those meetings constructive is to phrase concerns / questions about the design in the form of a user story. "I see in the design you have a multiple-choice list here... We do have clients that want both pepperoni and sausage on their pizza at the same time. Can we support that use case?" What I don't recommend is getting drilled down too badly on the engineering minutiae ("We can't support that because the data'd have to be in a tree and we don't sort it that way") until, possibly, much much later meetings; for one thing, designers are most valuable when they can step back from the implementation minutiae, and for another, if the design justifies the cost of supporting it you end up building that tree.

The overarching takeaway piece of advice is there's no substitute for working together... Communication / collaboration challenges are only ironed out by interacting until both sides find a happy medium. Every team sorts out what that happy medium is on a case-by-case basis.


This is essentially the challenge that I've built my career upon solving. I actually prefer to back it up one layer further and suggest focusing on how to get the business and developers to collaborate.

My answer to that question--which I know isn't the original but I think helps solve it--is that bridging the gap is, to a significant degree, the designer's job.

Note that I'm saying this as someone with a dev background but who formally took the UI/UX path, so there's definitely an "if all you have is a hammer" angle here. :)

My view: It is on the designer to have a reasonably strong technical understanding of what the application can and cannot do. IMO, design as a discipline is at least 50% engineering, because how it works under the hood has a dramatic impact on the end user experience.

---

Tips if you're on the design side:

- Ask technical questions, even if you don't really grasp the terminology yet. For example, where is this data coming from? Push the dev team deeper than broad answers ("the data lake"). Is this data cached uniquely for our application? How often? What's the response time? Does it come back in one big query or 15 little ones? Not understanding this results in annoyed devs asking you for loading states you didn't know you needed and will annoy you with a laggy app.

- Ask what libraries and frameworks the dev team is using. Read up on how they work. Walk through demos. If dev wants to purchase XYZ charting library, invest in understanding how it thinks so that you don't design something impossible. Conversely, once you have a good understanding, you're in a much better position to push back when it really matters. By making 90% of the app compatible with the dev team's tooling (which, remember, may have been forced upon them by politics elsewhere), you're buying goodwill for the really important, high-LOE custom bit that really should override dev reticence sometimes.

- For most projects, UI/UX is all about designing systems. The art is in the elegance of the system. The consistency, how it all meshes together, how easy it is to build upon and evolve. Express yourself in the beauty of that first, then add aesthetic exploration on top.

- And I can't emphasize this enough, if you can build your skillset to the point where you can build an average application in a rudimentary sense (i.e. it works, but isn't wired up or scalable), you will open so many doors and understand the dev team so much better.

---

Tips if you're on the dev side:

- Work to view your designer as your advocate and help them want to be it. Your designer should understand the implementation details 90% as well as you do. If they don't, help teach them. Show them how the framework thinks and why you chose it. If both sides come from years of cultural antagonism, this will require a lot of patience from both players.

- Remember that the designer is often reacting to feedback and external pressures just like the dev team is. They're trying to strike a balance between their best judgement (both as an individual and on behalf of users), the dev team's needs, the dreams of the business, and many other stakeholders who may or may not understand the process.

- Understand your designer's background. Even today some digital designers come from traditional design backgrounds and are learning to adapt to flexible viewports, etc. Note also that design tooling, especially in years past, could easily produce designs that exceeded the capabilities of HTML/CSS/et al. at the time (consider Photoshop CS2 vs IE6). It took deep technical knowledge and sometimes reversion of design best practices to reign the tooling in to something that a browser could efficiently support. I say this not to absolve responsibility, but drive empathy. :)

---

Also, shoutout to the answers by thomasqbrady [1] and apricot13 [2], who are capturing the "empathy" message I was trying to go for way better than I did. :)

[1] https://news.ycombinator.com/item?id=32153989 [2] https://news.ycombinator.com/item?id=32151110


There are a lot of reasons you can end up in this situation, and as many solutions to apply. Identifying the problems, choosing the appropriate solution and implementing it is a job.

You cannot learn an entire job from a HN post.

However, one solution can be used to solve all those problems: put a product manager in charge with a background in ergonomics (in the steve krug sense), and have this person steer the project from start to finish, with the legitimacy to direct people effort and choose policies.

The hard part now becomes to hire a good one.

A good one will know programming (Xor design), ergonomics and customer support. This person will know how to talk to the customer/end users, to the boss, but also to the designers and the devs.

Because eventually that's what it is about: having a good product vision, but being able to make sure this vision matches what the customers need, sell that to the boss, then direct the team to get it.

Expecting all of those people to behaved optimally is like hopping to win the lottery. It may happen, but chances are low:

- the boss may want fast things for cheap, or have another agenda/point of view about the project

- the customer don't know how to express what they really need. Sometimes they don't even know before you ask them.

- the designers are skilled at making visual things, but not all of them get out of their way to make sure they are making the visual things that are needed.

- the devs are skilled at making programs, but not all of them get out of their way to make sure they are making the things that are needed.

- they don't talk the same language, so every conversation means one should be capable and willing to make the effort of taking in a foreign jargon and context.

So unless you are very lucky to have most of those doing exactly what you want them to do, you need somebody that will steer the ship. And it's WAY easier to hire one single person with those skills than to make sure every single team member you hire is going to be able to see more than one's own area of expertise.

If you can't hire that person, then the next best thing is becoming that person.

In that case, you may want to read "Don't makes me think", all 37signals books, and "the mythical man month" for a first step into the marvelous world of building products with reality as it is, instead of what people wish it to be.

The rest of course is a lot of practice, talking to a lot of bosses, customers, designers and devs, then try to get the product in the right direction.

It's a long (yet interesting) journey, though, so good luck.


I have had quite a bit of experience with this.

I'm primarily a native Apple application developer, but have done some backend stuff, as well. I have designed numerous Web sites, but I am not a particularly skilled Web designer.

I was, in the days of yore, an artist. I have also taken numerous design and usability courses, from the likes of NNG (Nielsen-Norman Group).

I'm a passable graphic designer, but don't pretend to be anywhere near "pro" level. I know enough to be dangerous (and use many of the tools).

I have designed a bunch of fancy widgets[0 - 4]. I actually use very few of them, because they are too intrusive.

I am in the "refining UX" stage of an iOS app that I've been developing for the last year and a half, or so. I'm working with designers and testers, to clean up the information architecture, interaction, usability, aesthetic design, and accessibility.

For me, the most valuable technique, has been rapid, high-quality prototyping. I have been abusing Apple's TestFlight[5] beta release system, and have been using it to make regular (usually, a couple a day) releases to the rest of the team, who are mostly non-tech people. I've made over 600 releases. The first release was made less than a month after first code submission.

The way I use it, is that I run what I call "constant beta." The app is always at "ship" Quality, even if incomplete. This means that the code people get, is fully operational, for the currently developed feature set, and they aren't using some kind of "lash-up" kludgy throwaway code. They are working with the actual code that will ship.

This has the advantage of constant vetting by Apple. They don't test TestFlight to the same level as the App Store, but they look for things like unsupported API usage, code signing issues, and obvious quality issues (like crashes). In at least one case, their testing found a crash that I missed.

Once the first release for a version has been vetted (takes a day or so), subsequent build releases, within that version, are approved almost immediately, so I get quick turnaround.

If the testers encounter crashes, I get a fairly useless report. If I use a Ouija board, I can often figure out the general part of the application affected.

With this workflow, we can have a highly iterative process, with aesthetics, usability, and general UX, being tested, almost from the start.

It also means that integration testing (the most important kind), starts almost immediately, and continues, throughout the development lifecycle.

It also means that I throw away a lot of good code. Most of those widgets I referenced were once in the app, and we decided not to use them, so I broke them into open-source packages, for reuse in future projects (I tend to eat my own dog food. I have a lot of packages in the app).

I'm pretty good at interpreting designs. I can accept Figma, Photoshop, Sketch, Illustrator, Napkin Sketch, or Hand-Wavy Verbal Description, and turn it into UX. I usually have something for the designers to try out, within minutes.

Most of the actual app assets are generated (and stored in the app) as vector PDF, via Illustrator, and I will often redesign raster art, into vector.

The designers and non-tech stakeholders seem to like it.

WFM. YMMV.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

[1] https://github.com/RiftValleySoftware/RVS_MaskButton

[2] https://github.com/RiftValleySoftware/RVS_Checkbox

[3] https://github.com/RiftValleySoftware/RVS_RetroLEDDisplay

[4] https://github.com/RiftValleySoftware/RVS_AutofillTextField

[5] https://developer.apple.com/testflight/


> I've made over 600 releases.

I just checked. It's probably closer to 750.


PM has the last word.


This topic is near and dear to my heart. My encounter with this issue, and the way I approached it, have defined my career (been doing this about 22 years, now, and have gotten to work at some dream jobs with names you've heard in the meantime and currently). I did a few conference talks about it, but I won't link those unless someone is curious, just to make sure it doesn't seem like I'm trying to get views or something.

TLDR: No shock here, if you think about it long enough, but the answer I found was empathy. This professional relationship between designer and engineer (which I've found through many interviews—formal and informal—to be the same for architect and engineer, stage designer and carpentry shop, etc.) is still a human relationship. It's easy for a lot of people to forget that, or to think that professional relationships don't require emotional intelligence/work/etc.

Fairly early in my career as a front-end engineer I landed at a fancy advertising agency. We built high-end interactive marketing sites for big names. We had a lot of hot-shot designers who were VERY excited about themselves, and were, frankly, watching Mad Men a little too closely and drawing the wrong inspiration. It was quite easy for me to start blaming them for the parts of the design -> engineering hand-off process that weren't working. Their designs seemed to ignore the constraints of the technology, the budget, the schedule, etc. And several of them jerks who would quickly throw the engineers under the bus and say "the engineering team at the last place I worked could have done this in a week."

Then one day I started a new project with a new designer. He dropped by my desk with design specifications that contained all the info I normally had to go spelunking into design source documents to try to ascertain myself. This guy had put them all in one place for me to make it easy. I was shocked. I noticed something that wasn't technically feasible in the design right away, and thought I'd test the waters. "Could we do this differently? The technology won't allow this exactly because of [blah blah blah]." He listened. He asked if we could both think about it a little longer, him thinking of alternative designs and me seeing if there was some approach I hadn't thought of that might make it possible.

The next time I spoke with him, as he was about to walk away, I said, "Hey, quick question… how come you're not an asshole?"

I'm so glad I asked.

I've already gone on a while, so I'll try to summarize. Essentially, he told me a story from his days in art school. Final exams, which for his art program meant turning in a lot of finished graphic design projects, which meant getting a lot of digital artwork printed, which meant going to a print shop and handing over all the money left in his bank account and then just sitting there for hours waiting for the prints, realizing that he had not control over what happened at this point. Did the printer install the fonts the way he'd asked? Were the color spaces configured correctly? Did the printer know what they were doing? Were they any good? There wasn't going to be any time to re-print (let alone enough money to pay for that), so his final exam was completely in the hands of this printer.

"That's how we often feel working with engineers." He said. "We turn over to you design files that we're proud of. They're beautiful. Then we just have to wait and see, a lot of the time, what actually ends up getting shipped. Often what shows up doesn't resemble our designs. The wrong fonts, the wrong colors, padding, margins. Sometimes the layout itself isn't even close. And we're powerless to do anything about it, and if we speak up too loud we're called prima donnas."

I immediately realized how I'd been complicit in this pattern so many times. How many times had I totally missed things like padding/margins that didn't matter to me because my untrained eye couldn't even see the difference unless it was pointed out to me? How many times had I said "eh, good enough" rather than trying a little harder, or going back to the designer to see if we could find a middle-ground?

I thought of the design specs he'd dropped off and how helpful they were. I realized that the only way forward was to mimic his style: respect for each others' disciplines, empathy for the struggles that each of us had in our work, dedication to work together—to set each other up for success and put the quality of the work before our own personal convenience.

For me that approach got me jobs I thought I would never qualify for. I got so good working with designers I became one. I've worked as a front-end engineer, a design technologist (hybrid designer-developer), and even as a straight up lead designer (UX/interaction design) for the past 15 years. My career has been rewarding (getting to go to/speak at conferences around the world, getting to co-author an O'Reilly book, etc.) beyond any dreams I had early on, and I think I owe so much of it to that designer and his lesson in empathy.

This is a side-note that might be as important (or more so) than the main thread. Why was I able to empathize with him so quickly, instead of getting defensive, as was my wont at the time (and still is more often than I'd like)? I think the key was the STORY he told. It's so easy for us to drop ourselves into a story as the main character. When he told that story, I was the art student frustrated with the printer. When the tables turned and I realized I was actually the printer in this story, it was a powerful moment because I had put myself in the designer's place. My defensive instincts were coming out in defense of the main character of the story (me as the designer).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: