I'm working at a company where InteractionDesign has become a major feature of our overall SystemsDevelopmentLifeCycle.  We have experienced two negative outcomes:  First, we have become a WaterFall development shop and second, the InteractionDesigner''''''s end up GoldPlating.  I don't know if the WaterFall consequence is a necessary outcome of incorporating InteractionDesign, but I believe GoldPlating is a natural and, almost necessary, outcome.

As stated on another page, InteractionDesigner''''''s work ''much'' faster than programmers.  That necessarily creates a glut of requirements to the programmers.  That glut can either grow and be treated as a backlog or the InteractionDesigner''''''s can spend time iterating over existing requirements to improve them (GoldPlating).  Neither one of these activities is all that helpful to the ultimate goal of shipping software.

So, my question is, how do you incorporate InteractionDesign into a development lifecycle without the negative consequences?  How to you get all of the forces lined up to actually ship software?

'''Proposals'''

* Share one interaction designer between multiple projects. This way you reduce the amount of design that can be done for any one project.

* Desynchronize interaction design and programming completely, up to and including having the interaction designer walk away, but remain on call, once the design is substantially done.

* Have the programmers price the refinement / backlog UserStories out of management's reach. Only works if you do XP.

----

Is the fundamental problem that InteractionDesign''''''ers don't share in the 
cost of building software?  They have no systemic reason to bound requirements by cost.  In our case, the programmers don't know enough about the problem domain to recognize that cheaper solutions may exist.  Therefore, InteractionDesign gets little pushback on requirements.

Does it really make sense to have separate people acting as InteractionDesign''''''ers from the people acting as programmers?  Wouldn't you rather have programmers with InteractionDesign skills coupled with InteractionDesigner''''''s with programming skills?

''Even if you accepted that the former would have miserable design skills and the latter would hate to program, that's an aweful lot of added cost to get people who appreciate the other's point of view. One is reminded of the ancient suggestion that an architect should also be a mason, a miner and a singer. If they're not a singer, they won't be able to tune catapults by listening to the pitch made by the skeins when struck with a hammer.''

----

I worked at a company where the InteractionDesign was well integrated into an XP process. Iterations were one week long. There were an initial few iterations that did not include the full team wherein the project was being defined and early versions of story cards written, but there was an effort to get going on coding as early as possible. In a complimentary fashion, there were usually a few iterations toward the end of the project where the bulk of the work was with the developers and the InteractionDesign''''''ers were mostly on to other projects. It worked well because all members of all teams were working in one large co-located space, so it was easy to get small InteractionDesign sessions started as needed late in the project despite the fact that the InteractionDesign team was focused on another project. During the bulk of the project's run, both teams worked fulltime on the project, with the InteractionDesign team usually working on designs for the upcomping iterations and answering questions on the storycards they had written which were driving the current coding. The InteractionDesign team wrote story cards from the "target persona's" perspective, developers estimated those story cards, the client planned the project with the story cards and the project manager assigned work for an iteration with them. A story card could only be declared finished by someone from the InteractionDesign team. This seemed to give everyone a portion of the control and minimize unproductive conflict.

CategoryInteractionDesign