Keith Instone

This is a report on what happened at our CHI 2002 workshop on deliverables (April 22, 2002, CHI 2002).

Participants

• Keith Instone, IBM
• George Olsen, Interaction by Design
• Peter Boersma, Satama Interactive
• Dave Roberts, IBM
• Arnie Lund, Sapient
• Anita Salem, Salemsystems
• Annie Archbold, IBM
• Bill Curtis, IBM
• Liz Danzico, Columbia House
• Boyd de Groot, Satama Interactive
• Frans Heeman, Elsevier Science
• Leo Frishberg, VideoTele.com

Ways to discuss deliverables

During our initial brainstorm we identified the following aspects of deliverables that we wanted to discuss:

• Place in process
• Audience
• Role/skill
• Work product vs. Client deliverable
• Media/type of product
• Pragmatic concerns
• Organizational context

Five-minute presentations by participants

Next everyone did five minute presentations that focused on their backgrounds and work environments, and how this influences their deliverables.

Here are the terms we captured for each participant.

Place in process: Initial organization of deliverables

All participants brought one or more deliverables to the workshop. They ranged from one-page screenshots to 300-page books on development methods. A total of 42 deliverables were submitted.

We started with placing the deliverables on a long table in the order we used them in our projects (Place in Process). By quickly comparing the deliverables to what was already on the table, people could decide to put their deliverables to the left ("earlier") or the right ("later") of those of others. After a quick review we gave them short and, where possible, unique names.

Here is a list of the 42 deliverables, ranked roughly from "start of the process" to "end of the process".

Things we learned from discussing the deliverables and their place in time:

• Prototypes seem to run through the project in an iterative way, gaining fidelty as time progresses.
• Deliverables at the end of projects serve as input for new projects: the loop is closed. Examples are Keith's evangelism deliverable, Liz's Styleguide, and Dave and Peter's Methodologies.

What most participants mentioned was the convergence in processes and deliverables, despite the different backgrounds of the attendees. There was much more overlap in both the shape of deliverables (despite differences in culture, naming, exact methods, etc.) and their place in the process than most people expected.

Other dimensions: Audience (Work product vs. Client Deliverable)

We discovered that there is a difference between internal (in-house) and external deliverables, but also that different audiences can use the same deliverable in a different context. The clearest indication of this fact was that the naming of deliverables (and concepts inside) mattered, especially if the deliverable is used in different business cultures ("thrown over the wall").

Other dimensions: Role and Skills

We then wrote down what skills were needed to create the deliverables and placed the skills on the deliverables with sticky notes. (But the full list of skills has been lost.)

We agreed that the skill set of an architect/designer does matter when selecting deliverables for a project. Some people feel more comfortable expressing their ideas in visual formats (wireframes, sitemaps), other prefer textual formats (functional designs, scenarios). Depending on the familiarity and affinity with a certain deliverable format, the author may create a skinny, shallow version, touching only the surface, or a "fat", deep version, with in-depth analyses.

The discussion about skill sets then touched education: What skills can be taught, what can be learned through experience. The general feeling was that an academic background is not necessary. There is still a disconnection between academia and practice, although academia is getting more practical. This made us think that a coherent set of deliverables could serve as a useful section of a textbook.

Organizational Context and Lifecycle of Deliverables

After lunch we decided we wanted to follow some deliverables through the design process, to see how they evolved.

We wanted to trace the following aspects:

• Audience (internal vs. external, business vs designers vs developers)
• Techniques/tools (ethnography, sketching, powerpoint, visio)
• Role of author (researcher, designer, developer, evaluator)
• Naming (internal, external, naming schemes, versions)
• Ownership (individual vs group, discussion-piece vs. sign-off)
• Transformations (input and output, growth or rework)

Candidates that qualified for following (because of their longer life-span) were:

• User profile
• Scenarios
• Prototypes
• Functional specs
• Conceptual maps

We only had time to discuss the User Profile deliverable.

Audience

For clients with an interest in marketing, the deliverable is written for different marketing segments. For business-oriented clients, the deliverable is written towards solving different business problems.

Technique/tool

Ethnographic techniques (contextual inquiry, interviews, etc.) should be employed.

Role/skills

Research, enthographer, analyst.

Naming

User profile, target group, market segment, persona.

Ownership

Some clients (with marketing departments) are able to deliver (and own) user profiles. If an HCI professional creates the deliverable, (s)he will usually guard the profile during the design process, occasionally checking designs against the profile. Sometimes the profiles (usually in their persona-shape) are on display for the developers to remind them whom they are building for. These developers may have a need to add fields and values to the descriptions.

Transformation

Typically, user profiles change from lists of marketing-generated percentages to descriptive narratives coupled with scenarios. Later in the process, when they are used as evaluation tools or reminders fro developers, they become more illustrated.

Next steps

We created a poster for the conference to share what we did with attendees of the main conference.

The major next steps we talked about were how to let others learn from deliverables and open questions that we still have about them.

Spin-offs of this workshop could be:

• An online repository of our (sanitized) deliverables.
• A textbook where these deliverables and our findings are discussed.
• A series of contributions to a special issue of a related journal.

We indicated a couple of ways to dig deeper into the area of HCI-deliverables:

• Follow the life cycle of deliverables (more "threads" like the User Profile above). We identified scenarios, prototypes, functional specs, and conceptual maps as candidates.
• Patterns for deliverables: which groupings of deliverables make sense, when, why, and how does one create them?
• Theory vs Practice: what happens when practitioners work according to established methods; how do they adapt the theories to their day-to-day practice?