Hi Jonathon, 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 (IMO) to work together than what was presented. -ambrose On Fri, Apr 24, 2009 at 4:02 AM, Jonathon Juvenal <[email protected]>wrote: > 1. Be a developer > > When you can follow along and contribute intelligently > to all the technology discussions, the developers will start to trust > you that you understand them. Yes, it's only fair if you expect them to speak your language and share your concerns that you make an effort to do the same. > Let alone the fact that you will be able > to call them out on their bullshit, and yes they bullshit a lot. > This is a sad fact caused by the lack of empathy on both sides. If you understand what the pain is, you will be more sympathetic, and they won't feel the need to BS so much. > 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. If you think that (at least some) devs don't also understand this, you're mistaken. And again, it is wrong-headed; good teams are not about power struggles. > 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. If the design is good, then it speaks for itself--shouldn't need the power/authority to back it up. At that point, the goal is to work with the devs on the feasibility aspects and try to come to the best possible solution given all concerns. Bill Buxton talks about the 3 pillars of business, tech, and design. They need to work together to make the best solutions, not against each other. There will be inevitable conflicts from competing concerns, and the best solution is to not try to force one perspective down the others' throats but work towards a compromise that is best for everyone. > 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. > Devs vary widely in their taste for interacting with stakeholders, but it is best if at least the architect/lead devs be involved and are speaking the same language. And if they are, the three pillars can work together and avoid unnecessary and unproductive power struggles. > > 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. > This is by far the most positive thing said so far. But the motivation of tit-for-tat is questionable. Surely it is true, but if you have that underlying motive when you help them out, it is likely not going to go as far towards building a good team--trust is not built upon ulterior motives. > 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. This is without a doubt true--no one likes to feel like they've wasted effort. This is a pain point for designers as well, from what I've gathered, though they are more welcoming of it as part of the design discovery process. Generally speaking, the less investment you have the more willing you are to change it, which is of course the motive behind keeping things lo-tech and lo-fi especially early on in design. This does, of course, take convincing, not only of the business but of devs, especially if they've found success with Agile. I think you'll often have to sort of incrementally work backwards on this one and prove the value of doing more design up front--there's a lot of baggage from failed BDUF you'll have to overcome. > 5. No one gives a rip what the artist thinks > True, but as you point out later, if you learn to communicate the Design perspective, you'll probably end up doing better design yourself as well as help them to be more sympathetic to your Design concerns. It's not not caring what you think but rather not being willing to just drop their own concerns just because you say so. > 6. But you do get to do what you want > > most developers don't want to think about the details, so you get to! It's important to specify which details. Business folks and devs have their own details that they are concerned with. Very few people can successfully juggle all the details, so they have to (or maybe just prefer) to focus on the details they feel are more important and/or are more within their expertise. > 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. "Pet.." - this comes across as very condescending. And the message here comes across, again, as manipulative. Not conducive to good teams. > 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. Wow. Again, the verbiage here is chock full of wrong-headed, power struggle-oriented thinking. The better way is to get everyone on the team on board with the vision of building something great, and agree, as best you can, what that means. > 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. It starts good--helping other team members by providing what they need, and then dives down into what appears to be manipulative ("secret" to get them to do what you want). > 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. You contradict yourself directly here. "devs don't like HTML" then "hire a UI dev to do it." There are something like 7 million devs in the world, so any generalization should be met with skepticism. I know just as many devs who are nitpicky about HTML as not. It usually depends on their experience, but these days, the trend is towards caring more than not. But yeah, on larger teams/projects, you often have distinctions between front-end devs and back-end devs. The back-end ones tend to not care much about the UI in general, much less HTML, specifically. > In the web world this is called a Web Designer. Not from what I've seen. Web designers more often come from a design (often visual design) background and pick up what coding they need to make their stuff come alive. But there are certainly folks who come at it from the other direction. But if they're a real "dev," they do more than scripting and also have to think about plugging in the design into the back end, which I would say very few Web designers can or want to do. I wouldn't call this person a "middle man" but maybe an "integrator" if you have to generalize. Front-end dev or UI dev is probably a better descriptor. > 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?). Is it just me or is this a wacky application of 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. > This is really good. Co-location and "hot" communication is strongly advocated in Agile as well (and has been proven). Unfortunately, it's not the reality for many people in our increasingly globalized world, so working on remote communication skills is important too. You're certainly not screwed if you can be co-located; you just have to work harder at communication. > 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? This is great. I honestly wonder though how you can be a friend and yet be so (apparently) manipulative. I mean, maybe you totally don't mean to come across that way and aren't that way, but just reading what you wrote here, that's how it comes across to me... > 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. This is something I've been thinking about more lately. I wonder if we just don't have the right language for it or have too many connotations for things like "intuition" and "subjective" and "creative" and "right-brained." I'm optimistic that we can and should continue to develop our ability to communicate about what makes good design and what doesn't. It should be something you can explain. It's not about subjecting one form of thinking to another. Reason is broader than just logic. It should be something that with reasonable effort--without having to attend formal design school or take more years to learn in the wild--you can establish a common language with the other pillars to collaboratively come to the best solution possible. > 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. I share your optimism and belief that design can be communicated. I think, though, that we shouldn't require everyone to make the effort you describe to learn to do so because communication is two-way. The language has to be shared and understood by non-designers for it to be effective in making design a better understood and valued discipline on product/project teams. > 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. True and pretty well put. > Developers are incapable of this because of the > very fact that their job is to speak computer. *sigh* there you go again.. it has very little to do with capability. It has far more to do with experience and interest. Developers are specialized in talking to computers. This does not mean they can't (or even don't want) to speak human. Are designers incapable of learning to develop? > Your job then is to > force the programmers to make the computer to do something it was not > meant to do. Your job is not to force anyone to do anything, IMO. Your job is to work together with them to come up with the best possible solution given all of the constraints--business, technical, and design. > That will always mean that have to personally generate an > incredible amount of extraneous code, blood, sweat and tears, > everything they hate. I have found devs to be far more patient with minutiae and more willing to spill blood sweat and tears than many others on the various teams I've worked on. As you note above, there is a lot of work to get the computer to do neat stuff, and they thrive on that--it's why they're devs. They don't hate it.. > 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. I guess this was meant sort of tongue in cheek. ? Maybe not. Anyways, a more accurate statement, as I see it, would be that your job is to try to make the best design given all the constraints, even if it sometimes means pain for the developers. Your job is to work with them, not against them. Your job is to collaborate, not control. I would also say that good design is not always inimical to development. In fact, in recent years, more and more effort has been put into making frameworks, tools, and technologies that make good design more feasible. I see this trend as really only having just begun and continuing. We also have a growing body of knowledge around patterns, which pertain a lot to good design and help perpetuate and enhance it. Surely, there will always be custom (not extraneous) effort to make even the best tools produce good design, tailored to particular contexts. But that's what makes what we do interesting and challenging. Devs talk about "boilerplate" code; this is all the "grunt work" and foundational stuff that they have to do. That's what they don't like. They thrive on the custom, interesting challenges that show up on each project. So in that sense, you're not making their lives difficult but rather more interesting. They enjoy new challenges as much as any designer.. What they don't like is being condescended to. They don't like being manipulated. They don't like (as you identified) rework--even if they recognize the value of the change, there's still a sense of wasted effort and wistfulness that they would have been given the right thing to build first (that's where some conflict can come from). They don't like reading tomes and tomes of specifications, even good ones. They appreciate good design, even though they may not have had as much exposure to it or have thought about what makes it in terms of human/user experience. They do a lot of design themselves, a lot of which involves lots of creativity and judgment calls between competing concerns. They can abstract aesthetics more than most people can (probably including the "average" designer), and like most people, they do have some concrete aesthetic sense, too. They're not complete dullards, and I'll wager if you listen to them, they'll help you find flaws in your own designs more and more, especially the more they work with good designers and become more sensitized to those issues. And in all this, remember that we are generalizing very broadly. My generalizations come from having been a developer for many years professionally and being (real) friends with many and meeting many at many different conferences, user groups, and professional associations. And yet I know that even I have not been exposed to all the various "types" of developers out there, much less accounting for the fact that we are all individuals with our own lived experiences and preferences. > 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. Ack! > Your job as a designer > is to deal with this fact and somehow still get those developers to > produce something human beings enjoy using. > Ack and ack again! > What do you think? What have you found to be effective? > See above. Main takeaways--work together as respectful peers; try to communicate as best you can; use your designer empathy with them, too. You asked. :-p -ambrose ________________________________________________________________ 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
