In 2014, I was invited to speak at Alt Conf in San Francisco and at UX open in Stockholm. I shared my ideas on how designers and developers can work together and get along better, based on what I learned in 5 years of working with many different digital product teams. This is a revised and improved write-up of those talks.

Share a room

Sit next to each other – rather than in separate rooms, floors or buildings. Hang out in a shared #product Slack channel – rather than separate dev and design silos.

Over time, this physical or virtual nearness will let your team collaborate continuously (not once a week) and build a shared understanding of where your product is at and where you are going.

Minimize hand-offs

Get comfortable sharing non-“final” work. Nothing is ever final. We’re building apps, not a railway bridge or some interstellar probe (those are harder to change afterwards).

As a designer, your job is to provide the developer with enough detail so that she can start building in the right direction. It’s also helpful to predict in what ways the product might change in the future: e.g. “We might allow multiple people to edit an article.”

As a developer, it’s your job to point out missing details and flaws in the design and ask for clarification. Everything else would be waterfall. You’re not a code monkey, and you’re not a spec-to-programming-language compiler. So appreciate when your designer doesn’t treat you like one :)

As a designer, it can be hard to strike a good balance between protecting a budding idea and getting feedback from non-designers. But the longer we wait before we share our ideas, the longer we spend not learning about what can be better.

Minimize external documentation

Documenting and tracking progress are sometimes necessary. More often than not, however, they are not a solution, but rather a symptom of project leads and/or clients not feeling in the loop of what’s happening in the trenches.

  • Why document decisions in multi-page wiki pages, when everyone was involved in arriving at the decision?
  • Why document every single change through JIRA tickets, when your Git repository not just already tracks every change, but actually is the definitive log of your changes?
  • Why keep track of assets in a ginormous multi-column wiki page that all too easily goes stale and out of sync with the truth?

The closer you and your team work on the product itself, the less you will need to document changes, decisions, and progress.

Share ownership of the end product

Really, what it boils down to, is: Own the end product, together. Be proud of what your team produces – not your individual contributions. A user does not care about your perfectly laid out Sketch file, or that your code is beautifully clever. A user cares about the end product. So you better do, too.

If you’re a developer and something feels off with the assets, transitions or wireframes, go challenge the designer. Maybe there were trade-offs and constraints involved that you didn’t know about – or maybe you just struck a weak point of the design and now have challenged the designer to come up with something better.

If you’re a designer and you aren’t happy with how your developers have implemented your designs, go explain to them why it’s important that the title gets more breathing space (visual hierarchy, gestalt laws) or why the animation needs to be eased in and out (skeuomorphism, laws of physics).

Such a working relationship built on mutual trust and respect is actually how I got into UX design in the first place. When we were building our first three iPad apps in early 2010, running against the tight deadline imposed by the imminent iPad release, I – the iOS app developer – was constantly critiquing and challenging our designer’s concepts and visuals.

I learned a lot about the craft of design by listening to him explain his decisions. And sometimes I poked holes into them, unwittingly driving him to work long nights – because he grudgingly agreed there was something amiss with his design and had the ambition and work ethos to make it better. We pushed each other to make a better end product.

In an interesting twist, Derk and I have since switched roles: he now codes Swift, and I do UX design for my clients. It should be interesting to work on something together once again, in reversed roles! It doesn’t really matter though who does what, because in the end, for both of us, it’s about making the best product we possibly can.