How designers and developers can pair together to create better products
Cross-functional collaboration, for empathy and results
Around about every two weeks, I spend half a day pairing with a developer on my team to fix design tweaks. I enjoy it — it’s fun to stretch my CSS muscles and spend a little bit of time with the code. I always walk away feeling good — like I’d had one of my shoes untied and now I’ve fixed them. Everything was just a little wonky before, but now the world is in order. 🙏 As a designer, fixing those little design tweaks is the difference between 😕 and 😍.
Before we jump in — what’s pairing?
Pairing is two people working on one problem at one time. Two mouses, two keyboards, two screens, two seats, two desks… and the screens are mirrored, so you’re working on the same thing, at the same time.
Why do dev-design pairing?
It’s a much faster way to communicate design tweaks.
I use dev-design pairing as a quick and easy way to iron out those final design tweaks in new features as they get built. Talking and doing the work together is way faster than trying to communicate fiddly design things in writing.
Sometimes the changes I want to make sound something like, “Fix up the spacing in the header.” For a designer it’s pretty easy to look at a header and see immediately what’s misaligned. But it’s super annoying to try to communicate that via text — especially as it can take a little bit of trial and error and doing things by eye to get it right. It’s so much easier to just sit together and talk than try and write, “Move left hand side of navigation ~10px to the left” and leave your developer having to work out how to make that happen in real life, and then work out whether what they’ve done is what you wanted. And then communicate it to you that they’re done, and then have you communicate back that it’s still not quite right, but you haven’t seen the code, so you don’t fully get why it’s just slightly off…
If you’re anything like me, after 2 rounds of this teeth-pulling traditional “design UAT” process you’ve more than had enough, and you’ll probably let the design go out to the world looking the way it is just to avoid any more rounds of tweaks. Plus, that time-consuming and frustrating process is exactly how engineers begin to hate designers. We don’t want that. Let’s all be friends.
Pairing timeboxes the 10% design tweaks that can take 50% of the time.
Product Managers love dev-design pairing because it allows them to timebox design polish tasks. Without a designer directly involved, it can take a long time for developers to get to final pixel-perfection. Because a mockup is silent. A mockup says nothing about where compromises can be made and where they can’t. If you can let stories be accepted for some time at 90% pixel perfect, you can sit together every few weeks and push through that final 10% that makes all the difference to how polished your product looks.
It grows empathy between development and design
I love pairing because it gives me the chance to talk through my design decisions with the engineers. They get to understand why decisions get made, what things are negotiable and what we’re thinking about for the future. And I get the chance to see under the covers on how the product is structured. That means I get to know what tasks are difficult and what are freebies, and means I can iterate on my designs in the future if it makes sense, to make things faster and easier for the engineers. Empathy is always number one, for your users and for your team!
How to do dev-design pairing in your team
1. Create your list of tasks
During the time between pairing sessions, I compile a list of things I spot in the product that I want to fix. I use a list of tasks in a story in Pivotal Tracker, because that’s the project management software my team uses, but you could use whatever format makes sense. Here’s an example of the kind of tasks I write:
The beauty of this is that because I’ll be there helping do the work, I don’t need to explain it any more than that 💁
2. Get some time prioritised
Book in a time to do pairing. Set aside a full morning or an afternoon. Personally, I find coding a little exhausting so I avoid doing full days or my brain will melt out of my ears by 4pm and my pair will be left to scoop me up. But if you are not like this, you could do pairing less often, for longer stretches.
3. Be a good pair
Here’s some tips on being a good pair in general. For designers and devs, there are a few other tips of my own.
- Always share the why. Don’t say, “let’s change this text size to 16,” when you could say, “Let’s change this text size to 16 so it’s consistent with the paragraph text across the rest of the app.”
The more you let your pair in on how you make design decisions, the more they’ll be able to make decisions like you after you’ve been working together for a while. Win, win! - Have empathy for your pair. Coding is hard, man.
4. Have a quick pair retro
If you can do with communicating about how the session went, set aside 30 minutes to do a quick pair retro ( I recommend using Postfacto) at the end of the day.
Do I need to know how to code?
Nope. It’s helpful if you do, because you can jump in to the CSS/HTML and drive sometimes. But if you don’t know code, you can navigate! Ask lots and lots of questions and get your pair to explain what’s going on to you. You will learn so much!
Remember: Design pairing is for doing styling fixes only — nothing that conveys meaning.
The pairing sessions should only ever be for styling fixes — if there is something visual that is also conveying meaning, it should never be left behind to be fixed in a pairing session.
For example, a timeline. Without the line-through-the-dots styling, the meaning is lost. This isn’t a good thing to leave for a dev-design pairing session.
But — if the meaning is conveyed in the built version, but the styling is just a little off for the designer to be happy — then it’s a good one to leave to fix when you pair.
Equipment you’ll need
A pairing station is ideal. What that looks like is a desk for two and two monitors (one machine) set to mirror screens. Two mouses, two keyboards. How to set up a pairing station >
The only other thing you’ll need is an attitude of sharing and a willingness to learn. It’s not hard. And you’ll see results — better collaboration within your team, empathy between designers and developers, and a better looking product overall. What’s not to love?
How do you handle fixing design tweaks and visual polish? Do you have any tips to share on pairing? Let me know!
