This is exactly to the tee what an Interactive Producer does.
On Apr 24, 2009, at 8:02 AM, Jonathon Juvenal wrote:
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.
________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
