After the effort to create new interaction designs for our company’s systems management software (which I describe in a separate story), I worked with developers, testers, product managers, and writers on the team that took over creating subsequent versions of the existing software.
The team used essentially a SCRUM process, in which I was a member of the Customer team, along with product managers and a colleague with years of field experience using the software and working with customers and users.
As a member of the Customer team, a large part of my time was spent with the backlog, understanding, clarifying, prioritizing and adding stories to it. We worked to put items in the backlog approximately in the form of User Stories as described by Mike Cohn in User Stories Applied. Our backlog had hundreds of stories and at each iteration we would estimate and commit to several dozen of them.
One of the initiatives that I tried out was to add acceptance test criteria to each of the backlog items for an iteration. I was initially surprised to find out how effective acceptance tests linked to items in the backlog were at triggering discussions, understanding and ultimately better estimates and code that worked more as the Customer team had desired more quickly than without the tests. In subsequent iterations we found that spending the time to document them in the backlog was often not worth the effort, but in certain cases it was (mostly when the range of polish or error-handling available was large and hence the range of effort estimates was large, too).
An interesting line of analytical and creative work, especially in the early iterations of the release, was taking the large designs from the redesign effort and turning those into stories that could fit within an iteration. There were two important aspects of this: breaking up the larger design for form and behavior and turning that into smaller steps, and making sure that the smaller steps each made sense in the order they were done in, and working to order them so that the highest return items were done earlier.
As an advocate for the user, it was also important to me that within any release (and preferably within each iteration) all primary user goals could be met, and that any user would have a coherent experience using the application. What we did not want was for the users to do something one way in one context of the system and a different way in another context. And we didn’t want step-wise changes in the software to prevent a user from achieving some goal at the end of an iteration because we were part way through creating something new.
Because the User Stories were not at the level of detail of our detailed designs (or any other formal specification), I was frequently involved in just-in-time design work with developers as they were working out specific details. Sometimes when the entire team was estimating and committing to an iteration, unexpected challenges (large estimates) and opportunities (ideas for changing a story to shorten estimates) arose, and there would be design on the spot, resulting in changes to the stories and new estimates.
Working in these ways in an Agile team was, of course, quite different from working on a large design-the-whole-thing-ahead-of-time project. I believe from the combination of experiences, reading, discussion and reflection, that both have their advantages and both have their risks. I also believe that the choice between them is primarily a software engineering choice, that while I have opinions, I don’t have a large stake in the decision as an interaction designer.
I do believe that as in interaction designer in order for any kind of development to be successful, it’s critical that I understand deeply the targeted users of the system. In addition, if the organization’s goals include making large or disruptive changes in the market or environment that they operate in, then doing comprehensive design (at least to the framework level) ahead of time makes the chances of large leaps forward in usefulness, desirability and usability much more likely than only doing incremental, opportunistic improvements without a larger vision.
Carl Seglem Portfolio
Resume
Big Data, Enterprise, and Complex Systems
Lean & Agile
Mobile
Patents
Carl Seglem Portfolio 