IMG_0227.JPG

Written

The blog I've always dreamed of writing, written.

On Working with Developers

Were I to sit down a designer and a developer, and speak to them as if I were sharing my own expectations, it might sound like this:

1 - Respect each other

You’re both professionals and have lots of experience in areas the other may know little about. If you have respect for yourself, then start by treating others the same.  Your time is no more or less valuable than the other persons, and you both are coming to the table with expectations. Make it your mission to understand the other person’s notions about what’s good/bad, right/wrong and what your shared goals are for the project.

Even if you’re having the worst day possible, and nothing is going remotely as expected, remember that design and development are symbiotic.  You need each other to get the job done and are likely to both be accountable for delivery.  Make sure you’re working together towards the same end.  It’s ok to give your counterpart a free pass once in a while for behaving badly. Remember what Sandra Boynton says:

...a difficult mood is not here to stay. Everyone’s moods will change day to day. (Except for the duck....

2 - Ask questions in earnest

If you don’t understand something, ask about it. You do not show weakness by claiming ignorance. Asking sincere questions show vulnerability which builds trust.

These are all fair questions:

  • What does React.js do?
  • How hard is it to build this?
  • Is there a different way to setup these pages?
  • Can we make it a link instead of a button?
  • Why does it look different here than over there?
  • What was missing when you started this?
  • How do you see this helping us meet the goal?

I have asked and been asked all these questions in various forms.  See point one if you are considering, (or facing someone else) reacting defensively.

There are appropriate times and places for these questions.  Be prepared for resistance if you don’t have the experience to know which question is best asked when.  Consider leading questions in this category with the obvious, “I’m not sure if this question is helpful at this time, but can you help me understabd ...” If you’re certain it’s a flow-derailing question, then save if for after the group meeting, and appeal to the expertise of your counterpart and ask your questions in private.

3 - Own your inputs

We all have needs when it comes to our respective roles and responsibilities. Each of us is responsible for obtaining the input necessary to deliver on our promises to our manager.  If you fail to secure the copy from the editor, it’s not the editor who screwed up - it’s you.  Most people don’t understand this.  Don’t be most people.

As a developer, you’re accountable for writing code that implements some software component. To write that code, you’re going to leverage your considerable talent and skill in making sure the code meets quality standards, is thoroughly tested and that it gets the job done that the software application is designed to do.  You had better understand the goal of that application without a shred of doubt.  You build the wrong thing, it’s on you.

Owning the inputs means saying, “I can’t do my job without X” and then taking the next step to make sure that you get X. If you don’t do both parts, you fail.

4 - Speak to your audience

As a designer, you’re responsible for helping the business solve their problem, and to the user to provide a compelling and useful experience. You have two masters... but wait, there’s more! You also own the delivery of guidance and clarity to whoever is taking your design and making it available to the users.  Your true audience isn’t the user, it’s the internal team who’s writing the code.  Your job is to speak their language and communicate effectively against their needs and expectations.

Be a good communicator. Learn what your audience is really looking for from you, and speak in a way that they get the message (not in whatever method happens to be most comfortable for you).  Communication happens when the audience gets the message. Your communication fails if you can’t speak the language of your audience. It’s not their responsibility to learn your incomprehensible jargon.

Originally published May 6, 2016