I currently work at a very small company, less then 20.  But compared to the other stories I’ve heard lately from interaction designers like myself, our company gets surprisingly consistent results from our developers in regards to design.  Following are 12 lessons I’ve learned that have helped me get better results from our in-house developers.

1. Be a developer

I can’t stress this one enough.  Development isn’t something that can be appreciated, it has to be experienced.  HTML and JavaScript don’t cut it, you have to go out and actually do what your programmers do.  Write SQL statements, create classes, build an application.  When you can follow along and contribute intelligently to all the technology discussions, developers will start to trust you that you understand them and what they have to deal with.  And most importantly you can help them find solutions they may not see yet.

2. Get in bed with the business people

At the end of the day the business people run the company and they control what the developers do.  At my company I spend a great deal of time with our project manager, VP and CEO.  I try to develop personal relationships with them.  I make it obvious that my goal in life is to help them articulate what they want to the development team.  Then when I present something to the development team, it’s not my idea, it’s what the boss wants.  And in the end the developers are actually happy you managed all that back and forth discussions with the business guys so they don’t have to.

3. Ease their pain

Most developers just want to develop.  They don’t want to worry about requirements gathering, deadlines, art, research, politics and all the stuff that goes into running a project and a company.  So the more you take responsibility for all these things they don’t want to do, the more they will work with you and with what you ask them to do.  When they need something from you, do it fast and with a smile.  The more enjoyable you make their lives the more responsive they are going to be when you ask them to do things.

4. Force business to iterate in design, not in development

There’s nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else.  I won’t hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible.  There are many decisions that can be made off of drawings rather than programming it.  And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying expensive developers.

5. No one gives a rip what the artist thinks

Even though you were hired as the design expert you still have to earn everyone’s trust.  Too many business people and developers have had bad experiences with artists who think they know everything or who are overly emotional.  You typically have a steep hill to climb to affect things as much as you need to.  Design in a business is all about being the facilitator and assimilator, not the dictator.  Collaboration is the only way to get design done in business.  If the developer wants to design, let them!  Just be there to guide them rationally and fill in the gaps when they have to go back to developing.  If you need an artistic outlet, do it at home, or you’ll always be bitter.

6. You get to control those lovely details

Once you’ve checked your ego at the door, something amazing starts to happen.  The funny truth is most business guys and most developers don’t want to think about the details, so you get to!  Usually people on the team only end up really caring about particular features, no one wants to take all that time to think through the rest.  So as long as their desires are represented or addressed, you get to fill in the rest with what you know is best.

7. Write it down, write it down, write it down

The beautiful thing about writing is that it’s the universal standard for communication.  Yes a picture is worth a thousand words, but you cannot draw interactions as well as you can write them.  My documentation is a mix of what we call “scripts” with supporting graphics at key points.  My friend is an html guru at a large company and his biggest complaint is that he gets handed a large Photoshop file with no documentation or annotations that are difficult to understand as a whole.  Writing can be difficult for designers, but it is incredibly effective at communicating the interaction to the rest of the team.

8. Get in bed with the QA team

The QA team is the group of people whose job it is to tell the developers they did it wrong, they are your design enforcers.  The better they understand what you wanted from the developers the better they are going to be at helping keep the developers on design.  It’s critical QA has the right kind of documentation to do their job, and you want to be in charge of that documentation.  The cool little secret about QA is that they like checklists.  I write my documents so that they are essentially checklists that the QA team can easily translate into test cases.

9. You have to have a middle man

In my experience developers do not like to do HTML.  There is a rare breed of developers in the web world called web designers who like to do this kind of GUI development.  But on the whole, GUI is too much of a mental stretch for developers who live in the abstract inner workings of business logic.  As much as developers may think HTML is easy or even beneath them, HTML takes just as much concentration as does any other kind of development.  In my experience the very best scenario is to hire a GUI developer to be the middle man between the designer and the developer.  A GUI developer is someone who cares about the visual details, but they can also code.  If you don’t get this guy you’ll always be fighting a losing battle with developers because they don’t want to do HTML.  They’ll end up butchering the designs simply because their interest is in business logic and such.

10. Proximity breeds understanding

There is a direct correlation to your physical distance from the developers and how effective you will be with them.  Currently I sit right next to my developers.  I hear everything they say, I’m accessible, we go to lunch, and I know what they are doing and saying.  If you hide in an office or work off site, you’ll have to spend a lot more time forcing collaboration to occur.

This one should be obvious, but there’s a basic rule that the more time you spend with someone the better you are going to be able to interact with them.  Be friends with the developers, kick their ass in Team Fortress, go to lunch, carpool, whatever it takes.  Get in their face and take as much time to figure them out as you do figuring out your customers.  Have you spent enough time with Derron to understand why he is such a grumpy loveable prick?

11. Learn to articulate well

This is where studying design comes into play.  Design is difficult to communicate verbally, it’s naturally an intuition and a feeling thing.  But the reality is no one is just going to trust your feelings without good logic behind it.  So you have to learn to verbally articulate your feelings.  The good news is there is actually logic and reason to art, but the bad news is it’s one of the most complicated things on the planet.  It’s complicated simply because of the fact that it’s based on the brain, which we understand very little about.  Computers on the other hand we understand very deeply.  Learning to verbally articulate design takes time, you have to take time to study it.  Study how other designers talk, learn patterns and read design literature like a mad man. Over time you’ll start to surprise yourself how well you can explain why you made the design decisions you did.

12. Good design is always hard to program

I finally realized this after being a developer and then a designer.  Your job as a designer is to get the computer to act more human and to be more understanding of human communication.  A developer’s job is to make a computer more like a computer, logical and efficient.  I came to the conclusion that there will always be a conflict between a designer and a developer because designers speak human and developers speak computer.  Your job is to make the computer do things it was not built to do.

Image: Yourdon