This is part 1 of a 2-part blogstravaganza. After you consume this post eagerly, you are instructed to devour the words and sentiment of Rene Rubalcava in Part 2.

…

If you are a designer, graphic or UX or otherwise, the opportunity to collaborate with a for-realz developer on an idea rules! Embrace the fun and awesomeness of that opportunity. We need each other. Wonder twins.

For example, I’ve relished working with Jinnan Zhang, a remarkable developer here at Esri. We’ve collaborated on several official and plenty of unofficial projects over the past couple years and had a lot of fun. Getting to meet minds with other makers like this is a thrill. And I’ve noticed a handful of sentiments over the years that help keep these relationships positive and productive. Most of these really have to do with smaller 2-person hi-jinks. If you are part of a much bigger project with lots of specific players, of course it’s a different dynamic. But still, the overall sentiment of these should hold up.

Here are five tips for designers to keep in mind when working with developers…

1. Whiteboard Fiercely

I mean, of course communication is the biggest deal in any collaboration. But especially when two potentially very different brains are meeting to smash out some ideas and form a plan you need lots of talking, ample hand-waving, and heaps of whiteboarding. I try to start with the overall concept, purpose, and audience. Only then do we start boxing out components of the plan.

This sort of iterative drawing will help you gain empathy for the technical challenges involved around a workflow, and will help the developer picture a workflow that is not a reflection of the underlying technical architecture.

Take pictures of the whiteboard and email it to yourself and the dev. Real high-tech. You think you’ll remember what you talked about because it’s so clear and fresh, but you will forget. And how.

Every once in a while you might have to have more conversations and whiteboard blasting. Each time will be more specific as your two understandings fall into a tight binary orbit. Take more pictures.

2. Respect Effort Estimates

In another life I was sitting in a project planning meeting when the customer asked an architect if they could see any “unforeseen obstacles” in the project.  There was a bit of a pause and then some sort of polite answer. But I think of it every now and then as an accidental example of the strain that developers are under. They are being asked to conjure something from logic and pixels.

Often, things that may seem trivial to a designer are actually mega hard. You have to believe the developer when they tell you something is actually inordinately difficult. You’ve probably heard a thing bandied about called the “80-20 rule.” If some non-critical feature is going to hog the lion’s share of effort,be willing to shelve it or think of alternatives…or if you have a pretty solid relationship with the dev you can suggest a potential workaround (sometimes a non-practiced perspective can provide novel approaches). In any case, accept what they tell you when you ask for an effort swag. And also be ready to accept “I don’t know yet.”

3. Be Specific

Each of you will have pre-conceived notions of what the workflow could/should be and it can be amazing how conversations that end in agreement result in people still walking away with very different ideas. Mockups are good. Mockups are great. Pictures are rigid rails that quickly align your, and the developer’s, understanding—then you can handle the twists and turns together. Don’t be that person that makes the developer also pretty much design the app only to then give a million rounds of feedback. Plus, where’s the fun in that?

So you send over (after your whiteboard storms) high-fidelity mockups, mocks that look like snapshots of the actual app in various states. Cool. But also provide details about colors, fonts, line thicknesses, margins, etc. What’s more, if your project is a web app, once your dev partner gets a prototype rolling in the browser you can tweak it with the property inspector in a follow-up phase. Then all you have to do is copy the recommended changes. Nice and paste-able. Also, you know it’s doable because you, like, did it.

4. Avoid the Poison

Sometimes there can grow in a designer-developer relationship a lack of trust or some resentment. It almost always has to do with a perceived lack of respect for the others’ role. We’re all human. I’ve been through some of this in the distant past so here are a couple things to look out for…

A request from a designer is easy, but delivering on the request may be exceedingly difficult. Try to honor the developer’s potential effort and couch ideas and requests with that understanding (sort of a preamble to #2).

Sometimes a developer has a favorite technology or library and will steer any project through that, even if it’s clearly a poor fit. It’s natural I suppose, but definitely not ideal; be on the lookout for that and ask questions early if you detect it. As an empathy-builder, consider the various visual design trends you’ve clung to in the past. Your response to the developer can sound very similar to how you might talk your past self out of some design fad.

If a developer ends a conversation with, “it’s a technical issue” without really explaining it…that’s a really bad sign. If you hear it, pull a Michael Scott and ask them to explain it as though you were an eight year old, and, failing that, a five year old.

But the best way to avoid the poison? If a dev collaborator makes something awesome, tell them! Don’t hold back on honoring their work. Be Excellent to each other. Who doesn’t like to hear that their stuff is cool?

5. Let it Flow

Avoid strict divisions of labor and the feelings of home-turf that come with that. Developers can have awesome design ideas, and designers can provide technical insights. A healthy working relationship will respect the expertise of the other, but also welcomes the occasional blurring of roles as an exciting…synergy (there has to be a better word, right?).

Projects, even simple ones, are actually pretty complex things. So with a mutual respect for each other’s task, be open to a project resulting in something quite different than either of you imagined in your earliest inklings. Designers and developers bring different and wonderful skills to a project and apps that have the fingerprint of both minds singularly working for the good of the end-user will be more successful.

…

So anyway, that’s a hopefully-handy little list of recommendations that you can take for whatever it’s worth. There are probably other, better, bits of advice that I’ve missed, but these are the ones that drifted down to me from the fickle muse flying about. Feel free to chime in with your own advice. In the meantime, designers, go forth with your fellow makers and do good things! Now head over to the developer-centric follow-up where Rene Rubalcava gives our code-slinging allies advice on how to deal with us!

Happy Collaborating! John