You are here

HCI & IA: Information, Interaction, Interface and Usability Architects Share Deliverables

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.

George Olsen presenting his view on deliverables

Here are the terms we captured for each participant.

Annie Archbold and Bill Curtis, IBM Atlanta
  • Bridge between tech & creative
  • Entire presentation layer
  • Right vs. Left brain thinkers
  • Not: usability/content
Peter Boersma, Satama Interactive
  • Career: role + skill
  • Work / deliverables: User Understanding
  • Methods / process: SUP
Liz Danzico, Columbia House
  • One deliverable, many purposes
  • Internal vs. External artifacts
  • (teaching the process)
Leo Frishberg, VideoTele.com
  • Economy, utility, delight
  • Service vs. Marketing vs. Development vs. Advanced Technologies
  • Specs.
  • QFD
  • Prototypes / usability studies
  • LIS vs. Architecture vs. Industrial Design
Boyd de Groot, Satama Interactive
  • Industrial Design * Information Ergonomics / UI / HCI
  • CUI * GUI * WEB * Mobile Internet
  • (senior) Concept Designer + Design Manager
Frans Heeman, Elsevier Science
  • UCD, internal
  • "Traditional" IA, bibliographical databases
  • Search & browse, funtional prototypes
  • Content-based UI
  • "Transparant" UI
Keith Instone, IBM.com
  • IA Strategy
  • LIS
  • Sharing/public/evangelism
Arnie Lund, Sapient
  • HCI
  • Ease of Use + Useful = UCD
  • Emerging Technologies
  • Sapient / Process
George Olsen, Interaction by Design
  • Multi-lingual mutt
  • Content - Experience
  • Form - Tech
  • Behaviour - Business
  • Translators
  • Articulate
  • Outside developer vs. In-house consultant
Dave Roberts, IBM UK
  • Tracability
  • UML
Anita Salem, Salemsystems
  • Audience
  • Translate
  • Process
  • Concept / Research / Usage
  • No detailed design

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.

Placing deliverables on the table

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

  1. Methodology
  2. Offering & Methods
  3. Business Problem
  4. Markets vs. Products
  5. Business Requirements / Context / Comparative Analysis
  6. Understand User
  7. Understand User Process + Contextual Inquiry
  8. Understand User Context
  9. Understanding Phase + Prototype for Concept Definition
  10. Benchmark
  11. Service Concept
  12. Document Existing Work
  13. Customer Requirements vs. Feature Sets
  14. High Level Concept
  15. Define Concept + Evaluate Mode
  16. Feature List, Functional/Non-functional Requirements
  17. Deconstruct Story into Elements
  18. Release Plan
  19. Design Underlying Structure
  20. High Level & Detail Interaction & Navigation & Flow
  1. Concept
  2. Design
  3. Iterative Prototyping
  4. Mockup
  5. User Profiles
  6. Requirements
  7. Design Visual Structure & Structure Presentation
  8. User Scenarios
  9. Detailed Design
  10. Diagrams for Developers
  11. Iterative Design & Test
  12. Formal Specification
  13. Detailed Design Specs / Wireframes
  14. Specs for Development
  15. Specs for Implementation
  16. Synthesis into Model
  17. Implementation + Support
  18. Unit Testing Support
  19. Usability Testing (high level)
  20. Go Forward Documentation
  21. User Acceptance Testing Plan
  22. Evangelism Education

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.

The table of deliverables and all gathered around it

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.

Discussing the deliverables

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.

Our poster that summarizes what we learned

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?
AttachmentSize
PDF icon hci-ia-abstract.pdf98.58 KB