As a member of Usability Professionals’ Association Board of Directors (and now President), I have been fortunate to be involved in the UPA’s user experience salary survey project. I actually wrote the 2005 report and just finished the 2007 report, the full version of which is now available to UPA members at this URL. (A free version is available to the entire UX community here.)

One thing we noticed back in 2005 was the marked difference in salaries between men and women in the UX field. In 2005 we found that the gender gap was about $8,500 USD: the median salary for men in the UX field was a bit more than 80K; for women, 72K. This finding got a bit of attention in the part of the blogosphere concerned with user experience.

We also found upon further analysis that the gender gap seemed to have narrowed slightly between 2000 (when UPA last did a salary survey) and 2005. But the gap narrowed by only $1,000 USD in those five years.

With the 2007 report in the can I am happy to announce two findings: One is that average and median salaries in the UX field increased since 2005. The average salary in 2005 was $78,466 (median = $75,000); in 2007 the average salary was $83,297 (median = $80,643), representing an increase of $4,831. (The median salary increased $5,643.)

The second finding is that the difference in average and median salaries between men and women has narrowed. The average salary for men increased $2,878 from late 2005 to late 2007; women’s average salary rose more than twice this amount, or $6,384. (Median salary for men increased $5,000; for women, $7,000.)

I am of course happy about this from the social justice perspective. And I have more personal reasons to be happy: my wife also works in the user experience field.

(Originally posted June 2005 - P.S.) 

In the last entry I argued that enterprise software often falls short of the mark when enterprise vendors don’t pay sufficient attention to the specific wants and needs of the intended users.

I claimed that this happens because enterprise software vendors don’t set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.

In this entry I’ll relate some case studies where negative outcomes could have been prevented. I’ll also discuss why the factors that contribute to these poor outcomes seem to be persistent.

In the next post, I’ll provide examples of how to justify usability for enterprise software, and discuss a model for creating and deploying enterprise software that will result in more positive outcomes.

In the last entry I argued that enterprise software often falls short of the mark when enterprise vendors don’t pay sufficient attention to the specific wants needs of intended users.

I claimed that this happens because enterprise software vendors don’t set goals for the learnability and usability of their systems, and because the enterprises themselves don’t hold vendors to high enough standards of application learnability, usability, and efficiency.

I this post I relate case studies where negative outcomes could have been prevented. I also discuss why the factors that contribute to these poor outcomes seem to be persistent. Finally, I relate a model for creating and deploying enterprise software that will result in more positive outcomes.

Case 1: The “Business Intelligence” System
The technical support group for a major financial software application was responsible for generating weekly and monthly reports on calls to the help desk. Statistics on call burden, call reasons, call resolution time, hold time, post-call work time, and other statistics tracking cost and rep productivity were summarized for management. The process of producing the reports was mostly manual: the data resided in three separate systems, data was extracted via complex (though mostly repetitive) queries, and reports were generated and formatted in a spreadsheet application.

Other groups within the organization - product management, development, user-centered design, and quality assurance - frequently requested custom reports and raw data from the amalgam of systems. Individuals within technical support and the IT group were sometimes overwhelmed trying to deliver their regular reports and comply with “outside” requests.

The business decided to deploy an enterprise-level application enabling support to centralize the data, automate data retrieval and report production, and provide outside groups with the ability to self-service their data and reporting needs.

Upon deploying the application the business discovered that, even after support and IT staff trained to proficiency, it took 5 to 10 times as long for staff to extract data and produce reports. What these groups discovered was that the application’s user interface, which was presented via a Web browser, only allowed users to drag and drop date ranges, field names, and other delimiters into a “reporting wizard” form. Complex queries that previously took 5 -10 seconds to type now took 2 or 3 minutes to drag, drop, delimit, and run. These users, with considerable technical abilities and expert-level knowledge, were essentially forced to interact with the system as if they were neophytes).

Furthermore, the reports were formatted into static HTML. Once produced, users were unable to reformat, rotate, or otherwise adjust the output. Although the simplistic process of query-building proved easier for occasional users from outside groups, the inability to manipulate the output proved frustrating. As a result, support and IT staff were again forced into a bottleneck role, laboriously creating reports to comply with outside requests for reports. Within six months, the technical support group had brought their old systems back on-line, and reverted to their previous process.

Case 2: The Expense Reporting System
A large telecommunications equipment manufacturer decided to move from spreadsheet-based expense reporting to a system that enabled users to input expense information directly into the company’s accounting system. The application promised to eliminate manual steps, including double entry of data, remove data entry bottlenecks, and streamline the accounting process.

Employees at this company had an inkling that the new system might pose difficulties when, two weeks prior to the system rollout date, HR disseminated a 50-slide training presentation to all employees. This was followed up by a mandatory, all-employee desktop video training session in the use of the new system. The training session, developed jointly by HR and IT, was 1.5 hours long.

The productivity lost to training for the new system was a significant expense, as was the projects related to producing training. These expenses were dwarfed by the time and expense lost when the system went live.Everything about the application’s user experience was a mess. The process employees followed to enter, describe and categorize expenses was confusing, long, and ill-thought out. The screens to capture the data were poorly designed. The terminology used throughout the application, while familiar to finance and accounting professionals, was opaque and unclear to most other employees. Information was presented in illogical formats; users were forced to scroll through 200-item drop down lists with nonsensical ordering.

Successfully submitting an expense report, which had previously taken only a few minutes, was now a half-hour undertaking fraught with error and frustration. As a result, productivity and morale suffered. Worse, compliance waned and systemic errors were propagated through the accounting system: some employees simply stopped expensing small purchases, or assigned expenses to accounts that appeared near the top of long account lists.

The Vendor’s Lament: If You Build It, They Will Complain
With their page-spanning feature matrixes, long lists of supported platforms and databases, ROI calculators and downloadable case studies, the enterprise application provider makes fantastic promises. However, many enterprise software development environments don’t adequately incorporate users’ specific wants and needs until too late in the engineering process (if at all).

So why weren’t the users’ wants and needs represented earlier in the development lifecycle? There are many reasons. They can be boiled down to this short list:

• The application is built to satisfy the vendor’s perception of users’ needs, not users’ actual needs.
• Engineering groups own too much responsibility for user interface design.
• “Featuritis”

The vendor is not the user: Often, applications are built without incorporating the perspective of actual user groups. Product managers, requirements analysts and engineers make assumptions about users, instead of observing them and asking the users themselves.

Gathering users’ wants and needs is not difficult, but it’s important to do it right. It’s remarkably easy to gather user needs poorly or incompletely, resulting in a biased or incomplete perspective of users’ wants and needs.

The key to developing an accurate picture of user needs is to distinguish the main user groups (and how the groups differ), then identify the users’ skills, tasks, and needs in the role they assume while using the application. It’s also helpful to usability test conceptual prototypes with actual users from the target customer groups. In this way, early concepts and designs can be tested and iterated very inexpensively.

Engineers are not the users: In many development organizations, engineers are given responsibility for transforming requirements into user interactions, process flows, and screen designs. What results is a user interface that reflects engineersâ’ mental models. Their models for how things work differ drastically from users. Consider this example:

• The engineer: “It’s a state-persistent container for database objects…it requires authentication and setting of cookies, etc etc…”
• The user: “It’s a shopping cart.”

Indeed. To the engineer, it is in fact a “state-persistent yadda yadda.” But not to the user, it ain’t…

Featuritis: Featuritis is a pernicious malady. Both vendors and purchasers contribute to this disorder. Here’s what typically happens on the vendor side of the equation:

• “Competitor A has these 5 features…competitor B has those 10…we’d better put them all in our next release.”

This kitchen sink approach leads to a mishmash of features, with no organizing principle or overarching information architecture.

And purchasers, well, they buy applications with undocumented usability in the door because they don’t know any better. The evaluation and decision-making process for enterprise applications usually looks like this:

• The need for a better, more scalable, faster, etc. process is identified.
• The business case is established.
• The IS organization sets technical and feature requirements (often informed, in somewhat circular fashion, by vendors’ application feature lists).
• Vendors are solicited, and sometimes asked to respond to a Request for Proposal, or RFP.
• Vendors are evaluated on the basis of their responses, and a short list of vendors is generated.
• Vendors’ systems are often brought into the enterprise’s test labs for performance and technical trials.
• A vendor is selected, and the deployment project is undertaken.

This process typically does not provide methods for evaluating the goodness of fit between the enterprise users’ processes, wants, and needs and the vendor’s solution. Many a rollout disaster could have been avoided simply by usability testing a vendor’s solutions with employees during the trial phase.

Solution:
I propose that user-centered design methods and usability testing can aid both applications producers and application purchasers.

Application vendors can utilize user centered design methods as a competitive advantage, to produce solutions that meet the enterprise users specific wants and needs.

Enterprise customers can utilize usability testing to ensure that the IT investments they make deliver fully on their value propositions.

In the next post on this topic, I’ll provide examples of how to justify usability for enterprise software, and a model for creating and deploying enterprise software that will result in more positive outcomes.

(Originally posted April 2005 - P.S.) 

Enterprise software products are complex, powerful tools. This complexity is one of the reasons businesses sometimes don’t fully realize a positive return on investment from these products.

For enterprise employees who must use the enterprise application, their complexity poses a considerable challenge. When an application is deployed, users are expected to learn the new system, integrate it into their existing work processes, and become proficient enough to allow the organization to realize the system’s full benefits. Far too often, however, enterprise employees find these new systems hard to learn, hard to master, and difficult to integrate into existing processes.

Enterprise software, which broadly encompasses functions such as enterprise resource planning and management, customer relationship management, supply chain management, project portfolio management, and business intelligence, is a multi-billion per year industry Well-known vendors include BMC, Business Objects, Hyperion,  PeopleSoft, Oracle, SAP, and Siebel, to name a few.

Most Fortune 500 companies have multiple enterprise software products installed and many mid-sized business are either actively considering or have implemented solutions. As the market has matured and vendors have searched for new growth opportunities, even small businesses with fewer than 100 people have options available to them from enterprise software makers.

To the growing company, enterprise software promises to convey benefits in a variety of areas, for example:

• Centralizing customer information from sales, marketing, customer service, and support to improve customer service and enable better prospect identification.
• Identifying and managing enterprise-wide resources needed to receive, process, and account for orders.
• Gathering, storing, analyzing, and providing access to data to enable enterprise users make better business decisions.
• Tracking and organizing information related to project planning, tracking, and resource management for multiple projects, enabling an enterprise-wide view of project scope, resource allocation, risk, cost, and performance.

Complex stuff.

From the CTO’s and IT Director’s perspective, these promises assume that the internal user groups can and will learn the new systems and incorporate them into their work processes. But these outcomes are far from assured. Some of the problems and pitfalls:

• Some businesses find that their employees’ productivity decreases because common or critical processes actually take longer using the new application.
• Others fail to realize an application’s benefits because users “vote with their fingers” and don’t adopt the new system.

Businesses can also experience reduced employee morale and increased turnover related to the imposition of new systems and processes. There will always be employees who resist change in any form. However, if the business mandates process changes and deploys systems that users perceive as difficult to learn, use and remember, the user population will see it as a change for the worse. In this situation morale will decline, and the sufficiently disgruntled will leave.

IT organizations responsible for supporting an enterprise application can find themselves overwhelmed as they struggle under unexpectedly high numbers of support requests that often accompany an application rollout. As anyone who’s worked the help desk knows, rollout day for a complex application often seems like the perfect storm for Level 1 support staff.

Why do these scenarios play out in organization after organization? I argue that two factors are driving these outcomes:

1. Enterprise software developers don’t pay sufficient attention to the specific wants needs of the internal user groups.
2. Enterprises don’t hold their vendors to high enough standards of application learnability, usability, and efficiency.

In my next post, I’ll discuss:

• Some case studies where poor outcomes could have been prevented.
• Why the factors that contribute to these poor outcomes seem to be persistent.
• A model for creating and deploying enterprise software that results in more positive outcomes that these products can deliver.

I don’t know if this happens to you other bloggers… a few weeks ago I had a GREAT idea for a post, and didn’t want to write anything else until I had written the great post. As a result, I got completely blocked up and stopped writing for a while. So I haven’t posted a darn thing in weeks.

Anyway, since I have little to say here at my own little node of the Interwebs, I’m going to point you to my latest UXmatters article. It’s about an interview I conducted a few weeks back with Eva de Lera of the Open University of Catalonia. She and her colleagues are developing measures to assess users’ emotional reactions to user interfaces. Article link is below.

How Do Users Really Feel About Your Design? :: UXmatters

Blogged with Flock

Tags: UI, emotion, affect

A friend pointed me to a whiny screed from one of the normally smart-and-perceptive folks at Adaptive Path.

In “Why Usability Is A Path To Failure“, one Todd Wilkens makes some interesting claims. One suspects he had a bad client day, and just couldn’t take one more client asking whether their design was going to be usable. Here’s what he said:

So, why oh why do people in this day age still hold up “usability” as something laudable in product and service design? Praising usability is like giving me a gold star for remembering that I have to put each leg in a *different* place in my pants to put them on.

It touched off a poopstorm of comments (which I suspect is one of the other reasons he wrote such an inflammatory post), the best of which comes from Jared Spool:

Todd, I think you have a very narrow notion of what “usability” is…Usability, like all design when done well, becomes invisible. People don’t talk about the positive case. (Well, except for designers who constantly need to bring attention to their work.)

…

Usability is foundational, such as having good content and providing reliable uptime. It’s only *not* a differentiator when everyone has equal amounts of it. If yours is better than everyone else’s, it become a differentiator.

Usability can be measured on a scale of extremely frustrating to extremely delightful. Since different designs competing for the same audience can occupy different locations on the scale, you can differentiate one design from another using it. That’s the broader definition of usability that most of us tend to use.

Props to Jared who very articulately explained why the writer was wrong. Still worth a read to gawk at the mile-long trail of comments.

http://www.adaptivepath.com/blog/2007/07/17/why-usability-is-a-path-to-failure