Jeremy Ashley, Kristin Desmond
With the proliferation of digital products, including computers, desktop and Web-based applications, and mobile and embedded devices, the quality of the user experience (UX) has become one of the key determinants in the success of competing products. Productivity, entertainment, and business-application programs for non-technical users in particular must have “intuitive” interfaces.
In the realm of business software, deals are increasingly won as a result of the “prove it” demo, during which a customer evaluating a software purchase may have the sales teams from competing companies in different conference rooms and moves back and forth between them. Even so, although the software development firms that produce business software products see user interface design and usability engineering as important, many still do not accept them as integral parts of their product development cycles. Typically, the needs of product marketing and engineering prevail over those of users. Most of these firms know that their digital products need good user interfaces and that their product teams need dedicated UX professionals to design them, but very few know how to employ these professionals effectively. They often perceive user interface design and usability activities as being primarily about enhancing the visual appeal of a product and, through usability testing, finding errors or usability problems with individual Web pages or dialog boxes. Design managers need to change this perception by applying processes and techniques that enhance communication, prioritization, and cooperative goal setting.
In contrast, consumer product companies employ traditional design-management techniques for both industrial design and brand identity development. Design management is, essentially, the process of making design an integral part of a company’s culture and a commitment to shipping well-designed products. Such companies actively integrate their design organizations with their research, product management, and marketing organizations, because product design is closely associated with brand. Their product design and definition phase is separate from their engineering and production phases. Much of a product’s design is complete and fully tested well before the production engineering process beginsoften a year or more in advance.
In the software development process, it is much more usual that only part of a product’s design work is complete before the development cycle starts, and the design of the product changes frequently throughout the development and testing phases. This is popularly referred to as “building the plane while you are flying it.” Although many see this as the reality of a software development process, we maintain that this way of working is generally inefficient, costly, and produces poor-quality products with inconsistent user interfaces.
Successful user interface design requires:
- multidisciplinary product development teams
- designers who can mediate between management, marketing, and development, and negotiate good resolutions of design issues
- designers who can shepherd products to their completion
At conferences, UX professionals typically hear about the process of user-centered design or how to design a particular type of product or feature, but rarely hear about how to facilitate the inclusion of design management in the product development cycle and successfully ship a well-designed product.
Q: What Is the Problem? A: People, People, People. Doing good design work is actually the easier part of the software user interface design process. There are many highly skilled designers and usability engineers who have the education and experience necessary to design and test products and are familiar with good design process.
The real challenge lies in getting their designs realized in a product. Many designers are wont to forge ahead and attempt to solve their immediate design problems, and then experience frustration when others aren’t receptive to their work. To get our designs realized, we need the cooperation and participation of other people in our companies. Gaining this is no small task. Consider how many people have a stake in the success of a product’s design: the user interface designer and usability engineer, of course, but also the director who owns the product, the product manager who determines what features go into the product, the developer who codes the product, the salesperson who deals directly with customers, and the executive who is directly responsible for the product line or even the success of the whole company.
Users Who? All of these constituencies feel that they understand their product’s users, and they all do, from their own perspectives. The user interface designer and usability engineer understand the users with whom they come into direct contact through their user research and usability activities. The development managers feel they know their users’ needs, because of the domain knowledge they have acquired over years of supporting the product. The product managers and salespeople feel they know the users, because of the feedback they have received from their customers. And the executives feel they know the users, because they know what makes or breaks deals and are responsible for the continued health of the company.
Of course, all these different perspectives on the users are fraught with potential misunderstandings. Following typical usability methodologies, UX and usability professionals go to great lengths to recruit users for usability testing who represent typical users of the product. Thus, they feel confident that they can obtain representative information about the product’s users. The product managers and salespeople come into contact with customers, who are often purchasing the software for use by others and take into account technical requirements and costs above user experience. Developers and executives feel a high sense of ownership of the product and see themselves as typical users.
Although each perspective may be correct in its own way, when these individuals gather in a room and talk about user needs for a product, each is coming from his or her own particular perspective. They frequently take the user’s name in vain! There is often no common understanding of who the user is or awareness that there are a number of audiences for a product. The product team needs to consider the needs of each audience without invalidating the needs of the others.
Design What? Another challenge is understanding the context of the software design and development process within an organization. The UX professionals on a product team may follow a full user-centered design process, but to get buy-in for the process and the resulting design is another matter entirely. Often, only the UX professionals in a software development company practice user-centered design, with co-opted assistance from a few understanding product managers and developers. In this case, user-centered design is not part of the core development and release process. In contrast, at consumer product companies, the user-centered design process is increasingly integral to the product development process.
Keep the long-term picture in mind, even as you are working at a more detailed level. Doing so prevents you from getting too bogged down when the process is not moving as smoothly as you’d want.
Influence without Authority. Another challenge is organizational structure. In software companies, UX groups may reside in many different places within their organizational hierarchies. In some cases, UX professionals are engineers who belong to the development organizations for their respective products; in others, they work in centralized teams supporting many products. In still others, they are part of product marketing or report to the CEO’s office; and in many cases, UX work goes to consultancies.
We’re Building What? Another problem is what actually gets built. Since the design process is not well integrated into the overall development process, product teams often make decisions about what features to include based on how much time the team has or how hard a problem is to solve rather than what features make sense according to the needs of the product’s users. Unlike the traditional industrial design process, the software design process is susceptible to these problems, because the product team does not fully define the product before development begins.
Principles for Success. Software companies can remedy this challenging situation by applying some key principles. A product design process has four dimensions:
- design, including research and development
- user validation, or usability testing
- design practice
Through cycles of design and usability testing, UX professionals define and develop products. However, design practice and communication are the dimensions important to actually getting products built, and they are the more challenging dimensions. Finally, an element of considerable importance that people sometimes overlook is the personal style of designers.
Communication. There are five important principles of effective communication that UX professionals should follow.
Formalize Communication Formalizing communication is the easiest and most controllable element. When you present your work professionally, it inspires confidence. A well-organized design Web site that includes current and historical designs, lists of issues with their current status, and access to relevant usability reports is one example of formalizing communication.
Manage Expectations One of the worst relationship killers is a perceived lack of dependability. If you say you are going to do something, either do it or, if things change, immediately inform all affected parties and reset expectations.
Facilitate We cannot expect development teams to handle the design management process; that’s our responsibility. But it is important to educate them about the process and involve them at all crucial stages in the process. In the spirit of teamwork, draw others into your process. By facilitating the design of their products’ user interfaces and making their products better, we can show them the value of what we do.
Respect Cultural Differences Development teams have distinct cultures of their own. Don’t try to impose your user-centered design culture on them. Instead, meet them where they are and identify where you can add value. We look at our relationships with our client teams as long-term investments. Every release of a product presents another opportunity to influence the process.
Always represent yourself and the design process honestly. To make effective use of what your team has to offer, a development team must be able to accurately gauge what it is you do and trust you.
Identify Common Goals In the end, we want the same thing that product teams want: to ship good products, be successful in our jobs, look good to our management, and hopefully, get paid more.
Practice of Design. The practice of design is the way we execute our craft.
Deliver Quality Quality is not simply creating a design that wows the product team. It is usually the result of considering more-subtle aspects of design like matching the scale of the solution to the problemnot over- or under-designingand innovating where appropriate and valuable rather than for innovation’s own sake. Too ambitious a design will turn off the product team.
Be Proactive Designers who are proactive look for ways to work smarter. They are adept at independent problem solving. They look for ways to refine their designs by bringing people together and negotiating a compromise or by exploring alternatives, including the possibility that there may be no need for a design. They facilitate results.
Be Resilient Resilient designers have the “We have lemons; let’s make lemonade” attitude. They know when to make trade-offs and can identify opportunities. They are adaptable when the process is not going smoothly and avoid taking issues personally.
Personal Style. You can’t fake personal style. To gain trust, you have to show yourself to be trustworthy. You meet your commitments and are accountable for the work you produce. All of this ultimately defines your credibility.
Development Example: Next-Generation Business Intelligence Tool. We were able to put these principles to use on a project when we took on the UX design for the next generation of a business intelligence tool. When working on the previous version of the product, the development team and the UX team had not worked together as effectively as they could have. The development team did not believe the UX team had the required knowledge or were dependable, so they planned to design the product themselves. The UX team thought the development team did not have a clear plan and, because of a recent management change, the decision-making process in the development and product management organization was unclear. There were no key decision makers; therefore, feature plans were in a constant state of change.
The design challenges themselves were considerable. The product was Oracle’s premier business intelligence application, supporting ad hoc query, analysis, and reporting. The team was rebuilding the product in Java, while adding new features.
Since the UX team was responsible for meeting corporate goals such as following standards and guidelines, using particular technologies, and being responsible for maintaining the quality of the products through usability testing, we needed to regain control of the UX effort. To do this, we decided we had to put ourselves in a position to have a controlling influence over the schedule (Be Resilient, Be Proactive).
Our first task was to understand the lay of the land. Management had already set a release date, and we had to start our design work, but the feature list was not yet complete. To avoid the other members of the product team perceiving us as a threat or as meddlers, we met informally with individual product managers to learn about their feature priorities. We asked them to prioritize each feature according to its importance, how long it would take to develop, how difficult it was to develop, and what dependencies it had (Respect Cultural Differences, Facilitate).
We then consolidated their disparate lists into a single list and organized it according to the amount of time the design work would take and the nature of the feature: whether the design was a new, complicated design, part of an existing design, or a simple new feature or graphic. The outcome of this process was an executable design plan complete with feature definitions and time estimates, as well as a usability testing schedule. We had positioned ourselves ahead of the curve (Be Proactive).
We took this feature list to the lead development manager and discussed various scenarios with him. The entire feature set was too large for the team to completely implement in the first release, so we mapped out a three-tier plan. The top tier contained all the essential features that the product needed to function, as well as the primary new features that the product managers had determined were necessary for the product to be competitive. The second tier added features that the product managers considered to be very nice to have, but not essential. The third tier added the remaining features. Each tier comprised a set of features that provided a complete and compelling user experience (Identify Common Goals, Deliver Quality).
Once the product team decided what features they could build within the time and resource constraints, our approved feature plan provided the basis for our UX effort. We also negotiated ownership for each feature with the new development manager. We identified a user interface designer, a developer, and a product manager who were responsible for collecting input, reviewing designs, validating that the developers could implement the design as specified, and signing off that a particular design met all requirements and stayed within the scope that the feature plan defined. This eliminated the endless churn that occurs when product teams try to make design decisions by consensus (Managing Expectations).
Then, we started designing. We worked iteratively with the respective feature owners. The plan we had mapped out worked very well.
The final part of the process was ensuring that the product the development team coded met the design we specified. We did that by comparing the signed-off prototypes side by side with the coded product. We filed every issue in the bug database (Formalize Communication, Deliver Quality).
We were very successful using this process. We completed the user interface design two months ahead of schedule, with minimal feature creep. The development team built a product that tested well in the usability lab, had good analyst response, and pleased executives. The long-term benefits were even better. The whole development team, including the product managers, recognized the value of our contribution. They continue to do so today, four major releases later. Our UI Group is now a determining factor in the success of this product. We also went on to successfully apply this process to the other projects in the same product line.
How You Can Use These Principles. If you have struggled to find solutions to the problems we faced, try following these recommendations.
First, don’t expect to change your entire approach in one go. Look at your current process and ask yourself what you can easily change right now. Formalizing communication and increasing the quality of your work are well within the capabilities of a UX group and have the fewest dependencies on other organizations. As you start to gain influence outside your immediate group, evaluate the strengths of the members of your team. In addition to evaluating their core design skills, look at their other skills. Some designers have strong organizational skills; some designers have great charm; some designers are good with difficult personalities; some designers are highly technical. Fit the whole skill set of the designer to the project. Assign designers with complementary skill sets to projects.
Second, keep the long-term picture in mind, even as you are working at a more detailed level. Doing so prevents you from getting too bogged down when the process is not moving as smoothly as you’d want, helps you frame the scope of the problem, and provides an effective check to keep you from taking things personally. Changing the existing processes of other teams takes perseverance.
Third, always represent yourself and the design process honestly. To make effective use of what your UX group has to offer, a development team must be able to accurately gauge what it is you do and trust that you will do what you say you will do. As you repeatedly go through this process with your development teams, and it’s a positive experience for everyone, you will build great leverage and influence over time, and find that your most pressing organizational problem is likely to be that you have too much work to do.
About the Authors:
Jeremy Ashley has 14 years of experience in applied interaction design of software products. He joined Oracle in 1996 and is currently the leader of the usability and interface design group, managing a diverse team of designers and usability engineers. He previously worked for Apple and Taligent. He has a bachelor of arts in industrial design from the Glasgow School of Art and a master of design in computer-related design from the Royal College of Art in London.
Kristin Desmond has ten years of experience in interaction design and information design. She joined Oracle in 1995 and is currently a UI manager responsible for sales and manufacturing applications. She has a bachelor of arts in architecture from the University of California at Berkeley.
©2005 ACM 1072-5220/05/0500 $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.