UX Magazine logoThe Magazine of the Usability Professionals' Association

Enterprise Usability Maturity: Designing an Enterprise Application Suite

By Jeremy Ashley and Kristin Desmond

The Usability Maturity Model
Inspired by similar models for software development and quality assurance, the Usability Maturity Model synthesized by Jonathan Earthy in 1998 defines six levels of capability in human-centered processes that can describe an organization. The six levels are:

For this article, we have informally assessed the levels in use at Oracle Corporation; however, the complete methodology, as presented by Earthy, includes a more formal recording of form and scale.

The Problem
UCD professionals are highly trained in their individual sub-disciplines but are often unprepared for the challenge of fully implementing UCD to produce a finished product. Occupied with user research, design, prototyping, and usability testing, UCD professionals are often shocked when some or all of their work is not applied. This disconnect occurs when UCD professionals do not consider their organization’s readiness to accept their work or perform the non-UCD processes needed to ensure success.
 
A Case Study
In 2005, Oracle started a new development cycle to design and build a next-generation integrated enterprise application suite. The vice president responsible for the project had worked with the UCD process in the past, and he understood that UCD would produce a more usable product. As usability was an important differentiator for the product, he consolidated the enterprise applications UCD staff into one team that reported directly to him. As further evidence of his commitment to the team’s success, he also granted the organization a generous number of new positions.

Initial Analysis
At the start of this process, the UCD team analyzed the historical effectiveness of its various working styles and noted areas where they needed improvement. The newly joined teams agreed that they had, on average, achieved a Usability Maturity Model level of Implemented in their previous team’s practice: they had dedicated teams of UCD professionals who performed the complete process to support their product teams. In addition, all the teams adhered to company-wide user interface (UI) guidelines and standards. Some had managed to institute UI code reviews to ensure compliance to these standards.

However, these processes were applied inconsistently across products. Some development teams were still saying that they didn’t have time to incorporate all of the UCD team’s recommendations. Users were still complaining that products were too technology driven and that the software was hard to learn and use. There were also numerous places in the products where the UCD teams had identified missing functionality that could greatly improve user productivity, efficiency, and satisfaction.

While we did not consciously use the Usability Maturity Model levels in our thinking at the time, the push to function fully at the next level—Integrated—was a key factor in our overall success.

At the Integrated level, the following things occur:

In the beginning, the technique that our organization adopted was to push harder on the UCD front. We knew that the teams needed more UCD to improve their products; however, the teams resisted the move toward this more unified approach to UCD, and we were having trouble understanding why. After all, everyone was saying that we needed to improve the products.

At this discouraging moment, we decided to use some of our headcount to hire program managers and developers. We had seen that one issue our UCD teams faced was employees spending too much time on process management or technical problems—not their area of expertise. We reasoned that by hiring product managers and developers we could free up our UCD people to focus on their specialty. This assumption proved true, but the greater value came when these new team members opened-up a way for us to reshape how our UCD organization functioned within the larger process.

Learning More about Our Internal Audience
We used the ethnographers in our organization who normally worked with users and customers to conduct an internal ethnographic study to help us better understand what our product management and development counterparts thought about UCD, how our team functioned, and how UCD could help them make better products. From this we learned three key things:

Effect of Our Program on Managers and Developers
The new program managers on our team helped us understand what we needed to do to become fully integrated with the formal development process. Because the development organization was redefining this process in conjunction with a major release, the timing was ideal. In the beginning, a lot of what we had to do was explain our process and requirements to the team responsible for defining the new development process. Once others began to understand our role and include us in the process, the tables turned. We had to take a critical look at the quality and consistency of our deliverables to ensure that they were presented in a way that all audiences could understand, and addressed the concerns of all stakeholders. We also had to make sure that all members of our team understood how to create these deliverables consistently.

Because the development project included a new user interface for every product, our team would not be able to do all the work. We needed to document the mandatory user experience deliverables in such a way that product managers could complete them as well. Had we not done the prior ethnographic work, it would have been much more difficult to do this well.

Even with our up-front ethnographic work, we had to iterate the user experience part of the process a few times before ultimately defining a three-tiered support structure to which all teams had to adhere.

We also began to define standards for our team to adhere to, including properly using the existing bug filing and tracking process for all user experience issues. When there were issues on which we disagreed with the design direction or approach of a particular team, the development process itself ensured that we discussed the issues and resolved them appropriately and on time. We made our process visible to other functions using the same tracking and metrics as the rest of the organization.

Our program managers then helped us translate our UCD process to our executives and other team members and then translated their language back to us, ensuring that everyone was clear on the process.

Figure 1 shows what the process evolved to over time. We were instrumental in generating this diagram, which became an effective teaching tool for all the teams involved.

Our developer and UCD architect team members participated as members of functional and technical working groups. They helped us understand how the UI would be delivered and what we needed to provide to the technical teams in order to ensure that we could build the UI that our users needed.

Their work also gave us the opportunity to influence technical direction. Historically, our thoughts on technical issues had been poorly received, taken as the agitations of clueless outsiders. Now that we were participating on the relevant working teams, however, our input was taken seriously. We facilitated communication and cooperation among development, strategy, and product management and became, in many cases, the main conduit that led to the understanding of the solutions.

As a result of these actions, we have successfully carried out the UCD process and avoided wasting time and effort justifying our process and resolving inter-organizational conflicts. The company now better understands the value and use of UCD, and UCD has a voice and a role to play at all phases of the process. Most importantly, the design of the application suite itself now provides a significantly more integrated, satisfying user experience.

Fig. 1

Ensuring that UCD Provides Maximum Value

Get Top-Level Commitment to UCD
Top-level commitment to UCD means that the organization recognizes that “usability” and UCD are strategic elements of the product offering. The organization may not understand all of the implications of applying these elements, but it knows enough to make an investment. Top-level commitment is demonstrated in three ways:

Integrate with the Process
Integration with the process means that UCD is not a side activity whose outcomes may affect the product only if time permits at the end of the cycle. UCD is a full partner in the development process with all of the other players: strategy, development, product management, testing, and so on.

To ensure integration of UCD in the development process, a company must:

Conclusion
Instead of attempting to directly convert our organization to the language of UCD, we learned to communicate in the terms of product managers and developers by incorporating their disciplines on our team. We introduced by example more detailed aspects of UCD as a normal and accepted part of the process. As a result, UCD is well-represented in all stages of our process, from strategy, to planning, to execution. As we look forward, we see our organization beginning to function at the Institutionalized level, where the organization as a whole is human-centered in its focus.UX

Jeremy Ashley is vice president of Applications User Experience at Oracle. He has built a large, multidisciplinary organization, bringing together the former user experience teams from Oracle, Peoplesoft, JD Edwards, Siebel, and Agile to meet the challenges of defining and delivering the user experiences of the next generation of enterprise applications. He previously worked for Taligent and Apple Computer, and formerly supported Oracle’s business intelligence, data warehousing, and CPM applications. He is a member of the Design Management Institute, is a regular contributor to the CHI and UPA conferences, and publishes regularly on issues relating to design management. He has advanced degrees in Industrial Design and Computer-Related Design from the Glasgow School of Art and the Royal College of Art in London.

Kristin Desmond is a user experience architect at Oracle in the Applications User Experience organization. She specializes in design management and talent management and has previously managed teams responsible for human capital management, sales, and supply chain user experiences. In her long tenure at Oracle, Kristin has worked on server management and data warehousing applications, among many others. She has previous work experience as a technical writer and an architect. She has a BA in Architecture from UC Berkeley.

UPA logo
Usability Professionals' Association

promoting usability concepts and techniques worldwide

User Experience Magazine is by and about usability professionals, featuring significant and unique articles dealing with the broad field of usability and the user experience.
http://www.usabilityprofessionals.org/upa_publications/user_experience/

This article was originally printed in User Experience Magazine, Volume 9, Issue 1, 2010.
http://www.usabilityprofessionals.org/upa_publications/past_issues/2010-9.html.

© Usability Professionals' Association
Contact UPA at http://www.usabilityprofessionals.org/about_upa/contact_upa.html