X.6 November + December 2003
Page: 20
Digital Citation

Managing interdisciplinary relationships

Elizabeth Rosenzweig, Joel Ziff

back to top 

User-centered design and usability have gained precious ground in getting recognition of users' needs in the development process. More companies than ever before have usability labs. More universities include human factors, engineering psychology, and usability in their curriculums. We've identified and overcome many of the hard obstacles: We've learned how to document return on investment and sell usability, and we've learned how to modify development methodology to incorporate user-centered methods.

However, we still face many "soft" but equally difficult obstacles as we work to make user-centered design (UCD) standard practice: impasses in our working relationships with colleagues from other disciplines. These obstructions are not easy to define, but anyone who has attended a conference and listened to the war stories of colleagues knows that these interpersonal challenges are pervasive and difficult to overcome.

There are no formulas or simple answers as we work to resolve problematic interpersonal dynamics in the workplace. When we experience interpersonal challenges, we are sometimes oblivious, failing to recognize the unique dynamics of a particular situation. Instead, we tend to rely on "common sense" responses that are habitual and rigid, responses that often do not help us achieve our goals. We must suffer the consequences of our mistakes, and we don't always succeed in our goals.

Relationships can evolve in the same way that a good design evolves. In fact, the concept of "iteration," so near and dear to us in design, provides a good metaphor for managing working relationships. Each interaction gives us another opportunity to change the tone and improve a situation. We will inevitably make mistakes, but we also have the ability to learn from those mistakes and gradually improve our effectiveness as well as create more nourishing and productive working relationships.

We can learn to respond in different ways depending on the people involved and the circumstances: to be able to build trust, to speak and to listen, to be assertive and to be responsive, to ask for help and offer support to others, to take initiative, and to follow the lead of others.

In this column we offer guidelines for addressing three common interpersonal obstacles to user-centered design input:

  1. Respect short-term concerns and needs of others when working toward long-term goals.
  2. Address the real technical problems developers face when integrating new designs.
  3. Pay attention to differing perspectives resulting from differing roles as well as to turf battles and personal agendas.

Let's discuss them one at a time.

bullet.gif Guideline #1: Respect short-term concerns and needs of others when working toward long-term goals.

As user-centered designers, our focus is the long-term goal of creating high-quality products that are easy to use as the foundation for a successful business. However, our colleagues are often rewarded for short-term accomplishments; they may have little time to ponder the longer term implications of design decisions. We cannot ignore the realities of these short-term concerns, such as the pressure to release products quickly and economically, minimizing the amount of time and effort for development. We need to be advocates for the user and for the long-term success of our work, but we must also be sensitive to short-term concerns for efficiency and economy.

bullet.gif Guideline #2: Address the real technical problems developers face when integrating new designs.

Many of us in the UCD community prefer not to focus on technical constraints. We are concerned that we will be less effective as user advocates if we immerse ourselves in technical details. However, this perspective does not help us with our colleagues. UCD professionals are often viewed as naïve and ill informed: We care more for the "users" than for the "developers," we don't really understand the technical constraints of the systems we are designing, and our solutions are technically unrealistic. Too often, our input is dismissed because it doesn't match our colleagues' sense of what is technically feasible. We will be accepted as full members of the team only by actually delving into the details and demonstrating that we understand the technical constraints. The more we know the technical details, the more effectively we can argue for changes that will make a difference for users and be feasible to implement.

bullet.gif Guideline #3: Pay attention to differing perspectives resulting from differing roles as well as to turf battles and personal agendas.

Our role is interdisciplinary. To do our jobs well, we must interact with a variety of colleagues across the organization, each with his or her focus and perspective: a concern with development, finance, marketing, sales, and so on. Fundamental differences in perspective, reward structures, and expertise are inevitable. We need to respect those concerns and take them into account as we work to achieve our goals.

In addition, each of our colleagues has personal concerns that are often not made explicit. If we are oblivious to the unspoken feelings and agendas, our ideas may be rejected for reasons that have nothing to do with their validity. To be effective advocates for the users, we must first understand the needs of those who are using our information, and we must find ways to respond to their needs as well.

back to top  Case Examples Applying the Guidelines

We present several examples in which people have applied these guidelines to practical interpersonal dilemmas. In each case, the UCD person began with a common-sense approach that backfired because of dynamics in the organization. The UCD professional then used one or more of the guidelines to understand the problem and clarify how to resolve it. (Although based on real situations, the names and details have been changed to protect privacy and confidentiality.)

back to top  Case Example #1: Paul's Prototype

bullet.gif Initial Approach

Paul, a user-interaction designer, created a prototype design for the home page of the company's sales site. The company offers several versions of its product: a lower-priced, basic version for the average consumer; and a higher-end version for the business user. Paul presented his design at a meeting with Lisa, the product manager; Larry, the marketing manager; and Rosa, the Web developer.

On the basis of the company's research, Paul concluded that pictures and graphics confused customers. They responded best to simple, uncluttered, and clear designs. They also resented efforts at hard selling, which generated distrust of the product and the company. From these findings, Paul created a prototype using a simple page with text and no graphics, asking three qualifying questions to determine which product is most appropriate for the customer.

Larry is surprised and upset. He thinks the design will influence customers to buy the cheapest version. He wants customers to be encouraged to buy the most expensive version. Rosa is also critical of this new design because this change in the home page has to be coded from scratch. She does not have enough time to do it with the current schedule.

To make matters worse, Lisa, who has the authority to make a final decision, is not focused. Every few minutes she leaves the meeting to talk to someone on her cell phone. Paul repeatedly tries to explain the reasons for his design, referring to his PowerPoint presentation that summarizes his research methodology and findings. Neither the marketing manager nor the developer pays much attention to the graphs and tables. They talk to one another, agreeing that this proposal is neither viable nor practical.

This scenario is not unusual. In today's business environment, with pressures to get products into the marketplace more quickly with fewer resources, more conflicts take place between those who are watching the bottom line and those who are concerned with quality products. Those conflicts are exacerbated by the interpersonal tensions that lie not too far below the surface: needs for recognition or power, insecurity about job stability, or concerns about lack of competence and skill.

Paul, the user-interaction designer, made a mistake. He thought that his colleagues would be convinced by his research. He incorrectly assumed that they believed in the scientific foundations of his approach, but he was wrong: Their concerns were not addressed by the research. The more he repeated himself, the less effective he was in getting them to accept his conclusions.

bullet.gif Iterative Approach: Learning from What Happened

Paul decided to iterate, to consider how he attempted to get his views accepted and clarify how to do that more effectively. He realized that his presentation did not address the concerns of the marketing manager or of the developer. The marketing manager was worried about the impact on total sales, and the developer was worried about the amount of time required to do the programming. Paul developed a second iteration based on Guideline #1: taking short-term concerns into account.

Paul developed a different presentation, which addressed the issue of impact on sales. He demonstrated that his approach would result in lower sales in the short term but would build customer loyalty and willingness to purchase yearly upgrades, producing a longer-term gain. However, the marketing manager was not convinced by this approach any more than he was by Paul's first. Paul developed another iteration. Speaking with a friend who was in marketing, he learned that bonuses and promotions for marketing managers were specifically linked to quarterly sales; the marketing manager was not concerned with long-term profits. His salary was determined only by what happened in the short term.

Paul did not know what to do next, but he did know that he needed to take Guideline #3 into account, paying attention to the implicit personal concerns of his colleague. Paul spoke with his supervisor, who was supportive and reminded him that the CEO had recently announced a new initiative, asking everyone in the company to focus on developing brand loyalty and building the customer base for repeat sales. His supervisor discussed the issue with the CEO, who was a dynamic and effective presence in the company. The next week, compensation guidelines for marketing managers were modified. Paul received an e-mail soon thereafter from Larry, who now indicated that he had reconsidered his position and now found Paul's ideas very interesting.

Next, Paul considered how to approach Rosa and her concerns regarding the impact of this design on her schedule. Paul used Guideline #2, addressing short-term concerns concerning the schedule. He discovered that another group had used a similar process on its sales page and had already written code that could be used for the Web page for this product. He sent an e-mail to Rosa to let her know that he had found a solution that would allow them to use this design without affecting the schedule. Rosa did not respond to his e-mail.

After a few days, he realized that this iteration had also failed. It appeared that Rosa's explicit concerns did not reveal the underlying issue. Applying Guideline #3, he realized he needed to understand Rosa's underlying personal needs. Paul invited Rosa to meet for lunch. Rosa appeared surprised and uncomfortable but accepted. At lunch, Rosa became somewhat more relaxed, talking about her years of experience and pride in her skill but also expressing frustration that others did not recognize her competence. Paul realized that Rosa felt threatened and defensive when he rejected her original design. Paul was 20 years younger than Rosa, and Rosa resented Paul's attempts to tell her what to do. Paul decided to take a different approach with Rosa. He asked Rosa for help. When he returned to his office, Paul sent Rosa another e-mail with the subject heading: "Need your help!" In the e-mail, he sent Rosa some initial designs of screens for the home page and asked for her input on the layouts, fonts, and color schemes to be used. Rosa responded immediately with several excellent ideas and a few that were not. Rosa subsequently dropped her complaints about the new design for the Web page.

back to top  Case Example #2: Kara's new technology

Kara worked in the research lab of a large corporation. She was responsible for discovering, inventing, and incorporating new user-interface technologies into her company's product line. In the course of her work, Kara discovered a wonderful new technology that she developed into a prototype and tested with users. Kara produced some designs and descriptions of how to incorporate these user interface improvements into the company's product line.

bullet.gif Initial Approach

Kara wrote a report explaining the benefits of the new improvements. She cited data from her user test and offered to help the developers find ways to integrate the new technology into the user interface. The developer, Tom, felt comfortable with the technology but did not believe it was ready for commercialization. Tom felt that Kara had underestimated the work needed to incorporate it and did not think it was possible to include in the next release. Kara realized she did not fully understand the technical issues and decided to wait until the next release. Kara talked to the product manager, Jim, and asked to have the changes put on the product roadmap. Jim said he would consider it when they passed the current release. Kara waited.

bullet.gif Iterative Approach: Learning from What Happened

Kara realized that she needed to take more initiative with the developer and product manager. She also realized that she did not fully understand the issues. Using Guideline #2, she found a way to nurture their interest and cooperation, enlisting them to help implement the new technology.

Kara asked Tom to meet with her to review a prototype design she had developed. At the meeting, Kara was able to get Tom excited enough about the technology to agree to put the item in his schedule. She built the demo around the issues she thought were important in the product's development. At the meeting, Kara's initial goal was to get Tom excited by the new technology. She shared her excitement, showed him some of her preliminary results of tests with users, and focused on the potential for addressing needs of the users that the company viewed as very important. She also acknowledged to Tom that she understood that there were important technical issues, and she told Tom that she was interested in hearing about the technical constraints. Tom responded positively both to the concept and to Kara's interest in the technical details. He agreed to include the technology in the next release. Kara then approached Jim, the product manager. Because Jim was concerned primarily with the schedule, he was happy to include this technology in the specifications for the next release.

back to top  Case Example #3: Dan's Usability Lab

Dan had worked for large corporations for most of his career. Although he found the bureaucracy and administrative trivia tedious, he loved the work he did. In particular Dan enjoyed user-centered design projects that required in-depth exploration of issues, and he took time to do proper testing with several iterations.

Dan was hired by a remote office to build and run a usability lab for the software development team. The remote office wanted to set up its own team to work on an independent software project. This team had no need to interact with the larger development organization at the home office. Unfortunately for Dan, no one told him about the dynamics of the group when he started to build his lab.

bullet.gif Initial Approach

A product planner, Andy, asked Dan to submit several project proposals for next year's annual budget. Andy wanted Dan to work on a project being developed in the remote office.

The home office had a usability lab and a human factors team. They wanted to get more involved in the software development that the remote office was doing. The manager of the home office, Rachel, sent Dan an e-mail saying that she didn't understand why Dan had bid on the job. Dan was confused, and forwarded the e-mail to his manager, and to Andy. Andy reassured him that he wanted Dan and his lab involved in the project and told him not to worry.

Rachel also went directly to Andy and told him that her lab had the expertise to do the work for the project. She told him that she didn't understand why Dan was even at the remote office, since her lab provided everything the company needed.

Dan was caught between the home and remote office. He was blindsided by the force of the turf battle, discovering the realities only after the damage had already been done.

After a few years of wasting company time and energy on sorting out the politics, a vice president of the company held a meeting with all the parties involved. He told them that if they couldn't figure out a solution to the endless bickering, then he would do it for them, and they might not like his solution.

bullet.gif Iterative Approach: Learning from What Happened

Dan applied Guideline #3, paying attention to personal agendas and concerns. As soon as Dan received the e-mail, he called Rachel and asked to meet with her in person. He explained that he had not been aware that the remote office had a usability lab or human factors group and that he was happy to either fly to see her, or better yet, have her visit him.

Rachel didn't want to come to the remote office, so Dan went to see her. When he got there, he realized that Rachel's lab was twice as large as his, and that she clearly had a much larger budget than he did. Furthermore, her lab was right in the middle of the largest office and manufacturing section of the company's plant.

Dan realized he needed to make a strategic retreat. He explained to Rachel that he was a team player and wanted what was best for the company. When he was hired, he didn't realize there was another office doing work similar to his. He knew there was software development, but not enough to warrant another usability lab. He thought it would be best for the company if the two groups could work together. Dan suggested that they submit a joint proposal to Andy and let Andy decide how to best use the resources.

Dan also talked directly to Andy and explained the problem. Dan wasn't sure if Andy was aware of the situation but wanted to make sure everything was out in the open. Andy appreciated Dan's frank talk and agreed to consider the best option for the product.

After Rachel and Dan submitted a joint proposal to do the work, Andy decided he wanted the testing to take place in Dan's lab, so the developers at that remote location could watch the test. Andy said he wanted Dan to do the preliminary design, but Rachel was invited to review the work to ensure that it met the company's standards.

back to top  Conclusion

As UCD professionals we have made great strides in improving the usability design of our products. However, we still have some obstacles to overcome. We can resolve these difficulties through an iterative approach, paying attention to our working relationships, looking for opportunities to solidify trust, to identify the underlying issues, and to find creative ways to respond to them. These simple shifts in how we interact with our colleagues enable us to work more effectively and efficiently to meet our goals.

back to top  Authors

Elizabeth Rosenzweig, S.M.V.S.
Usability Professionals' Association and Eastman Kodak Company

Joel D. Ziff, Ed.D,
Ziff Consulting Group

Susan Dray & David A. Siegel
Dray & Associates, Inc.
2007 Kenwood Parkway
Minneapolis, MN 55405, USA
612-377-1980 fax: 617-377-0363

back to top 

©2003 ACM  1072-5220/03/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 © 2003 ACM, Inc.

Post Comment

No Comments Found