How to get better results from developers

24 Apr 2009 - 10:02am
5 years ago
11 replies
1317 reads
Jonathon Juvenal
2009

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?

Comments

24 Apr 2009 - 11:24am
Sharon Greenfield5
2008

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.
>

24 Apr 2009 - 1:28pm
ambroselittle
2008

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 <jjuvenal at yahoo.com>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

24 Apr 2009 - 3:51pm
Jared M. Spool
2003

On Apr 24, 2009, at 11:28 AM, J. Ambrose Little wrote:

> 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,

Right on the mark.

The "us" vs. "them" attitude never works. We're all in this together.

Jared

24 Apr 2009 - 4:07pm
Jack L. Moffett
2005

Yes, thanks Ambrose. I was keeping that message to reply to later when
I had time. You've saved me the effort. :)

Best,
Jack

On Apr 24, 2009, at 4:51 PM, Jared Spool wrote:

> Ambrose,
>
> Right on the mark.
>
> The "us" vs. "them" attitude never works. We're all in this together.
>
> Jared

Jack L. Moffett
Senior Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

Questions about whether design
is necessary or affordable
are quite beside the point:
design is inevitable.

The alternative to good design
is bad design, not no design at all.

- Douglas Martin

24 Apr 2009 - 4:31pm
dirtandrust
2008

I love this post! It's very pertinent to what the design team I'm on
is dealing with, particularly communicating requirements to
developers.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41485

24 Apr 2009 - 3:01pm
Jonathon Juvenal
2009

This is fantastic feedback Ambrose, thank you :) Your responses are a
much more appropriate and thoughtful way of explaining what I was
discussing. I was definitely trying to be more tongue in cheek
because I wanted to make the writing interesting to read.
Manipulative and controlling is not how I interact in practice. Keep
in mind too that a lot of my experience has been at places where the
devs are not as you describe though. I look forward to the day when
I can work with more mature developers as you've described them, I
know they exist. I think the caliber of developer has a lot to do
with location.

I meant this article to be somewhat sensationalized, if I were to
make it more appropriate for an academic journal I would definitely
take out all the generalizing and wrongheadedness as you pointed out.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41485

24 Apr 2009 - 6:18pm
Dustin Savery
2009

I love the post too! I think that it holds a lot of merit.

In response to your comments, Ambrose, I would agree with you IF
everything was in an ideal workplace and all developers were team
players rather than looking out for their own self-interests. Good
design usually means more work for them, and thus they usually fight
those sort of things. That is why I would have to agree with Jonathon
about needing to be a bit...forceful.

I am currently in a situation where I am designing an application and
presenting those designs and interactions to the "project managers"
who are also developers on the same project. A great deal of the
interactions that are fairly common amongst good IxD have been
slashed because "it's too hard". If I were in a position to tell
them what we are doing rather than ask, they might fight a little,
but then take the documents and get to work.

Don't get me wrong, I'm not saying be condescending or belittling
to the developers, and I'm all for a team, but the reality is, in
the trenches of design in MOST companies, it's a little more tricky.

- Dustin Savery

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41485

25 Apr 2009 - 9:58am
Mattias Konradsson
2008

Good post! This is something I've been pondering myself. I see myself as a
designer who programs (since there arent any programmers that can design
;) and the benefits of being well-versed in both the design and actual
implementation have been tremendous. I've worked with many programmers who
think they can design and while they show various adeptitude in designing
interfaces it's very rare to find anyone delving deeper into the interaction
issuesss. Thinking about what kind of problems the user *really* want to
solve and thinking about personas rather than "the user". This often leads
to spending lots of time and energy solving the wrong problem, things like
designing a form rather than questioning if the form is necessary.
Programmers also have a tendancy to underestimate the importance of the
minor details and overestimating the users (they can be really "stupid"
sometimes)

Designers on the other hand suffer from their lack of technical expertise.
Advanced algoritms, controls and a deep knowledge of the underlying data and
systems can be a great inspiration for features and interfaces that are
truly useful. If you're not aware of the controls existence or what data
there is you'll never get there. Another important factor is knowledge of
the framework your working with. Usually when programming interfaces you
have some kind of UI library and/or framework that has features and
controls, if you are not aware of all the possibilities of that framework
you won't be able to make use of them.

In theory you shouldn't shape your solution based on what framework you're
designing it in but rather simply design and then program the best custom
interface. In reality however it's efficient to do so, rather you pick the
best (hopefully) framework and tool for the task and go from there. You
might design some custom control if it's extremely important but it's costly
and takes time.

That's why I think the Designer who programs have great advantage over when
the role is split. Not only does he knows more that can improve design, he
also implement it and make sure it gets done right. You can do much faster
iterations of a solution if you yourself can design something and quickly
implement it without having to synchronize a whole team. The downside is
that the designer programmer is extremely hard to find and demands a lot
from that role. Most designers don't have the time and inclination to be
really good programmers, and most programmers don't have the proper mindset
and interest to become great designers

best regards
--
Mattias Konradsson

25 Apr 2009 - 1:58pm
ambroselittle
2008

On Fri, Apr 24, 2009 at 12:18 PM, Dustin Savery <dustin at project7software.com
> wrote:

> In response to your comments, Ambrose, I would agree with you IF
> everything was in an ideal workplace and all developers were team
> players rather than looking out for their own self-interests. Good
> design usually means more work for them, and thus they usually fight
> those sort of things. That is why I would have to agree with Jonathon
> about needing to be a bit...forceful.
>

But beware of the dark side. Anger, fear, aggression; the dark side of the
Force are they. Easily they flow, quick to join you in a fight. If once you
start down the dark path, forever will it dominate your destiny, consume you
it will.

Heed the words of Master Yoda, my friends.

-ambrose

25 Apr 2009 - 6:42pm
Angel Marquez
2008

Sweep the Leg<http://www.urbandictionary.com/define.php?term=Sweep%20the%20Leg>

On Sat, Apr 25, 2009 at 11:58 AM, J. Ambrose Little <ambrose at aspalliance.com
> wrote:

> On Fri, Apr 24, 2009 at 12:18 PM, Dustin Savery <
> dustin at project7software.com
> > wrote:
>
> > In response to your comments, Ambrose, I would agree with you IF
> > everything was in an ideal workplace and all developers were team
> > players rather than looking out for their own self-interests. Good
> > design usually means more work for them, and thus they usually fight
> > those sort of things. That is why I would have to agree with Jonathon
> > about needing to be a bit...forceful.
> >
>
> But beware of the dark side. Anger, fear, aggression; the dark side of the
> Force are they. Easily they flow, quick to join you in a fight. If once you
> start down the dark path, forever will it dominate your destiny, consume
> you
> it will.
>
>
> Heed the words of Master Yoda, my friends.
>
> -ambrose
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

26 Apr 2009 - 2:09am
dszuc
2005

Good post.

What is the reward?

If I am rewarded for working to specification and implementing on
time with little regard to what works for the business or customers,
thats what I will do.

If I am rewarded for overlaying nice visuals on top of a business
problem that has not been articulated properly, thats what I will do.

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.

Its takes a leader to gel people behind a common goal.

You often see this in sport where you see teams playing in sync and
see how well they have been coached towards something more than the
individual needs in terms of their preparation and willingness to
abide by team rules i.e. I will give up my position on something,
because I know it will make for something better overall. Easy to
say, harder to do.

rgds,
Dan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=41485

Syndicate content Get the feed