Consultants are, in our esteem, mostly well-intentioned. But often they aren't around long enough to see the effects of their work, and aren't keen on investigating whether any harm was done before offering the same (apparently successful) method to the next client. As practitioners who have been on both sides of this fence, we have some observations for consultants and the clients who hire themall in the name of increasing the number of heroes, and decreasing the number of hucksters. Consultants, we'd like to sensitize you to a few problems you may not have had the opportunity to observe; and to those hiring consultants, we'd like to offer a few tips to improve the way consultants and clients work together.
Consultants: Some consultants invoke the name of their mentor, their university, and/or the holy name of their discipline (HCI/UCD/design) to secure credibility with potential clients. The best credibility is that earned through experience, both good and bad. Experienced consultants can qualify their comments and analyses based on previous projects rather than invoking the famous with similar opinions. Case studies and explicit examples, with as much context as possible, give clients a realistic view of what the consultant has done and can do. If there is no context and the method is a one-size-fits-all, please read on. We'll get to that.
Clients: Check your assumptions with your consultant's. Don't be comforted that they follow user-centered design or follow a famous guru's every step. Understand their process, their deliverables, and what the consultant thinks you will be able to do with their deliverables. And then make sure you ask for examples and show them around to make sure the development team can use the form and content they are offering. Furthermore, do not think that a consultant performing one aspect of user-centered design will result in a user-centered design product. UCD is a development methodology. A consultant can contribute a portion to that effort, but he or she cannot substitute for following best HCI/UCD/design practices. For example, excellent user research will not make an excellent product without good design and user testing practices.
Consultants: Hucksters sell miracle cures. They often offer a quick fix that leads to long-term problems, ensuring the services of the same consultant to continually mop up the mess. Worse, the consultant can sometimes take advantage of the client's lack of understanding of HCI to come up with impressive-looking documentation that may overwhelm. This is surprisingly common with consultants offering user research who deliver a mountain of unsynthesized data. Better consultants don't make money-back guarantees and don't promise success; instead, they facilitate, enable, or coach a client toward success. They also set expectations correctly. Context is everything: The solution you recommend today may have a limited lifetime. Don't let your clients mistakenly assume that you can forever fix an endemic business process with a user-centered design approach.
Clients: As a client, you are purchasing effort and likely trying to purchase a specific result. In the process of working with a consultant, keep your eyes open and permit yourself the opportunity to draw your own conclusions in addition to considering those provided by your consultant. Sure, you hired him or her for the expertise and perspective you lack. But it's your business, your problem, and just the process of engaging with a consultant can help you develop your own insights. Make sure the consultant does not leave you with a heap of data that puts the onus on the reader. Likewise, don't accept a consultant's conclusions without evidence; there must be enough material to empower you to reach a conclusion that respects your own perspective. Don't ignore your intuition, and be proactive in the consultant/client engagement. A consultant will rarely have the depth of domain knowledge that the client has in-house. If you do not challenge the consultant with your domain knowledge on his analysis during the project, then you cannot be truly surprised that he does not take your special issues into consideration.
Keep your eyes open and permit yourself the opportunity to draw your own conclusions in addition to considering those provided by your consultant.
Consultants: You can give your client broad, general conclusions and a dense pile of data from which you derived your results; just don't forget to make the connections between them clear. We once received a conclusion from a usability consultant: "Your score is 86; that's pretty good!" Presented as a summative conclusion, we questioned how that number was derived. Turns out it was a score on a single questionnaire instrument and didn't in any way reflect a roll-up result. Good thing we asked.
Clients: If you don't ask, you don't get. If you have questions about the methods or the results, speak up! Don't accept "it's too complicated to explain" or "that element is irrelevant" without exploring why. You are paying the bill; get your money's worth. But if you don't ask during the consultant engagement, asking the consultant to "show their homework" later will either delay your project or increase the costsor both.
Consultants: If you are providing a service working as a "pair of hands," you are equivalent to every other worker on the factory floor. Alternatively, if you promise to enable your client to do something themselves, set out the criteria that will help them see when they're ready to do so. While there is a lot of promise in long-term relationships with a deep-pocketed company, if you say you are training them, at some point both you and your client should be able to recognize that they are ready to fly solo. There's nothing wrong with long-term relationships. But deliver what you promise, or explain why it's not possible.
Clients: Do you have a codependent relationship with your consultant? We have a consultant working in our UX team who plays a pivotal role in the team; she's great, everyone loves her, and she provides deeply thoughtful solutions. But she's a consultant, not an employee, and she can name her own schedule. She doesn't want a full-time job. This affects the type of work that is appropriate for herwe can't expect a long-term commitment, but short-term deliverables that can be cleanly packaged are perfect. She's both a pair of hands and an enabler, and it's important to focus on learning from her and leveraging her skills inside the company. Oh, and yes, we do regularly continue to offer her a job (and she always says no).
Consultants: Your client hired you ostensibly because they are feeling a bit of pain in one area or another and they think you can help relieve the symptoms, maybe even solve an underlying problem. Like the doctor who says "this is going to hurt a little," you owe it to your client to prepare them for the consequences of electing to undergo a procedure. Plunging in and shaking things upeven if you really do know bestcan create irreparable damage in some environments, and you'll get splattered in the process. Try not to poke your finger too hard where you know it will hurt the patient.
Clients: Consultants don't generally offer anesthesia. Don't expect that you can tend to other matters and a consultant can "fix" things without any visible disturbancedepending on the size of the dilemma, of course. A mere flesh wound is different from a massive head injury. Know how much change, pain, and indecision you can tolerate before you engage in a relationship where you pay a consultant to tell you what's best for you. We recently heard this from a customer: "This is all terrible. And further, this criticism is good medicine for you; it might be hard to take, but you'll be better for it." Delicate flowers aside, this admonition could make us stronger, but we just found it unhelpful and insulting. It's all in the delivery. Don't expect your consultant to work painless miracles.<eic>
©2007 ACM 1072-5220/07/1100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.