380 likes | 514 Views
Design, ethnography and institutional realities. Jack Whalen Aalto University School of Art and Design. ‘Shifting Territories’ seminar Aalto University School of Art and Design 26 January 2011. Shifting territories and spaces.
E N D
Design, ethnography and institutional realities Jack Whalen Aalto University School of Art and Design ‘Shifting Territories’ seminar Aalto University School of Art and Design 26 January 2011
Shifting territories and spaces • The territories of ethnography* and design – an integrated strategy for innovation/radical change ‘Users,’ ‘customers’ and ‘requirements’ and/or Discovering opportunities for innovation, possibilities for radically different futures But this often means shifting the design space, perhaps radically • The institutional realities of corporate life(‘organisations using users’…) *Ethnography is much more than a ‘research method’
Three design stories • Reengineering customer support • ‘Smart’ knowledge sharing • Customer self-service and ‘smart’ printers Questioning the institutional order, shifting the design space: What should we be designing? And with/for whom? (What is the problem we should be solving?)
Integrated Customer Service Reengineering Xerox call centres, c. 1995 Administration (account inquiries) Customer Service (equipment service) Supplies Marketing (sales of paper, toner, other supplies) • One face to the customer (reduce hand-offs) • Reduce costs (easier to manage call volume) • Increase revenue (opportunities for cross-selling & collection)
Integrated Customer Service Reengineering Xerox call centres, c. 1995 Administration (account inquiries) Customer Service (equipment service) Supplies Marketing (sales of paper, toner, other supplies) • The training challenge (only one challenge amongst many): • Each employee had to learn two new jobs whilst continuing to perform much of their current job • The training program for the three jobs (based on existing curriculum with classroom instruction) would require over 45 weeks to complete … but the experiment, with live calls, had to begin in four months! • The new process would also require some new curriculum development, with associated costs • And classroom instruction was assumed to require skilled trainers, who would be expensive • One face to the customer (reduce hand-offs) • Reduce costs (easier to manage call volume) • Increase revenue (opportunities for cross-selling & collection)
Ethnography: discovering opportunities for radical innovation • What we discovered • Natural monitoring practices • Physical environment as a barrier or enabler to collaboration (and learning) • Peer-to-peer teaching and learning • Employees capable of more than just functional work • What we believed this meant • Employees could and did learn ‘naturally’ whilst working • The physical environment could be redesigned to support collaboration and mutual learning on the job • Most learning could be moved out of the classroom and into the workplace • Employees could teach each other • Employees’ expertise showed they were capable of writing their own curriculum (a practical guide to the job)
Our prototype:Phased Interactive Learning (PhIL): • Learning by observing • Unstructured observation • Structured observation • Cross-skilled and co-located workgroups • Learning by doing • Learning after the classroom • Organisational support of natural learning activities • Integration of classroom work and real work vs
+ Workplace redesign • Low dividers • ‘Cubicles’ should be for the entire work group, not individuals • Extra-long phone cords (to compensate for absence of call-sharing technology)
Community knowledge-sharing: The Variation Reduction Advisor at GM • Advisor started as an Artificial Intelligence project, for manufacturing engineers in General Motor’s body shop • But it soon became apparent that the engineers wanted and needed something quite different! • Observing work practice: Knowledge-sharing through the daily log (diary)
Our remit: Enable sharing between engineers in different plants GM management and their R&D lab wanted a web-based Advisor, so that manufacturing engineers in the body shops of different plants could see each others logs
Our remit: Enable sharing between engineers in different plants But in working closely with the engineers, we had discovered some problems with this model.And a need for something thatwas similar in spirit but quite different in scope.
Manufacturing Engineers + Daily Log + Task list
? Manufacturing Engineers + Daily Log + Task list
Manufacturing Engineers + Daily Log + Task list Feedback/requests Changes + breakpoints Shared Shim Log Final Line
Manufacturing Engineers + Daily Log + Task list Feedback/requests Changes + breakpoints Shared Shim Log Tooling changes Shared Shim Log PM/CM status Maintenance - Skilled trades Final Line + Daily Log/ Shift Summary + Task list/status
Reliability Supplier/parts issues + Record of parts quality issues and related communications with suppliers Manufacturing Engineers + Daily Log + Task list Feedback/requests Changes + breakpoints Shared Shim Log Tooling changes Shared Shim Log PM/CM status Maintenance - Skilled trades Final Line + Daily Log/ Shift Summary + Task list/status
Reliability Supplier/parts issues + Record of parts quality issues and related communications with suppliers Manufacturing Engineers Feedback/requests Shared Shim Log Rework Reminders? Production + Daily Log + Task list Feedback/requests Changes + breakpoints Shared Shim Log + Daily Log/ Shift Summary (ESR) Tooling changes Shared Shim Log PM/CM status Maintenance - Skilled trades Final Line + Daily Log/ Shift Summary + Task list/status
‘Assembly Plant Advisor’ – Sharing between groups in a single plant Reliability Supplier/parts issues + Record of parts quality issues and related communications with suppliers Manufacturing Engineers Feedback/requests Shared Shim Log Rework Reminders? Production + Daily Log + Task list Feedback/requests Changes + breakpoints Shared Shim Log + Daily Log/ Shift Summary (ESR) Tooling changes Shared Shim Log PM/CM status Maintenance - Skilled trades Final Line + Daily Log/ Shift Summary + Task list/status
Institutional realities @ GM • Research project funding and expectations • Research ‘philosophy’ • Reluctance to let ethnography/user studies drive engineering R&D • Anxiety over any radical shift in direction GM’s decision: Build the Web VRA/multi-plant system for which we contracted!
Project rationale • Xerox service costs can be significantly reduced if more problems can be solved remotely rather than by a CSE (Customer Service Engineer) on site • Customer self-service is naturally the most cost-effective solution
CSE Remote Call solve 2nd Level Support solve CSE on-Site Customerself-service Welcome Centre solve The more we move calls to the left - the lower the cost to Xerox - the faster ‘time to solution’ is for customer Project rationale • Xerox service costs can be significantly reduced if more problems can be solved remotely rather than by a CSE (Customer Service Engineer) on site • Customer self-service is naturally the most cost-effective solution • Xerox calls this a ‘move to the left’ solution/strategy
Project rationale • Xerox service costs can be significantly reduced if more problems can be solved remotely rather than by a CSE (Customer Service Engineer) on site • Customer self-service is naturally the most cost-effective solution • Xerox calls this a ‘move to the left’ solution/strategy • ‘Voice of the customer’ data suggested customers might be motivated to fix things themselves • …but Xerox’s own data from the field showed poor results • But why? What did this mean?
Design challenges • Technical • Insufficient diagnostic information • Lack of customer self-help tools • Lack of coverage and specificity in the existing fault code structure • Organisational • Lack of integration (including information sharing) between service and support organisations Field service/CSEs + field analysts, 2nd level customer support, Welcome Centres, web self-service, training for customers • Socio-cultural • Customer practices and organisational life • CSE and Welcome Centre practices
Design challenges • Technical • Insufficient diagnostic information • Lack of customer self-help tools • Lack of coverage and specificity in the existing fault code structure • Organisational • Lack of integration (including information sharing) between service and support organisations Field service/CSEs + field analysts, 2nd level customer support, Welcome Centres, web self-service, training for customers • Socio-cultural • Customer practices and organisational life • CSE and Welcome Centre practices Can we make our machines smarter? More and better sensors, better reasoning = better diagnostics (and prognostics)
Design challenges • Technical • Insufficient diagnostic information • Lack of customer self-help tools • Lack of coverage and specificity in the existing fault code structure • Organisational • Lack of integration (including information sharing) between service and support organisations Field service/CSEs + field analysts, 2nd level customer support, Welcome Centres, web self-service, training for customers • Socio-cultural (behavioral) • Customer practices • CSE and Welcome Centre practices Can we make our machines smarter? More and better sensors, better reasoning = better diagnostics (and prognostics) Design objective: Develop an embedded diagnostics prototype for increasing customer self-help or remote solves
Design challenges • Technical • Insufficient diagnostic information • Lack of customer self-help tools • Lack of coverage and specificity in the existing fault code structure • Organisational • Lack of integration (including information sharing) between service and support organisations Field service/CSEs + field analysts, 2nd level customer support, Welcome Centres, web self-service, training for customers • Socio-cultural • Customer practices and organisational life • CSE and Welcome Centre practices But will machine users* be able (or want) to take advantage of better diagnostic information and customer* self-help tools? *These are problematic terms …
Ethnography for design… • Expose design engineers to the reality of life in the field and the real-world contexts in which ‘diagnosis’ actually takes place • Build realistic models of different kinds of users • Ability to distinguish certain failure modes (e.g., types of ‘streaks’) … and common-sense reasoning in this regard • Ability (and desire) to perform certain tests • Help lead the iterative development of diagnostic tools (and the self-service printer UI) through studies of customer sites and field service work
Findings: Distinguishing between operators, users and customers • We need to make a distinction between those whose job it is to operate xerographic equipment — ‘operator’ as an organisational role — and those who simply use that equipment in the course of doing their work • People who occasionally use the machines can perhaps be referred to as ‘users’ • The lack of training and experience amongst users is plainly a problem when it comes to unnecessary service calls, inability or reluctance to replace Customer Replaceable Units, and the like • ‘Customer’ does not seem to be a particularly useful term when it comes to describing people who are operating or using the machine; however, it is the right term for those whose main responsibility or concern is the business relationship with Xerox
Findings: Technician-operator relationships • Every customer of high-speed equipment that had experience with other companies stated that Xerox service was far superior “They’re the only ones who know what they’re doing” • The relationship between their operators and Xerox technicians was a key factor in this regard • Operators valued a close relationship with the technician above everything else • This relationship was often one of apprenticeship — of teaching and learning • Sometimes the learning occurs through observation rather than explicit teaching • Technicians commonly give out their mobile numbers, so they can be reached directly • This reduces ‘unscheduled maintenance’ calls, as problems can often be diagnosed and instructions given for resolving them over the phone I've been doing this about sixteen years. I’ve worked on just about every Xerox machine that ever came out. I'm very very close with the techs, to the point where I'm almost as knowledgeable in a lot of things, because they teach me so much, to eliminate me calling them in crucial situations. They taught me to change belts, fusers, certain rollers, drums — I'd say pretty much about 60% of the maintenance I do myself. With the help of them through phone conversations — I have a direct line [mobile phone number] to each one of my techs. I talk to them first before I even place a [service] call. Unless it's really intricate, they pretty much talk me through everything.
Direction for design: Operators, users and customers • Operators are highly motivated to perform self-service • They normally have responsibility for completing the job on time and meeting quality standards • They want to avoid any significant down time on the machine • They are also sensitive to its financial impact on the business – their employer expects them to try and keep the machine up and running • They value ‘craftsmanship’ and respect diagnostic skill • Users are most concerned with getting their own work done, and are likely to avoid performing self-service actions on a faulty machine if another is available • PARC is a good case in point: There are almost always other machines for research staff to use, but machine problems are the responsibility of key-ops – the organisation does not expect researchers/users to take the time to diagnose and solve such problems • Knowledge of xerography (and thus self-service capability) does not seem to be the key factor with respect to this behaviour
Direction for design: Operators, users and customers • Operators are highly motivated to perform self-service • They normally have responsibility for completing the job on time and meeting quality standards • They want to avoid any significant down time on the machine • They are also sensitive to its financial impact on the business – their employer expects them to try and keep the machine up and running • They value ‘craftsmanship’ and respect diagnostic skill • Users are most concerned with getting their own work done, and are likely to avoid performing self-service actions on a faulty machine if another is available • PARC is a good case in point: There are almost always other machines for research staff to use, but machine problems are the responsibility of key-ops – the organisation does not expect researchers/users to take the time to diagnose and solve such problems • Knowledge of xerography (and thus self-service capabilities) does not seem to be an important factor with respect to this behaviour • The organisational context of work, and its consequences for performing self-service, is plainly a critical design problem!
Direction for design (cont’d): Operators, users and customers • Users commonly need self-service tools, but are not especially motivated to use them • Operators are motivated to try and solve machine problems before asking a technician to come out, but are not likely to need the same self-service tools that Xerox provides for users • Two very different ‘move to the left’ strategies are needed! In other words, a radical shift in design strategy for the ‘move to the left’ / ‘smart’ printers effort
The new design space • For office settings and everyday machine users… • Undertake intensive field research on the ‘organisational context(s) of service and self-service’ for that environment • Design a service strategy that can address not only the technical challenges involved with building a ‘smart’ printer that can be easily serviced by its own users, but also the organisational-cultural challenges • For print shop settings and machine operators… • Throw Xerox’s full support behind enhancing – and wherever possible increasing – professional operators’ self-service capabilities • Closely involve CSEs in developing this self-service strategy – along with the necessary tools – for these operators • Design a process (with enabling technology if necessary) ways to support the sharing of this expert knowledge and these practices amongst operators working for different shops
Thank you http://web.me.com/jackwhalen/Site_2/Home.html jackwhalen@mac.com