How to get better results from developers
Earlier this week at the local Utah IxDA meeting and over the last
while at various places I've heard the topic of how to deal with
developers come up. I was thinking about it and realized I had a lot
to say about it. Sorry for the length :)
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 in Utah, our company gets surprisingly consistent results
from our developers in regards to design. Following are my 13 lessons
that have helped me get better results from the developers I've
1. Be a developer
I can't stress this one enough. Development isn't something that
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, the developers will start to trust
you that you understand them. Let alone the fact that you will be able
to call them out on their bullshit, and yes they bullshit a lot.
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, this
is what the boss wants so you better get it right. There is nothing
more powerful then presenting a finished interaction document to
development and saying that this is 100% approved by the CEO. And in
the end the developers are actually happy you managed all that back
and forth crap with the business guys so they don't have to.
3. Ease their pain
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 reliant they will become on you. 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 within the time I was
given. 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 those expensive developers.
5. No one gives a rip what the artist thinks
The irony is they hired you to be the design expert, but they never
listen to what you say. And guess what, they never will. You have to
get over the illusion that they will do what you say because you know
better, it doesn't happen. To be happy you have to accept the fact
that you will never get to design what you want. Instead you have to
learn to enjoy the reality that you are there to facilitate and
assimilate everyone else's ideas into a single coherent whole. If
you need an artistic outlet, do it at home, or you'll always be
6. But you do get to do what you want
Once you've checked what you want 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!
Other people on the team only care about their pet features, no one
wants to take all that time to think through the rest. So as long as
their pet issues are represented, you get to fill in the rest with
whatever you want.
7. Write it down!
The beautiful thing about writing is 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 "stories" with supporting graphics at key
points. My friend is an html guy at a large company and his biggest
complaint is that he gets handed a large photoshop file with no
documentation. Somehow he is supposed to read the mind of the of the
designer to figure out what actually happens in ui when the user
interacts with it. The designer has failed to communicate the
interaction. Writing is a royal pain in the ass, but it is incredibly
effective at communicating the interaction to the developers and the
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 enforcers. The better
they understand what you wanted from the developers the better they
are going to be at telling the developers what they did wrong. 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 say, hey
dev, item 3.i.b is wrong, fix it.
9. You have to have a middle man
Developers do not like to do HTML. It's a fact of life that will
never change. As much as they think HTML is easy, it takes just as
much concentration to do HTML as it does any other kind of
development. In my experience the very best scenario is to hire a UI
developer to be the middle man. In the web world this is called a Web
Designer. A Web Designer 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 the developers because they
don't want to do HTML, they don't give a rip about visual details
and you don't have the time to program the HTML either.
10. Sit next to them
There is a direct correlation to your physical distance from the
developers and how effective you will be with them (remember Fitts'
Law?). Currently I sit right next to my developers. I hear everything
they say, I'm accessible, we go to lunch, I know what they are doing
and saying. If you hide in an office or work off site, you're
screwed plain and simple.
11. Spend time with them
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. Do you even known your developer's names? Have you
spent enough time with Derron to understand why he is such a grumpy
12. Learn to articulate well
This is where studying design comes into play. Design is difficult to
communicate verbally, it's naturally an intuition and feeling thing.
But the cold hard fact is no one is going to trust your feelings,
people will always want reason and logic to make decisions. So you
have to learn to verbally articulate your feelings. The good news is
there actually is logic and reason to art, but the bad news is it's
one of the most complicated things on this planet. Learning to
verbally articulate design takes time, there's no way around it. You
simply have to study it. Study how other designers talk, learn
patterns and read design literature like a mad man. And what will
start to happen is you'll actually be able to argue for a design and
13. Good design is always hard to program
I finally realized this universal truth. What makes sense to a
computer does not make sense to a human being. It takes a lot of hard
work to get a computer to speak human. This is what you are trying to
do as a designer. Developers are incapable of this because of the
very fact that their job is to speak computer. Your job then is to
force the programmers to make the computer to do something it was not
meant to do. That will always mean that have to personally generate an
incredible amount of extraneous code, blood, sweat and tears,
everything they hate. This is why there will always be an eternal
conflict between developers and designers, because your job is to
make their life difficult, plain and simple.
That about sums up what I've learned so far. I hope this is helpful
in some way. The painful truth is that design is a pain in the ass,
and getting developers to do what's right for the users is like
standing against a raging river. It's not natural for developers to
do good design, it goes against their nature. Your job as a designer
is to deal with this fact and somehow still get those developers to
produce something human beings enjoy using.
What do you think? What have you found to be effective?
- What are the "main" differences between getting a degree (e.g., MI) from an "iSchool" vs. an getting an MDes or MFA from an IxD specific program? And which would be better for someone with a humanities background?
- Solar Power systems: Is it possible to get fully funded processes? And if so - how?
- How to Get Useful Feedback from Customer Support?
- From Application To Interview: How To Get A Great UX Job -- Slideshare Presentation of the Day
- Just how Much To Weight management Pills Price? Proactol? Can I Get It At Shoppers Medicine Mart? (Canada)?