Challenges and Solutions from Real World Experience

During this year’s CHI (Computer Human Interaction) conference, over 75 attendees participated in a formal SIG entitled Making Customer-Centered Design Work in the Real World of Organizations. Presentations by four panelists — representing Development, Human Factors, UI Design, and Usability from four very different organizations — described the key challenges they’ve faced in implementing and using customer-centered design. The panelists also shared what techniques have worked for them in overcoming those challenges. From there the participants — representing over 40 companies and universities and half a dozen countries — broke into discussion groups where they offered their own techniques, tips, and solutions.

Facing the challenges with a variety of solutions—big and small

The challenges identified fell into four broad categories: Getting Acceptance, Recognition, and Buy In; Working with Scarce Resources; Dealing with Product Definition Changes; Handling Special Skills Needed by the Team. The solutions that have worked range widely from small tactical steps to long-term strategies. The challenges you see here are written from the perspective of the conference attendees — who are interested in HCI issues — but you’ll find that they transcend job titles and organizations.

Getting acceptance, recognition, and buy in

Challenges

1. Feeling disempowered. Lack of management support causes people who care about customer-centered design to feel they have no power to make changes.
2. Participation from key people throughout the organization. Customer-centered design needs cross-organizational participation, but often a company’s culture works against this. For example, different disciplines are in different areas and have different bosses; e.g., development people have a hard time getting approval to travel so they can participate in customer interviews.
3. Hard to sell customer-centered design in a company that’s already successful. When a company is already a market leader that defined the market it feels it already knows its customers.
4. Late involvement limits ability to have an impact. If you want to insert customer data into the design, you need to get involved up front in the project definition.
5. No recognized design role for human factors or usability. Management doesn’t know what to expect from a usability person; they think usability is only about screen design.
6. No customer-centered design process in place. The need for field research is not recognized.

Solutions

1. Be a partner, not an adversary. People sincerely want to do a good job, so show them how using customer data will make them more successful.
2. Win over Development.

   Show, don’t tell

   Bring Development on to the team, and have them do things like go on site visits—seeing the customer data turns them into advocates.

   Have developers watch usability testing so they see firsthand what really doesn’t work.

   Directly expose developers to user problems (for example, listening to support calls) to help them start thinking more about what the user is trying to do.

   Show developers real, practical examples of how customers actually react to problems and workarounds to bring home the fact that customers don’t react the same way as developers do.

   Talk to developers and others in advance of giving them the requirements that came from customer data. That way they don’t feel like it was just thrown over the wall to them.

   Find one actionable task—but that supports the overall design — and provide customer data that will impact the design.

   Speak their language

   Developers are familiar with techniques like agile development and user stories. Use their terminology to communicate your customer-centered techniques.

   Emphasize reuse through design tools and patterns.

   Make friends and build partnerships.

   Find one person on the Development team who can come over to your side.

   Recognize that developers have authority and intelligence; communicate with respect and in the spirit of partnership.

   Keep developers involved with regular communication and build their confidence with consistent decisions on your part.

   Don’t worry about taking credit for ideas; let the developers take the credit.

   Help Development by testing and reporting bugs.

   Take them out to lunch.

3. Win over Project Managers and Product Managers.

   Take on jobs project managers don’t like to do, such as task analysis and use cases to create a good relationship and insert customer data into what you deliver.

   Hire project managers from the CHI community who understand the importance of customer data.

4. Win over management.

   Show management case studies of successes in other companies.

   Find places in existing company practices where customer-centered design would be a natural fit and insert it.

   Get buy-in at the top level to make shipping usable products an explicit goal.

   Teach management about usability.

5. Look for opportunity, and exploit it.

   Get involved early; be involved continuously.

   Own the prototype.

   Be part of the standard quality process.

   Come out early with success stories.

   Exploit areas that are already recognized problems and show how it’s a usability issue.

   Apply new techniques to a lower profile project. But remember that a lower profile project has less organizational commitment.

Working with scarce resources

Challenges

1. Timelines are tight. There’s no time to visit users, produce pilots, or iterate. Designs need to be passed on to development with enough detail and that also takes time.
2. There aren’t enough people. People are pulled in too many directions and doing too many projects in parallel. As a result, you end up losing credibility if you can’t be consistent with a project
3. Dedicated resources aren’t really dedicated. The best people to spend time understanding the customer are also key people for other projects. Consequently, they get pulled away.
4. Analyzing qualitative data is time consuming. It’s not only hard to find the time to collect the data; you then need time to analyze it.
5. There’s no space. A team needs its own space to work but finding a team room is hard, especially when you want to tie it up for weeks.
6. No consistent core team. The people working on the data collection and analysis have to really understand the problem; it’s hard to have a shared understanding when people come in and out of the team.
7. Not enough money. Collecting and analyzing customer data costs money. This is a cost to the organization that has to be justified. If you’ve hired out the work to a fixed-price vendor, you can’t easily add the data collection.

Solutions

1. Take a guerilla approach. Get in with market research people and find ways to team with them so you influence them to include some contextual customer data. To read more about guerrilla techniques, see Guerilla CD.
2. Scale down, scale up. Know your company’s culture Scale down the process into smaller chunks if that let’s you contract with an outside company to do customer centered design. If your company only contracts out for big projects, then find a large-scale project to start with.
3. Some data better is better than no data. It’s not a perfect world; you can’t do all kinds of research at all phases. Scale down and recognize that some customer data is better than no data. But be careful to closely manage expectations about the nature of the results you will get.
4. Get one “aha.” For every customer contact get one big “aha” out of it. Communicate each one to decision makers so the value is recognized and additional resources provided.
5. Be smart about the demonstration project. If you can only do one project, pick one that targets a new customer or user segment. That’s usually safer than tacking a flagship or high profile product. Use the demonstration to convince decision makers to fund and provide resources for mainstream products.
6. Maintain a central knowledge area. Create a central area or team of people who act as a shred resource and pull information as needed.
7. Centralize. A centralized team might successfully work on a top few projects rather than spreading the effort less successfully over many projects.

Dealing with project definition changes

Challenges

1. People change. People on the project change over time, and they then want to change the project focus.
2. Projects change. Project definition and scope change over time.
3. Unclear project focus. When the project focus is not clear, there are different expectations on the team and different management expectations.
4. Stakeholder conflicts. When the project has multiple stakeholders, there are often conflicting goals for the project.

Solutions

1. Start with clear requirements. Make sure your requirements are clear and mediate changes as they come in.
2. Stay alert. Be alert to all types of changes that can happen: scope creep, executive redirection, differing or predefined expectations of the outcome (solution before investigation).
3. Stay concrete. Use concrete deliverables to decide whether a change is appropriate. Talk about the impact of the change in terms of the deliverables in a way that executives or developers understand.
4. Stay tied to customer data. Encourage change based on customer data; discourage change based on people’s opinions. Examine whether change needs to happen; is it being driven by a customer need?
5. Work on communication and trust. Build trust so you can discuss changes as they come in. Make sure that everyone shares a language for talking about changes.
6. Document discarded ideas. Document rejected designs and ideas and why they were rejected so you don’t re-invent the wheel the next time around.

Handling special skills needed by the team

Challenges

1. Certain thinking skills are needed. Finding design meaning in the data requires thinking skills that some team members are not accustomed to needed in their jobs. At least some people on the team need to be “web thinkers” who can hold the hold the whole design in their heads.
2. Easy to get locked into one way of thinking. Having a mix of backgrounds, expertise, and thinking styles on the team helps keep people from getting locked into their usual way of thinking.
3. Different cognitive styles can clash. The team needs different thinking styles, but if team members don’t recognize and value the differences there can be clashes
4. Invention requires inventors. Inventing from the customer data requires cognitive leaps; you can’t completely automate the design process. To learn more about different thinking styles and how to work with — and leverage — each of them see Assembling Creative Design Teams.

Solutions

1. Do a skills inventory. List the skills available on team and measure them against the needs of the project.
2. Balance the team. Have an explicit conversation in the team to balance responsibilities. Instead of having product-centered teams consider having a cross-functional and/or cross-product teams composed of different skills sets.
3. Mentor. Put mentoring in place; people can learn from the skilled person.
4. Commit to professional growth. Actively support individuals to seek personal growth and education. Send them to outside training.
5. Don’t accidentally threaten people. Make sure that people with existing valued skills don’t feel threatened because they aren’t natural designers.

Acknowledgements

This article reflects the effort of the four panelists who shared their experiences and then acted as discussion group leaders at the CHI 2003 Special Interest Group.

• Joerg Beringer — SAP AG, Strategic Product Designer, xApp Design Group
• Paul Blowers — Medtronic, Human Factors Specialist
• Joyce Vigneau — Art Technology Group, Senior UI Designer
• Dave Wallace — Apropos, Vice President Application Development

Our thanks to them, and also everyone who attended the SIG.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]