Overall, I think you have some valuable insights, but the way you express them belies what I think is a wrongheaded approach to interacting with devs. The subject line as well as numerous things in the text imply a goal of manipulating and controlling and conflicting (and even condescending) with devs, which I think is not the best way to create an effective team. More inline. My reason for taking the time to respond in depth is in the hopes of creating more empathy and a better way [trim] Ambrose,So is this something that can be captured?
Right on the mark.The "us" vs. "them" attitude never works. We're all in this together.
I think the methodology has to really capture this aspect, but as said further down in the thread
Much of this assumes you are all working to the same objectives towards something better. Often teams don't and that's where the problem lies.
The full post below 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 worked with.
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, 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 bitter.
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 QA 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 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 prick?
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 win.
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?
