Should interaction designer produce code...(Formally: Open Position: Sr. Interaction Designer @ MITRE)
20 Oct 2004 - 4:41pm
10 years ago
> [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.