12 Lessons Learned for Getting Better Results from Developers

How to work together with developers

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

Jonathon Juvenal

Sr. Interaction Designer at OneGreatFamily.com, a small internet genealogy company in Springville, UT, USA.

49 comments on this article

  1. Ralph on

    Cool article, but the ending was really butchered.

  2. Good reading 🙂

    Questions –

    * How are both roles (design and development) rewarded?
    * Is it towards the same success, goals or end point?
    * Is it different? How does this impact the end product?


  3. As a developer, I can say that you’ve pretty much nailed it. However, I would recommend taking all of these tips with a grain of salt – They may not always be accurate with your specific circumstances.

    In the end, I think it boils down to this: Developers want to do what they do best and usually enjoy most – Writing code – and if they need to interpret how you want things done, it takes time away from writing code.

    My advice: Ask the developers what they think. They may often have some ideas on how you can improve design mock ups etc. to make it easier for them to work with.

  4. Thanks @Ralph, it’s been amended.

    @Daniel, if I understand your questions correctly my answer would be along these lines. Design and Development would be rewarded for accomplishing the same business goal since it takes both to achieve anything business wants done. It affects the end product by creating a new feature or service that wasn’t there for the customer beforehand.

    @Jani, thanks! I’m glad to hear a developer feels I nailed it. I agree it depends a lot on your unique situation, these are just what work for me in Springville, Utah, USA. Utah has some very unique challenges in personnel and environment that led me to these 12 ideas.

  5. Hi Jonathon:

    Thanks 🙂

    That’s right and be interested in what helps you make this happen? Where people are aligned (independent of role) on what needs to be achieved from a business and product strategy perspective. Where it becomes less about an individuals skill set and more about the end piece you are all aiming for.

    What differentiates average teams to great teams that deliver great products?


  6. Thnx for this good article. The first part is the most difficult for somebody coming from the design section. I don’t think in numbers and logics. I try to solve problems. How they are solved in the background, is not in my view. What really helps here is the instant communication with the developer. Show things early. Discuss it. Learn from it. So in my eyes the most important lesson is: Communicate. Fast. Often.

  7. Pingback: 12 Lessons Learned for Getting Better Results from Developers « My User Experience Story

  8. Pingback: Chance Bliss » Blog Archive » Managing Web Development - Get thee to a knavery

  9. “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.”

    If this is true of the developers you work with, it’s time to find a new company.

  10. As a designer who manages developers, I find that this was a very good read. I feel like it was from a perspective of someone who is used to working with larger teams, so you have to apply the advice to your scenario.

    Richard – you have a point, but I assume you are working with a small team…not a large development group.

  11. Interesting article. Do you use Agile methods? And are your projects client based or internal?

  12. Pingback: Wayne State Web Communications Blog » Blog Archive » [Friday Links] The 2010 Edition

  13. @Tamim Well said. It does come down to communicating often. Programming is more about numbers and logic, you’re right. But any time you can spend using the materials you are designing for your designs will always be better.

    @Richard, sadly it is the case where I live that most of the developers just want to develop. It is a wonderful day when I get to work with the few who think beyond just coding.

    @Robi, thanks! Currently I support two dev teams, 5 each.

    @Robin, we do use Agile, though it is our own unique flavor of it. The projects are all internal based. Either marketing campaigns or new features for our subscription based website.

  14. Pingback: Design e Sviluppo: conoscere il conflitto - Alberto Mucignat

  15. Name Wiffheld on

    How about this advice: Stop sucking everyone’s dick and form your own company. Then do things the right way. Until then, you’re just another whiny, complaining schmuck.

  16. European developer on

    Most of your points are good. But I sense a kind of attitude where you only interact with developers regarding the implementation of your design. I think you will get even better results if you talk with them. These are the people who have spent a lot of hours on the application, and will know of ways to improve it. With a developer you get someone who can not only use an application (QA) but also actually know what is possible.

    I am someone who likes to dig down in the system and develop (Java), but I also like HTML/Javascript/CSS/PHP. Luckily I can do both in my job, because we are organized around projects and not job titles.

  17. Pingback: Johnny Holland – It’s all about interaction » Blog Archive » 12 Lessons Learned for Getting Better Results from Developers « Netcrema – creme de la social news via digg + delicious + stumpleupon + reddit

  18. Pingback: Johnny Holland – It’s all about interaction » Blog Archive » 12 Lessons Learned for Getting Better Results from Developers : Popular Links : eConsultant

  19. Pingback: 12 Lessons Learned for Getting Better Results from Developers » Web Design

  20. Kev on

    I have a problem with the phrases “Get into bed with the QA team” and “Get in bed with the business people.” Not every reader will understand the English idiom (taken literally it’s horrible advice!) but even those that do may find it archaic and perhaps offensive. There are better choices.

  21. Pingback: My daily readings 02/01/2010 « Strange Kite

  22. Pingback: jani hartikainen

  23. Pingback: Time Lapse – 3 Hours In My Cubicle at Work Shurnk Into 1.5 MinutesSpeedAndroid | SpeedAndroid

  24. Pingback: congnghethongtin.in » Blog Archive » Jogging couple

  25. Pingback: Thinkin’ about the code | Droid User

  26. Pingback: How Congress’ tax-cut decision may affect economy | The Secret To Make Money

  27. Pingback: How Much Time Does It Take Version 2 - Awearon

  28. Pingback: Nice Affiliate Internet Marketing Super photos | blog

  29. Pingback: Thinkin’ about the code | Blog Blog Baby

  30. Pingback: Online Custom Engraving Now Available for Men’s Jewelry and Accessories at Shimmer & Stone | Make Money Online

  31. Pingback: Thinkin’ about the code » hot spot

  32. Pingback: Don’t try this at home — or elsewhere! | makemoneywithclickbank

  33. Pingback: Latest How Make Money Internet News | how make money internet

  34. Pingback: Thinkin’ about the code | Vzooming

  35. Pingback: Cool How To Make Money On The Internet images | Money

  36. Pingback: Community groups gather grant money | SEO Marketing - Make money Online

  37. Pingback: Thinkin’ about the code - Article Hunter - Find the Latest Articles, News, Answers and Videos - Article Hunter

  38. Pingback: Women’s Embroidered Career Set by BBW Boutique in Plum – 4X-Large - Clothes for Woman

  39. Pingback: Thinkin’ about the code | microcontinuity.biz

  40. Pingback: Cool Secrets To Affiliate Marketing images | Affiliate Marketing

  41. Pingback: Airline, website won’t fix error in child’s name on plane ticket | Make Money Online Quick

  42. Pingback: Cool How To Make Money Online From Home images | Coach Craig

  43. Pingback: Thinkin’ about the code | Macbook Lover

  44. Pingback: Cool Computer Affiliate Program images | Free Articles

  45. Pingback: Internet marketing strategies - The Best Venue To Learn Internet Marketing

  46. Pingback: Thinkin’ about the code | Talk About Computer

  47. Pingback: Thinkin’ about the code | Recession-Proof-Home-Business

  48. Pingback: Thinkin’ about the code | customfieldswordpress.info

  49. Pingback: Cool Making Money From Home images | Wealth-Making-Secret