Hugs not shrugs: Building caring, sharing developer relationships for a better UI
Are you struggling to get on the same page as your developers? Tired of the designs you’ve painstakingly created being butchered in the build?
We’ve all been there, and a key part to achieving harmony between design and development is forming and maintaining healthy relationships with your developers. If you want to communicate effectively and solve problems effectively, this is essential.
18 months ago we embarked on a complete redesign of our core restaurant product. It’s the biggest redesign of the product to date and is dramatically transforming the working lives of thousands of our restaurant partners and their staff. It was also essential to address a range of usability issues, and re-platform to ease future development. On top of all that it’d enable us to continue to build an excellent restaurant and customer experience.
During that time I’ve worked closely with the 6+ front-end developers assigned to the project, based in the UK and internationally. So, in this article I want to share some examples of the things I’ve done during this time to help build these critical parts of a relationship. I hope that if this is something you’re struggling with or about to do you’ll get some helpful tips you can action.
Transparency
Transparency is important because it puts everyone on the same page. It can create an environment where people feel free to share their opinions, work and ideas. I think one of the privileges of my job is being the person who can create that transparency and can literally show people ideas and stimulate conversation.
Example 1: Create a shared space to discuss design work
Sharing your work early on is essential, but sharing your work also makes you vulnerable because a designer’s work is far more than just a screen design; it’s an emotional investment, something that’s typically had a lot of care and thought put into it. However, you’ve got to put all that aside if you want to create the best work. You can’t do that alone and without the feedback you get from others it’s hard to know what can be improved.
That’s why, early on in the process I set up a Slack room and invited design and development stakeholders to join, so I had a single place to share and discuss design direction and ideas. This room really evolved over time to become a consistent place for all UI-related chat and a real hub of questions and answers about how we were going to solve different problems.
Example 2: Create a single source of truth for design work
When we planned the project, we broke down our MVP into sections — this set a structure for what we’d design and build first. This gave me a basis for structuring my Zeplin project (at Just Eat we use Zeplin to bridge the gap between designs and development). Establishing Zeplin as a single source of truth for my design/development/BA/product colleagues made it much easier to discuss and feedback on the work, but also made the visual designs a lot more accessible to stakeholders.
You might not be able to use Zeplin, but if you’re able to create one place where your team can go to find your latest designs this will help to improve transparency and communication.
Zeplin allows one project for free, so if you’re a small team this might be enough. Alternatively you could try using Invision or Adobe XD, both of which have free and paid-for versions. Invision and Zeplin both provide Sketch integration that makes uploading your designs much easier. Adobe XD allows you to import Sketch files but you’d probably benefit from moving your design work to XD as well, if that was your only option.
Collaboration
Collaboration is one of those things that’s easy to forget about, especially when it comes to collaborating with people you don’t know, and can often lead to uncomfortable situations. Those ‘quiet’ workshops where no one is engaging — we’ve all been there. But, similar to transparency, collaboration is important in getting everyone on the same page. Sharing ideas and expertise, whoever they come from, can dramatically improve the final results.
Example 1: Collaborative and inclusive workshops
At Just Eat we work in two-week design sprints, so a really obvious and easy way to improve collaboration was inviting people to our sprint workshops. Attendance for the developers was optional, but I strongly encouraged it because it gave them a chance to contribute to the process. This worked really well; the developers were instantly more engaged and able to contribute technical expertise that gave the group a better understanding of the constraints we’d need to design for.
When it came to development, particularly refining tickets (refinement is the process of sizing and deciding what development work can go into the upcoming sprint), we were able to draw on the work that was done as a group. That shared understanding made making decisions much easier.
Example 2: Work together not alone
One of the benefits of UI designers not being developers is that they’re not constrained by code. This can result in design work that’ll really challenge both designers and developers and provides a great opportunity to work together in the actual implementation. Throughout the project there were occasions where a developer would get to one of my screens and I’d get a message on Slack saying,“This looks great, but I’m not sure how long it’ll take to build, but if we do it this other way then it’ll only take an hour.”
As the designer, at this point you’ve got to start by asking more questions. If possible I’d walk over and speak to them or I’d get them on a call. And this is where it can really pay off to have some understanding of how the things you’re designing are built. It improves communication and allows you to troubleshoot issues together. You can find common ground and come to a solution that works for both of you and results in the best solution for the user and the business.
Shared goals
If you can create clear shared goals for both you and your developers, that gives you a stronger joint outcome to work towards.
Example 1: Set clear shared goals
A clear shared goal is one that both parties understand and agree with. They aren’t always as formal as being defined in a workshop and they don’t need to be. In my case, many were created during Slack conversations.
One example of this was when it came to considering how we’d cater for multiple devices. The initial project required us to design and build for just a single screen size. However, as the project developed it became clear we’d need to accommodate a range of devices in the future. Through a lengthy Slack conversation with one of the senior developers, sharing designs and emulator screenshots back and forth, we were able to establish what our own individual goals were and then use these to create a clear shared goal.
Designer’s individual goal: Design a scalable interface
+
Developer’s individual goal: Responsive development that doesn’t require multiple layouts for different devices
=
Our shared goal: Create a functional product regardless of device
Example 2: Put processes in place to make these easy to achieve
Once development on this project really started to ramp up, it became clear that we were missing a QA check for the front-end work. I wasn’t seeing designs until they were shown in demos and by that time the developer responsible was usually working on something else.
Our shared goal was clear — both design and development wanted to maintain a high standard of UI. So, to ensure this we put into place a really easy and efficient process: Once a developer had completed the work they’d tag me in the ticket and include a screenshot. Each day I’d review the various screens and could give feedback to the developer in question, then we could troubleshoot and resolve any issues together.
Introducing this small additional step has reduced the amount of front-end issues I was raising and considerably improved the quality of the final product.
What you can do next
- Share a design you’re working on with your development team, or one of your developers, ask them what they think, start that conversation outside of design.
- If you’re coming to the end of designing a feature, set up a 15 minute call to talk it through with the team, explain you’re rationale and be open to questions.
- And finally, when was the last time you solved a UI problem with a developer? If you’ve noticed something isn’t displaying correctly, talk to the person who built it and understand more about it, then find where you can align to fix it.
In conclusion, relationships matter
Good relationships are the basis of healthy teamwork. I think a lot of what I’ve learned could equally be applied to building a productive, creative relationship with any colleague, not just developers. But as a UI designer, you are uniquely reliant on the expertise and experience of your front-end developers to bring your works to life, and that’s why I think these relationships are some of the most important.
Be transparent, be collaborative and create those shared goals. You’ll literally see the benefits.
Fancy getting stuck in?
Come and help us serve up the world’s greatest menu. Find out more.
