Over the years, I’ve worked with small and large companies as a Designer, Developer, and UX Engineer. No matter the size or shape of the company, the intersection of design and development had room for improvement. The relationship and interactions between design and development teams are some of the most crucial in product development. They will make or break the success of a project.
I’ve been there and back again a few times. Here are some ideas and best practices I’ve picked up along the way:
There’s no replacement for open communication and hands-on collaboration
This couldn’t be more true. It doesn’t matter how detailed the designs, how exact the redlines, or how comprehensive the prototype, if there’s little to no human interaction in the handoff, design intent will get lost in translation. Even if your designer hands you perfect assets, there’s still a strong likelihood that you’ll miss the intent, purpose, feel, emotion, vibe, [insert UX buzz word] and they won’t make it into the final product. The intangibles are hard to communicate. Period. Eliminate as much room for interpretation as possible by having not just one, but many conversations throughout the product development process. Invite yourself to all the design brainstorming sessions. Include designers in your tech design meetings. Include product managers and anyone else on your team.
But including everyone in every meeting makes us move slowly
You’re not wrong. And also, you’re wrong. Including the whole team in every meeting might be overkill. But including the whole team in most meetings, especially early on, is critical to building a shared understanding of the product’s purpose, how it impacts customers, usability concerns, design intent, etc. - all things that impact the little decisions (and assumptions) we make as we are building the product. Your team doesn’t need to be present for the whole meeting, but having them show up for the last 5-10 minutes will prove invaluable. Don’t wait for designers to invite you to the meeting. Check out what they’re working on incrementally. Stay involved. Provide feedback. Ask questions. Let them know that you care about the end product as much as they do. Let them know that you want to create the best user experience, too.
Engineering presence in design meetings can eliminate problems later in development that arise when you discover that designs include features your tech stack isn’t able to handle. A lot of web designers don’t actually know how a website works behind the scenes. Imagine a car designed by someone who has no knowledge of what is required to make a car actually do all the things it’s supposed to do. Imagine your designer hands you the car designs at the deadline, with no room to spare. Imagine how much work it takes you to figure out how to strap the engine and transmission to the roof because there’s not enough room under the hood. Imagine there’s no hood at all. Imagine your designer’s disappointment when you tell them that it doesn’t matter how aerodynamic and fast the car is, it still won’t fly.
Likewise, including designers in tech design discussions and reviews can save time following-up on questions and eliminate confusion around design intent. This means less time rewriting code and a smaller, more meaningful backlog.
Trust your teammates
You don’t have to be a product manager to point out that your product isn’t aligned with business goals. And you don’t have to be a designer to point out that a design is unintuitive. There’s an expression in UX design, “You’re not your user.” This is true and does a good job of reminding designers not to make assumptions based on their own personal preference and as a team, you have a lot of different, valuable perspectives and opinions. If one or two people on your team think the product is unintuitive, it’s time to challenge assumptions and do some testing.
Don’t be afraid
Your teammates need to have eyes and input on your work. Get over your fears of designers seeing partially-functioning features or messy code. This isn’t about you. It’s about your team, product, deadlines, and most of all your users. When you are efficient, thoughtful, and thorough, your product will be efficient, thoughtful, and thorough. Your users and, let’s be honest, everyone you work with can tell.
Be bold and stay humble
I’ve seen it happen time and again: A designer throws a design over the metaphorical wall to developers and instead of asking questions and challenging unusual design patterns, they decide they can make it work. Why? Why aren’t they asking questions? Why are they spending valuable resources on something they know should be different?
More often than not it’s a combination of fear and frustration, the root of which is feeling unappreciated and looked down on. The relationship is strained already. Previous experience has taught them that speaking up isn’t worth it. The designer won’t change their mind. Worse, they’ll tell the developers they’re wrong. They do it because they don’t feel trusted and they’re tired of hearing, “we can’t do that” or just, “no” without any explanation or partnership in finding a compromise.
So, be bold and stay humble. Ask all the questions. It’s okay to ask design questions as an engineer. It’s okay to point out that some piece of the UI doesn’t make sense to you. But, be aware of what you say and how you say it. “The text on this button doesn’t make sense to me” or “we can’t do that” can sound abrasive, no matter how pleasant your tone. Try, “I was walking myself through our experience, trying to imagine myself as a user, and when I got to the point where I was ready to move forward, the only UI element available to me was this button but, I wasn’t sure if I should click it because the text made me think it was for something else. What if we changed it to ______?” The second sentence shows that you care about the design, that you are empathizing with your user (walking in their shoes), and you are not just stating a problem, you’re offering a possible solution as well. Your designer is likely to be thankful you pointed it out, work towards a better solution, and hold a higher opinion of you. They’ll take you off the naughty list and add you to the, “this person actually knows what they’re doing” list.
The best user experience is the result of a healthy balance of design and development concerns
When we’re building what’s been designed, we’re not just building what’s been designed. We’re maintaining a codebase, ensuring it’s secure, performant, scalable, etc. Designers should know this. I repeat, designers should know this. Usually, they don’t so, tell them. I don’t mean schedule a meeting to educate them on what you do in an average workday. But when they come to you with a design that is going to require you to write lots of extra, messy code that could be avoided (Hi, I see you, CSS) for one very small piece of the UI, ask for a compromise and tell them why. It’s important that they understand the cost of making that icon vertically center-aligned with that text. They should know you’re going to have to add position: relative; top: .908432rem; and when they inevitably want to change the design later, it’s going to be a lengthy process because it will introduce a breaking change to the 15 teams that depend on that little bit of code. They should know that if you just leave that bit of code out it will make everything a whole lot more maintainable and scalable. And they should already know that the user experience won’t be affected if the icon’s alignment isn’t pixel-perfect.
As developers, we can’t afford to make these quiet concessions to keep designers happy. Great UX comes from making compromises or rethinking experiences so that they address all your user’s concerns and keep the code base maintainable, scalable, performant, etc.
TL;DR
Get in a room or on a call together on the regular. Get up in each other’s business. Be nosy about what your designer is working on.
- Have open communication and hands-on collaboration throughout the process
- Attend every design meeting
- Start your tech design as soon as possible and include designers in your meetings
- Be bold and stay humble
- Good UX also means your codebase is awesome
Top comments (2)
"won’t change their mind. Worse, they’ll tell the developers they’re wrong. They do it because they don’t feel trusted and they’re tired of hearing, “we can’t do that” or just, “no” without any explanation or partnership in finding a compromise"
That resonates with me from many experiences, across many technologies and relationship-types. Ultimately it is about trust and when someone both doesn't trust you AND doesn't think it's important for you to understand why [whatever the issue is about] AND/OR doesn't care that your concern is addressed; it's a very uncomfortable situation and sets a precedent that isn't productive for the product or the humans.
Great points all around!
Well said. That kind of precedent can be like a virus. Before you know it, you have a whole team with a grudge against another. Hard to see people as people when that happens.