How To Incorporate Interaction Design Into The Sdlc
How To Incorporate Interaction Design Into The SdlcI'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 InteractionDesigners 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, InteractionDesigners 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 InteractionDesigners 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
Is the fundamental problem that InteractionDesigners 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 InteractionDesigners from the people acting as programmers? Wouldn't you rather have programmers with InteractionDesign skills coupled with InteractionDesigners 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 InteractionDesigners 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.
EditText of this page
(last edited January 13, 2009)
or FindPage with title or text search