Working with designers: Lessons learned working as a Designgineer

Over the years, Ive 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.

Ive been there and back again a few times. Here are some ideas and best practices Ive picked up along the way:

Theres no replacement for open communication and hands-on collaboration

This couldnt be more true. It doesnt matter how detailed the designs, how exact the redlines, or how comprehensive the prototype, if theres little to no human interaction in the handoff, design intent will get lost in translation. Even if your designer hands you perfect assets, theres still a strong likelihood that youll miss the intent, purpose, feel, emotion, vibe, [insert UX buzz word] and they wont 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

Youre not wrong. And also, youre 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 products 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 doesnt need to be present for the whole meeting, but having them show up for the last 5-10 minutes will prove invaluable. Dont wait for designers to invite you to the meeting. Check out what theyre 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 isnt able to handle. A lot of web designers dont 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 its 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 theres not enough room under the hood. Imagine theres no hood at all. Imagine your designers disappointment when you tell them that it doesnt matter how aerodynamic and fast the car is, it still wont 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 dont have to be a product manager to point out that your product isnt aligned with business goals. And you dont have to be a designer to point out that a design is unintuitive. Theres an expression in UX design, Youre 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, its time to challenge assumptions and do some testing.

Dont 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 isnt about you. Its 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, lets be honest, everyone you work with can tell.

Be bold and stay humble

Ive 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 arent they asking questions? Why are they spending valuable resources on something they know should be different?

More often than not its 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 isnt worth it. The designer wont change their mind. Worse, theyll tell the developers theyre wrong. They do it because they dont feel trusted and theyre tired of hearing, we cant do that or just, no without any explanation or partnership in finding a compromise.

So, be bold and stay humble. Ask all the questions. Its okay to ask design questions as an engineer. Its okay to point out that some piece of the UI doesnt make sense to you. But, be aware of what you say and how you say it. The text on this button doesnt make sense to me or we cant 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 wasnt 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, youre 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. Theyll take you off the naughty list and add you to the, this person actually knows what theyre doing list.

The best user experience is the result of a healthy balance of design and development concerns

When were building whats been designed, were not just building whats been designed. Were maintaining a codebase, ensuring its secure, performant, scalable, etc. Designers should know this. I repeat, designers should know this. Usually, they dont so, tell them. I dont 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. Its important that they understand the cost of making that icon vertically center-aligned with that text. They should know youre going to have to add position: relative; top: .908432rem; and when they inevitably want to change the design later, its 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 wont be affected if the icons alignment isnt pixel-perfect.

As developers, we cant 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 users 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 others business. Be nosy about what your designer is working on.

1. Have open communication and hands-on collaboration throughout the process
2. Attend every design meeting
3. Start your tech design as soon as possible and include designers in your meetings
4. Be bold and stay humble
5. Good UX also means your codebase is awesome