Apprenticing with the customer
Upcoming SlideShare
Loading in...5

Apprenticing with the customer






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Apprenticing with the customer Apprenticing with the customer Presentation Transcript

  • Objectives  Introduction  Requirements gathering  The Designer as Apprentice  Building on Apprenticeship  Apprenticeship in Practice  Partnership in Design
  • Introduction  System design is so intimately involved with how people work, designers need better approaches to gathering customer requirements.  It is the relationship between designers and customers that determines how well the design team understands the customer problem.  The current interest in participatory design, ethnographic techniques, and field research techniques grows out of the recognition that traditional interviewing and surveying techniques are not adequate for designing today’s applications.
  • Requirement gathering  If we build a product for sale that meets few customer needs, we will not be competitive in the marketplace.  Designing from deep knowledge of the customer is central to any effective requirements definition process, and companies are introducing customer- centered approaches in an effort to chart a clear path from customer to deliverable.
  • Issues of requirement engineering  Requirements definition conversations often centre around steps to do, techniques to use, or methods to follow.  Certainly without a clearly defined goal, we would not know how to proceed.  All aspects of requirements definition ultimately succeed or fail based on how well people can work together.
  • Human communication  Requirement definition is about people talking effectively with one another.  First, customers and designers must develop a shared understanding of the work problems and the impact of technical solutions on the work.  Team members who did not talk to the customer need to understand what was learned, draw their own conclusions and effectively participate in team conversations.  Finally, organizational functions—design, engineering, marketing, documentation, testing, and customers—must also understand the problem, agree to the technical solution, and communicate implications for their own functions.
  • Involvement and Control  Effective requirements definition requires involvement and mutual control of the process by all players.  No one likes to feel out of control of their time, their work activities, or their goals.  Ownership means having the power and skill to renovate any given process to meet the unique needs of a particular team
  • Change is a Necessary Ingredient  we must redefine jobs to include designers who don’t code, work practitioners who might not design, and architects who make the platform fit the work not the work fit the platform.  we have to change the places we work: at customer sites as they do real work.  It is the relationship between designers and customers that determines how well the design team understands the customer problem.  A familiar model of relationship suggests roles, attitudes, and behaviours people use naturally.
  • The Designer as Apprentice  How do designers learn enough about customers’ work to design well?  What kind of relationship allows customers to impart deep knowledge about their work?  The relationship between master and apprentice stands out as a useful model.  Just as an apprentice learns a skill from a master, designers want to learn about their customers’ work from the customer.
  • Seeing the work reveals what matters  Even if the master is a good teacher, apprenticeship in the context of ongoing work is the most effective way to learn.  People are not aware of everything they do, Each step of doing a task reminds them of the next step.  Some actions are the result of years of experience and have subtle reasons;  Customers are also not aware of everything they do or why they do it.
  • Seeing the work reveals details  Talking about work while doing it allows a master craftsperson to reveal all the details of a craft.  As master or apprentice observes a pattern or principle in action, he or she can point it out immediately.  the master can describe exactly what he or she is doing and why  Every action customers take and every object around them helps them talk about what they are doing in detail.
  • Seeing the work reveals structure  The apprentice learns the strategies and techniques of work by observing multiple instances of a task and forming his or her own understanding of how to do it.  The master can communicate techniques and strategies without articulating them.  Designers observing multiple events and multiple customers learn to see the common strategies underlying the work.  Once they understand the basic strategies, they can start to imagine a system that would support those strategies.
  • The apprentice can learn from the master’s experience  Apprentices learn from the experience gained by a master before their apprenticeships started.  Designers can learn about events that occurred in the past.  The artefacts of work papers, forms, notes, clipboards, and so forth trigger conversations about how they were used, how they were created, and how their structure supported their use in a particular instance.  The documentation provided the context She/he needed to recover a detailed story.
  • Building on Apprenticeship  While apprenticeship defines an attitude for designers to adopt.  apprentices want to know how to do the work, designers must determine what a system might do to support the work. This leads to changes in the customer-designer relationship.
  • The designer must be responsible for seeing work structure  Designer must understand structure and implementation  The job of the designer is to recognize work structure.
  • Designers must articulate their understanding  Apprentices can learn the structure of work without articulating it. But if designers do not articulate the structure they see to their customers, they cannot get their understanding corrected.  Which of these designs is best? It depends on which interpretation is correct. The only way to ensure an interpretation is correct is by sharing it with the customer.  We fail in the entire purpose of working with customers if we do not share and validate these interpretations.
  • The designer’s job is to improve work  The designer constantly thinks about ways to improve the work with technology.  Designers know about technology, have skill in applying it to real-life problems, and naturally respond to the customer’s activities by designing improvements to them.  The apprenticeship model allows both designer and customer to introduce design ideas as the work suggests them.  The customer can respond to the idea while doing the work the idea supports.
  • The designer has a specific focus  The designer, who intends to support a specific kind of work, needs to guide the customer in talking about this specific part of that work.  The apprenticeship model allows designer and customer to guide the conversation into areas of work that are relevant to the design.  Using the apprenticeship model as a base, designer and customer can develop an interaction that allows them to explore and understand the customer’s work together.
  • Apprenticeship In Practice  In practice at some point the designer makes an observation or asks a question. This interrupts the flow of work.  In order to respond, the customer has to stop working, step back, and think about the question.  Maintaining the apprentice relationship requires attention to the interaction. Otherwise, customer and designer may fall back into more traditional patterns for requirements gathering.
  • Falling into other relationship models  Having apprenticeship as a model gives designers a way of behaving that replaces the behaviours they would naturally use otherwise. But because other relationship models exist, and are habitual, designers must recognize when they have fallen into them and know how to get out.
  • Talking in the abstract  People are liable to giving a high-level summary of past events devoid of the detail we need.  Most people will start telling a story in the middle, ignoring what went before. Then they will skip whole steps as they tell the story.  Listen for missing steps and ask the customer repeat comments as necessary.
  • Tuning an interpretation  Customers responding to the interpretation in the moment of doing the work can fine-tune it quite precisely.  A design is based on interpretations of work; if these are not shared with the customer, the design will reflect the designer’s made-up explanations of customers behaviour.
  • Adjusting Focus  Focus guides the interaction with the customer, determining what to pay attention to and what to ignore.  The designer’s initial focus may be wrong or too limited.  Probe into the details. Why is this information so different? What is going on? What expectations are violated? Probing leads to an expanded understanding of the work.
  • Partnership In Design  We started with the notion of apprenticeship as a good way to learn about the customer. But applying apprenticeship to the special problems of design leads to a shared design conversation and a partnership between customer and designer.  Apprenticeship is a form of intense listening that leads to mutual ownership and partnership between customers and designers.  Using the apprenticeship model addresses the problem of requirements definition by creating an effective relationship between designers and customers.
  • References  HUGH R. BEYER and KAREN HOLTZBLATT Apprenticing with the customer. Communication of ACM may 1995/vol.38 No 5  Holtzblatt, K. If we’re a team, why don’t we act like one? Interactions 1, 3 (July 1994), 17.  Holtzblatt K., and Beyer, H. Making customer centered design work for teams. Commun. ACM 36, 10 (Oct. 1993), 92–103.