I thought this was a joke? The hierarchy is a mess in the "final" version.

+1 to Figma

From what I've seen, I doubt you could just drop the components into a code base and you'd be good to go. It looks it might work better the other way around: Pulling in your teams React components to use them in your designs.

I really don't think it's just for handing off React components. It can do all of the prototyping and interactions way better than anything else out there right now. It can leverage the large React ecosystem that already exists to create just about anything you can think of.

That said, I think it's much more powerful for people that also know JavaScript and React quite well. It reminds me of the Flash days with Actionscript.

I think the idea is that you use a real code editor.

• Never use lorem ipsum, always use real content. You can't design without content, otherwise you're just creating templates. Figure out the narrative and what you want to say first. The design is just an implementation of that narrative.
• Figma and Paper
• Go with the best you've got, even if the tone and grammar isn't perfect.

Everyone has mentioned good points already, but here's a few others that might help.

Do some user research. Nothing works better than data proven the design is better. If you can show your designs with and without the changes to an audience quickly, you can prove that a slight animation actually increases usability. But be prepared to be wrong.

Create a design system if you don't already have one. Developers understand the need for systems that solve many problems. If they understand the design system they'll be able to implement it knowing that it will be used again and again. Get them to help design the system too so they understand the decisions for the type and spacing scale.

If they just don't care about getting the finer details right – spacing, type, color – then you're going to have a hard time getting past that. Creating a design system can help, but you'll need to have a front-end developer on the team who cares about those details.

Try to relate your concerns with problems they understand. I've often related design quality to code quality. Engineers have linters, formatters, and best practices. They're often pretty OCD about it. The same way they do code reviews, they should be doing design reviews. The same way they have tech debt from corners cut, there's design debt from corners cut. There's common ground there.

Finally it can come down to your influence of the team. Small things like speaking confidently, standing tall, and being assertive shows people that they can't just take the easy way out and that this is important. Make sure your arguments for change are strong and you're not just doing it because "it looks cool". Don't sacrifice the details that you can't necessarily measure for impact.

Also, don't think of it as "dealing" with developers. They have concerns and some of them will probably be important. The team needs to work as a unit. Without that you'll always run into issues.

The business decision for doing this is what I'm most interested in. The previous site was pretty clear, the style was unique, and the way they used color to distinguish products was simple. I'm possibly not their target audience so it seems like a pointless rebrand, but I highly doubt Intercom would redesign without a reason. I just want to know what that reason was.

It's Dropbox all over again

This is something I've been conflicted about recently with some projects, specifically related to quality vs. impact. Thanks for the article Joel! I needed that today.