I spent the past week at the Agile 2005 software conference. What an amazing conference and inspiring group of people! I spent some time with Lynn Miller from Alias who presented a report about how her companysuccessfully integrated User Centered Design (or UCD) with agile XP (Extreme Programming) practices. Lynn is the lead interaction designer on an innovative product called AliasSketchBook Pro. As an interaction designer, Lynn gathers customer information and defines and refines user features through prototyping and customer feedback. Lynn then feeds her designs to the development team who develop production quality code in month long “sprints.” At Alias, interaction designers work in tight collaboration with the development team, feeding them just-in-time interaction designs. According to Lynn, this is pretty unusual. Most companies do interaction design in all in one big lump before doing any software development. At Alias, interaction design is done in monthly increments, just like the code. Each coding sprint is fed by features defined by the interaction designers who worked on them during the previous month. Skeptics in Lynn’s field don’t believe that usability design can be done this way without sacrificing quality. Alias’ success story challenges these assumptions.

As an interaction designer Lynn isn’t up on the latest agile jargon. So for the first couple of days at the conference she was puzzled when she heard stories about how other agile teams had trouble identifying and working with the “customer” who defined “user stories” that the team implements. To Lynn’s and most people outside the agile community, customers are people who purchase products or services. How could you co-locate the “customer” with a development team? Don’t companies have many customers? What exactly was the problem some XPers were having? Only after a Lynn realized that XP defines customer as “an informed expert who clarifies requirements for an XP team”did her confusion evaporate. An XP customer isn’t necessarily an end user or purchaser of a product. Lynn plays the role of “customer” for her XP development team when she designs features. I agree with Lynn, the definition of an XP customer is confusing.

Lesson learned: Agilists who communicate with others outside their own community need to be aware that jargon is confusing. When someone looks puzzled it may be because they don’t share your context. Bridge this gap by asking a newcomer what’s unclear. Then take the time to decode insider jargon for them. You’ll learn something about what they do and how they think in the process.

I discussed with Lynn and Jeff Patton (another talented user-centered designer) what we each mean by “design.” To me, a software designer, design means creating a model of interacting software objects that are implemented in code. Interaction designers use a raft of techniques ranging from contextual inquiry (to understand the users’ work environment), to user-centered design (to cluster tasks and identify user categories), to interaction and user interface design. All these activities to an interaction designer are “design.” It was pretty easy to understand our different views and see how they dovetailed into an overall system design process. I don’t think we should come up with an unambiguous definitions for our various activities. Besides being unrealistic, we’d all have to start speaking design Esperanto which wouldn’t be a good thing. But I learned something. When you don’t understand what I mean, it is my problem not yours. As a good communicator I should try to bridge my ideas into your context. And when you don’t understand what I’m saying, please ask, “What do you mean by that?”