What collaboration between design and development can look like

Côme Bohu
The AB Tasty Tech & Product Blog
5 min readSep 19, 2019

I’ve always enjoyed working with developers, not only do they give life to my designs but they also help me to improve my work and improve my processes.

At AB Tasty we develop an all-inclusive platform for conversion rate optimization, personalization, testing, and insights and that comes with a daily dose of technical/product challenges.

Which is why the collaboration between designers and developers is a keystone of feature teams at AB Tasty and I’ll give you a glimpse on how it can work out. Disclaimer: I acknowledge that all feature teams can have slightly different ways of working and, what works for my teammates and myself is not necessarily true for other teams within the company.

Bottom line, it’s important not to over-process the way we work by imposing one single framework. Pick the good stuff that works for your team and leave the rest. It’s not a one-size-fits-all.

That being said, here are a few key points I believe are important to collaborate as a designer with developers so you can work efficiently.

Let’s see how to avoid this

Treat your collaboration as a design project

As a product designer, you should consider developers as a persona of your working environment. You should know their pain points and what they expect to create a smooth workflow.

“Show your work early” is one famous design moto. It means involving your developers from day one, to get feedback and come up with the best solution together. Design is a team effort: my role as Product Designer is to bring everyone to the table at every step of our project, so they can understand more about user problems and suggest solutions early.

Show wireframes as soon as possible. Even if it’s drawn on a whiteboard, they bring attention to points (technical or not) you’d not have thought of. Quite often I find myself with a way better version of my work when I leave a meeting room.

Make them understand who the end-user is. With a better customer vision, they’ll bring even more valuable solutions. Invite them to meetings with customers, share what you learned (journey, empathy map, whatever fits), go with them to user testings. Pass your customer obsession to your teammates and they’ll become the voice of the user.

Do it regularly. We do those sessions at the very least every week during our scrum rituals. Everyone should be able to speak freely on design.

Share your design deliveries the right way

Clear and consistent design deliveries are a prerequisite to ensure good collaboration with developers. Like many other teams, I use the combo of Sketch and Zeplin to share my work and I specify my user flow and interactions thanks to overflow.

One does not simply throw mockups to developers
That’s just a bad idea

I use those outcomes to infuse a design culture within my team. I explain both the story of our users, the context and how we solve the problem and spring on top some visual principles — why we snap elements on the grid, the psychology of colors, how you balance components to reduce the cognitive load and so on.

The more they get this designer mindset, the better the overall design will be. They’ll make better suggestions, see things that you had overlooked and improve your work.

Similarly, I try to write User Stories and Specifications to better understand what they expect from a product point of view and to get a better immersion on what’s expected from a technical side.

Last but not least, we consider that development is always possible when low-fidelity wireframes are available — as long as they’re validated by research, usability testing and that you give them context and enough guidance. If we had to wait for the final UI to start developing, our pace would be incredibly slow.

Check development early

Don’t waste time: as soon as there’s work my PM or I can check on screen, we do it. This way, I tackle most things before it goes to QA and I’m ensuring we get a nifty design.

I have set up a bot reminder on slack that’ll ping the team daily to ask whether or not something needs to be checked. We make sure I never forget to make a first design filter before sending the work to the QA Team.

Those pair-design sessions on their local environment are great: you can both infuse this design mindset and get to know how they work and improve your tech skills. Everyone wins.

Commit to improving your design continuously

Trade-offs are part of a product designer’s daily routine. Finding the right compromise is an art, between what you’d like to ship, what’s realistic in a short timeframe, what’s delightful and valuable enough.

Quite often you accept imperfections because it supports your shipping pace and it doesn’t block people from using your product. As these add up, your look and feels is deteriorated and it cheapens the overall experience. Yet, it’s forever overlooked.

A designer nightmare

To maintain this balance between delivery and user delight, we always allocate in our team 10–20% of our sprint velocity to take care of those little things that make a nifty product.

We call them “design debt” and we commit to solving them — as well as we do for technical debt and bugs. I feed a design backlog with tasks that can be taken anytime and that help to maintain a certain level of quality.

It has now become such a habit that sometimes those tasks are just worked out without me asking for it.

There’s no perfect collaboration between designers and developers. Although, it only takes a few commitments to smooth out the communication hiccoughs and other difficulties.

I hope some pieces of advice above will be of help. As an overall recommendation, try out things and see what works for you and your team. Design is about iteration after all.

--

--