"When it comes to shipping quality software, design is not the hard part. Methods and techniques to study users, best practices for creating iterative designs, and tools to validate them are all very well documented. Unfortunately, in chaotic and complex ecosystems very few of the designs actually end up making it through the UCD process. Interaction designers’ input is either ignored or interpreted through a development/business lens and considerable fidelity is lost."I've been paying attention to obstacles to designs making it through -- or even into -- the UCD (i.e., User-Centered Design) process for many years. In addition to obstacles I have encountered directly, I have paid attention to obstacles encountered by others. For example, I used to compile lists of obstacles as experienced in the workplace by participants in my semester-long user-centered design workshop. These many dozens of workshop participants -- I taught the workshop several times -- worked in a wide range of companies, and the number of obstacles was so large that I separated them into groups, labeling each group with a higher-level obstacle which seemed to capture what was going on in the specific cases.
While I was learning about these many obstacles and developing the groupings, I organized a BayCHI panel comprised of Don Norman (then a VP at Hewlett Packard), Janice Rohn (then Manager of Usability Labs and Services at Sun Microsystems), and Dan Rosenberg (then User Interface Architect at Oracle), and I asked this panel to comment on whether the obstacles were genuine (i.e., are they really obstacles to designs making it through the UCD process?), why they existed, and what could be done about them.
Here is that list of obstacle groupings. As you read through them, ask yourself whether the obstacles are genuine, why such obstacles exist, and what can be done about them.
Ignorance, Misunderstanding, or a Different UnderstandingIt is interesting that the above list is still largely valid though I haven't offered that workshop for several years. Though much has changed over the past few years, many perceptions of obstacles to designs making it into and through the UCD process are still the same.
Those who need to buy-in to user-centered design (or "ethnographic" research or ...) often don't know about or understand it, or sometimes have a different view of what it is or when it should be applied.
Questioned Credibility of Non-specialist Messengers
Advocates' credentials are often challenged.
Questioned Credibility of User Experience Specialists
User-centered design (or ethnographic research or ...) personnel are often considered too "light-weight" (e.g., not "technical" enough, or not adequately business-minded, or ...), unable to communicate effectively with engineers or marketing personnel or executives, and unable to agree with each other.
Questioned Credibility of a Different Process
User-centered design, ethnographic research, etc. are often described as being "untested," "unproven," too "light-weight" (e.g., not technical enough, not statistically reliable, ...), ...
"I Can Do It Myself"
Collaborating with or involving others is difficult for some people and is sometimes perceived as weakness and/or unnecessary.
Powerful Personal Preferences/Biases
The perspectives of software engineers and others often inhibit acceptance of the perspectives of product or service users. (Users are seen as part of the problem, not a part of the solution.)
Discomfort with: Flexibility, Uncertainty, Imprecision, Not Getting It Right the First Time, ...
The nature of several aspects of a quality design process is strongly discomforting to many.
Competing "Religions"
Key elements of these methodologies are not completely compatible with existing, often entrenched and/or more technical development or marketing methodologies and practices.
No Rewards for Attending to User Needs
Rewards given within organizations often do not promote use or development of better methodologies and sometimes inhibit both.
Fragmentation of the Organization & of Responsibilities
Collaboration and adequate attention to the needs of product or service users are often made difficult by organizational structures and roles.
Frequent Organizational & Personnel Changes
Collaborating and maintaining attention to the needs of product or service users are often made difficult by rapidly changing organizational structures and personnel.
Insulated Developers
Technical development personnel are often separated from product or service users and are often protected from interaction with others to "keep them happy," "to not waste their time," and so they don't reveal things they shouldn't.
Inaccessible Users
Product or service users are often "protected" from interaction with developers; plus, users are sometimes located too far away and are even sometimes unknown.
Marketing Personnel Are Already Responsible for Customer Contact
Management often believes that attention to customer or other user needs is already covered.
"Buyers Are Not Users"
Salability or acceptability sometimes have little to do with usability or usefulness; a focus on features or the needs of the people who make the choice can dominate.
Increasingly Large System Size and Scope
Market or other forces push for added capability, making the task of meeting the needs of different types of users and uses more difficult and time-consuming.
Short Life Cycles & Development Schedules
Market or other forces minimize design time and flexibility, leaving what is often believed to be inadequate amounts of both for ethnographic research, user-centered design, ...
Immediacy Is Most Important
Organizations are often much more reactive and task-oriented than anticipatory & process-oriented. Hence, user needs are often discovered late and addressed via "fire fighting," which must occur quickly and usually has a short-range focus.
Small Staff and/or Budget
Many organizations believe they can't afford (in personnel or money) good user-centered design or ethnographic research or ...
User Experience Is Not Perceived to be an Issue
If there is no serious competition, or if only abit of functionality is being added, or if targeted users are believed to be highly technical, or if there is no direct user interface, or if ..., some organizations believe they don't need good design or research.
There are definitely some obstacles not encompassed by the above groupings; indeed, Luke and his CHI 2006 paper co-authors identify a couple. And I wonder what list I'd come up with if I did the grouping process today, even with only the old obstacle stories and lists.
What obstacles do you encounter? Do you encounter any not addressed by the above list? Which items in the above list do you encounter where you work but are not actually obstacles to UCD? Are there any obstacles in your workplace to which you might be contributing?
Don Norman appeared on the BayCHI program a couple of times before he appeared on the BayCHI panel I mentioned above. The title of his talk during his first BayCHI appearance way back in February 1993 was, "Where HCI Design Fails: The Hard Problems are Social and Political, not Technical." During an on-stage interview just a year and a half ago, I asked Don whether the assertion he made in that title was still true. He answered without hesitation: "yes."
