Should interaction designer produce code...(Formally: Open Position: Sr. Interaction Designer @ MITRE)

20 Oct 2004 - 4:41pm
10 years ago
1 reply
718 reads
Cindy Alvarez
2004

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Ron Vutpakdi:

>> Second, if they think that the prototype takes advantage of things that
>> are easy to do in the prototyping language but hard to do in production
>> code, the developers can walk away with the impression that the
designer is being unreasonable and unpleasant to work with.
>
> Again, this is a colossal misunderstanding of the purpose of the
> prototype.

And an issue in communication styles, I think. If you're in a situation
where time and resources are always scarce, then you need to make it clear
that you understand the time-usability tradeoff. My engineering teams
don't care if it took me 5 minutes or a full day to prototype something;
what matters in our working relationship is that I understand the relative
degree of difficulty for *them*.

Just saying, "I know this will take a long time" goes a long way towards
being a reasonable designer to work with. Making it clear that you have
done cost-benefit analysis goes a lot, lot farther. Sometimes the most
elegant solutions is difficult to implement. Then you calculate: is the
second-best solution still acceptable? is the problem major enough to
warrant that extra time?

Part of the reason that development teams are still given the latitude to
"take or leave" designer input is the perception that designers aren't
doing a cost-benefit analysis. The prototyping tool doesn't matter in
that, it's the solution put forward. If there is 12 weeks of dev time,
then the design solution had better not take 16 weeks to implement. If it
does, it won't matter if the prototypes are in HTML or on a soggy napkin,
credibility is lost.

Cindy

http://www.cindyalvarez.com/

Comments

20 Oct 2004 - 5:09pm
Listera
2004

Cindy Alvarez:

> And an issue in communication styles, I think. If you're in a situation
> where time and resources are always scarce, then you need to make it clear
> that you understand the time-usability tradeoff.

Certainly. We really haven't talked much about what happens *after* the
design team completes the prototype and all the selling and positioning that
has to be done within the organization, and not just wrt developers but
*all* the stakeholders.

(Incidentally, just because I'm advocating that the prototype be done by the
design team, I hope it's not assumed that designers and developers do not
communicate during the entire process.)

Ziya
Nullius in Verba

Syndicate content Get the feed