As usability practitioners, we have embraced the philosophy of user-centered design and strive to devise systems that adapt to the user's needs rather than forcing users to accommodate the system. Enterprise software designers are no different; most of us profess to follow a methodology grounded in the principles of UCD. But the reality is that enterprise software designers must often conceive systems that deliberately make the primary user's life more difficult. Consciously or unconsciously, we do this because sometimes it's more important to support a business process than a user's task.
Every interaction designer's life is fraught with compromise. Marketing demands the inclusion of branding elements that push important information to the bottom of the page "below the fold;" engineering demands simplified interactions so they can spend more time coding the back end; product management demands thrilling features that unnecessarily complicate the design. The art of usability lies in designing a good user experience despite the limitations of current technology, release schedules, and project budgets. But interaction designers who work with enterprise software have the additional burden of considering the customer's business needs. When the end user's needs and the business's needs collide, take a step back from task analysis and consider the ultimate goal of your design in order to find the right compromise.
For example, I recently worked with a team designing a Web-based project management tool. One of the primary business requirements for this tool was to allow line-of-business managers to get an overview of the health of each project in their organization. To do this, the system needed to track data about project timelines, milestones, and resource availability. Not surprisingly, most project and program managers in our user research used Microsoft Project or a similar desktop tool to help them do their job. Somehow, in order to support the project-monitoring requirement, the data that was being tracked in Project needed to be imported to our Web-based system.
Finding the right solution proved to be difficult. At first we considered building a system that allowed the primary users of the system, the project and program managers, to import the necessary data from Project. Though an extra step was required in their workday, at least they could continue to use a tool they were familiar with. But the system we were designing needed to track more information than what Project provided. So Project users would need to enter extra data about each project and resource into the system. Also, once the project information was in the system, it could be modified as managers reviewed the portfolio of projects and reallocated resources or reprioritized projects. How was this updated information supposed to get back into Microsoft Project? Few users would want to deal with a constant import/export cycle in order to keep everything in sync.
Our next inclination was to recreate a Microsoft Project-like interface in our Web-based system, since that's what users would be accustomed to. Unfortunately, it was impossible to recreate the richness of the Project UI with our current Web-based technology. We knew the UI in our system would wind up being a series of tables and Web forms that required significantly more effort to use than the Project UI. We could build a useable UI, but it would not be as efficient as the one to which they were accustomed.
It was a frustrating position to be in. The usability team is supposed to be the advocate for the user, yet we were designing a system we knew would make the most frequent users of the system unhappy. After vacillating over what approach to take, we realized we'd lost sight of the ultimate goal of the system. The increase in effort required to track project data was necessary to enable the company to have greater visibility and control over its projects. There was no way around itin order to satisfy the business requirements, the project and program managers were going to have to spend more time working on a system instead of accomplishing their primary task of managing their projects.
Supporting the business's ability to extract project health information was more important than optimizing the project manager's task flow. From that point on, we did our best to build out the project health dashboards and other cross-project management features so that users would feel like the increased effort required to get project data into our Web-based system was worthwhile.
Other examples abound. A colleague talked about redesigning a time and expense application that purposely increased the number of steps employees had to go through in order to get reimbursed for expenses. The point of the redesign was to reduce the labor involved in approving expense reports, not the labor involved in submitting them. Employees were initially unhappy with the system, but soon stopped griping when they realized how much more quickly they received reimbursements. The efficiency is gauged here by the user goal: getting reimbursed quickly; not by the user task: filling in their expense reports.
Compromise isn't fun, but it's inherent to our profession, whether it's ripping out an interaction the developers can't support or adding complexity to support an important business process. Creating an exceptional system often requires the designer to have a panoramic view of the problem space. The creation of a system is intended to satisfy an objective, and the objective is not always improving task flow or reducing the time to complete a task. Keeping the ultimate objective of the system in sight will help designers make the necessary compromises.
About the Author:
Dustin Beltram is a senior interaction designer at PeopleSoft. With stints at companies such as IBM and Rational Software, he has spent the bulk of his waking hours over the past ten years designing software for corporate users. When not in front of the computer (where he spends entirely too much time), Dustin likes to read science fiction, futz with his camera, and marvel at the human factors issues encountered by his new baby boy.
©2005 ACM 1072-5220/05/0700 $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 © 2005 ACM, Inc.