All engineers have important cross-team relationships that we work with on a daily basis. QA catches our mistakes (hopefully), PMs provide us specs and schedules, and IT and Dev Ops keep our machines and servers working – but there is one relationship that is particularly special to frontend engineers: UX.
A symbiotic relationship between you and your UX team will enable you to create features that are engaging and user-friendly. Not only will this improve productivity between frontend and design, but it will also ripple through the company, positively impacting every department that has a part in the process of planning, developing, and maintaining features.
I have been an engineer for 15 years now, most of which were spent working on the frontend closely with UX. I’ve been lucky enough to have great relationships with all my designers, but what makes me truly passionate about this is that I’m married to a designer and have seen the effects that a negative relationship can cause.
Between my wife and my mother, who was an artist, I really appreciate how precise and detailed design can be and admire the effort it takes. The culmination of great relationships I have had in my life inspired me to write a series of blog articles to share with other frontend engineers what I think has helped me create those positive relationships over the years. Hopefully these can serve to build a foundation for a bright sunny rainbow-colored world in which engineers and designers can frolic together alongside ponies and unicorns 🌈🦄 ... or maybe just makes the lives of a few designers (and their significant others) a little bit better.
Well, What Is a Negative Relationship?
At this point, you’re probably wondering what exactly is a negative relationship. I use the word “negative” in particular, as opposed to “bad,” because in some negative relationships you may get along just fine at the office, but the balance of opinions isn’t ideal or you’re just not getting everything out of it that you could.
Here are a few basic categories of negative relationships I’ve encountered the most along with some real examples, taken from my own experience, my wife’s, and Indio’s Director of Design, Dave Rolnitzky:
-
Silent observers 🤐 – Fail to ask questions, point out issues, and raise concerns that help a designer do their best work.
Example: Bob was a new, junior engineer hire going through a design review for a new onboarding flow. He had fresh eyes and a different perspective that would have been valuable, but he was afraid of asking a "dumb" question.
-
Know-it-alls 👩🎓 – Think they know more about UX than their designers and may ignore aspects of a design, be unwilling to move on when they disagree with a decision, or believe that designers just exist to make pretty icons and images for them.
Example: Dave was working at another company, redesigning a navigation bar and talking through various choices, when an engineer went ahead and changed the navigation bar without consultation, later saying, “I thought this made sense so I’m just going to add it.” While functionally it worked and she had some good ideas, she didn’t consider consistency with the current site and future designs, and now users would end up experiencing two redesigns in a short amount of time.
-
Poor communicators 📞 – Usually unintentionally, but sometimes deliberately, speak in technical jargon that most designers do not understand.
Example: Bill was a senior developer who went into the complexities of CSS and browser support whenever his designer requested a change because he didn’t feel a change was worth his time and wanted them to drop the issue. He would claim certain designs were impossible given CSS’s limitations (when they weren’t) and undermined his designer to their PM just to avoid doing work.
-
Selectively apathetic 🤷♂️ – Either don’t notice or care about visual details.
Example: Dave worked with another developer named Joe who only cared about functionality. Joe didn’t trust that his design team was making changes to help the user and didn’t like to “waste time” making visual changes for “art’s sake”.
Bonus example: Sue was a backend developer who thought frontend was easy and would often submit markup without being code reviewed that had been generated and only modified to use the right string values. Everything was positioned using absolute positioning and margins, so it wasn’t responsive, didn’t wrap, and wasn’t vertically centered properly (my personal pet peeve).
What Should I Know Before We Talk About Positive Relationships?
Before we start talking about what we should do, I think it’s important as a developer to know a little about UX and designers.
First off, UX is multi-disciplinary, just like engineering! This was actually news to me until I met my wife 😅. At many companies including Indio, the designers are multi-disciplinary, but at some point you may work at a company with more specific roles, so it’s good to understand the differences.
The two most common disciplines are UI (User Interface) and UX (User Experience). The naming is a little confusing, but when designers are talking with each other they know the difference.
UI designers aka visual designers focus on designing the look of a website or product and/or make the little icons that we all depend on 🎨. The UX designers figure out what the user needs and how to achieve that in a big picture 🌏, and have less to do with individual page or component designs.
The design process is fluid and iterative. This part can be super frustrating as a developer, because sometimes you implement something exactly how it was designed, but then they change it.
The reason why is actually very logical – UX initially designs something with little or no knowledge of whether the users will find it intuitive. In a best case scenario, they’ve done a lot of user testing, but even then they don’t know about every edge case and different user type.
There’s no such thing as a perfect design that will make everyone happy – heck, sometimes they get some great feedback from one of their developers that leads to a change! 😎
Okay, So What Is a Positive Relationship?
The biggest thing our design team at Indio brought up was to have mutual trust and collaboration between a company’s engineering and design teams. Developers need to trust that UX will ultimately make the right design decisions and UX needs to trust that we can produce whatever they can design and will give them constructive feedback and catch corner cases early in the process.
Every relationship is unique, but keeping these points in mind will set you up for success.
Ask Questions and Provide Constructive Feedback Early and Often 🙋🏻♂️
-
Bring up corner cases – For example, what do we do if there is an error, a narrow window, long text, or a long list that will require scrolling? Maybe there is another use case they haven’t thought of? What about hover/focus/disabled states?
-
Bring up inconsistencies – If another page in the product uses a different text style, icon, or paradigm for a similar case, tell design! They’re human too; they don’t know or remember every previous decision. Maybe we’ll use that page’s design or maybe that page needs to have its design updated.
-
Give accurate time estimates ⏱ – If there is a technical limitation that makes a design difficult or there is an existing component that will save you a bunch of time, say so early on. Maybe they still decide to use the new design, but at least they have the information to make that decision.
-
Compliment good ideas and elegant designs! Shout out to the Indio design team for all the great work they do! ❤️
Understand Things From UX’s Point-of-View 👀
-
Be patient. Sometimes they don’t update a design or get you an icon right away because they need to talk to different stakeholders or are busy with multiple projects.
-
Most UX designers aren’t super technical and like to communicate visually 👩🎨, so avoid getting too technical and when you have a question or find an issue, send a screenshot – or better yet do a screen sharing session!
-
Familiarize yourself with their tools and processes 🛠. Figma, Sketch, and Adobe all have ways of getting color values, the spacing between controls, and extracted SVGs – be sure to learn them and use them.
-
If you have an opinion, share it, but accept that sometimes UX will disagree and that they and Product make the final decision.
In Conclusion
Thanks for reading my first blog post on the frontend engineer/designer relationship! I hope to bring you more on this subject soon. Remember, all relationships require maintenance and work, so don’t take them for granted!
TJ Hsiang is a Senior Fullstack/Frontend Engineer at Indio.