XIX.3 May + June 2012
Page: 10
Digital Citation

Finding the sweet spot of design

Uday Gajendar

back to top 

Not long ago, during a tense conference call at a high-tech firm, a project manager suggested exploring the capabilities of technologies available for building a product. The aim: finding out, at the outset of the project, what would be feasible to build. The UX lead responded, "But that's not user-centered! We cannot look at technologies first." That lead had a good point. But the exchange got me thinking. Are users truly the center of a design? Why not do thorough tech explorations? And besides, isn't the business model what is really driving market viability, since that's what is paying our salaries?

So what truly lies at the center of a "good" design process and outcome?

For more than a quarter century, user-centered design (UCD) has been the de facto methodology for creating software. UCD has distinct merits and has been championed by a wide range of thought leaders, including Don Norman, Jakob Nielsen, Alan Cooper, and Karen Holtzblatt and Hugh Beyer, to name a few. UCD emerged out of a reaction to engineering-driven approaches that came from the computational sciences. UCD helps ensure that the needs of users, who may not be technical experts, are the focus as a product is being conceived and developed. When this isn't done, the results can range from nonsensical error messages to task-flow sequences that only a programmer understands. There are any number of books and case studies demonstrating UCD's utility and the cost savings it can enable.

The term user-centered design is a bit misleading, however. It seems to suggest excluding from the product design process not just technical experts, but also business managers, "leading edge" next-generation users—even designers, or at least designers' own intuition and judgment gained via years of experience.

Is that any way to build a successful product? An exclusive focus on users seems unwise. Users, after all, can be messy, complicated, inarticulate, self-contradictory, and emotional.

UCD emerged from studies of computer usage done by human-computer interaction (HCI) scholars. HCI approaches are informed by cognitive psychology and sociology, among other fields; HCI experts look to identify, understand, and quantify the human factor in computing. To ensure that their research results can stand up to scrutiny from engineers and accountants, they seek to deliver hard, reliable, quantitative data. They tend to see human-computer interactions as repeatable, standardizable activities, not random or self-expressive behavior.

But again, no matter how good the available data on users' desires, habits, and preferences, they should not be the sole focus in designing products. Users do not always know what they want, or how to express their desires clearly. And there are other factors that are just as important.

back to top  Getting to the Sweet Spot

I wonder how many UCD professionals have seen the diagram here by Charles Eames, the legendary designer:

This classic diagram, originally done for a 1969 Parisian design exhibition entitled "What is Design," shows a designer's chief concerns, in Eames's view. These range from the user, to the client, to the designer and his or her company, as well as larger political and social forces. And all of them are always in flux. The dynamic "sweet spot," where everyone's interests coincide, should, per Eames, be the designer's focus.

Note that the center is not a single point. It's an area defined by a complex amalgam of needs, wants, and constraints. To find it, the designer must maintain a sustained, intensive engagement with a range of project stakeholders—not just users. Then he or she needs to assess their needs and wants carefully to arrive at a balanced solution to the problem at hand. Is this difficult? Well, of course!

Technologies matter. To create an actual product based on a user-inspired design, designers need to work closely with engineers. This means understanding their thinking, and, as needed, working with them to revise the design to make it technically feasible, while still addressing the needs of project stakeholders. Also critical is building positive relationships with engineers to ensure the success of future iterative projects.

Tool decisions are a big part of the development process. In making these decisions, engineers determine much of what will or will not be possible when building a product (e.g., Windows Presentation Foundation, or Javascript libraries, or Objective-C). Different tools enable different outcomes, which may not map to what the designer wants or believes is necessary to serve the interests of project stakeholders [1]. So designers need to be involved in these decisions. Designers can't just throw it over the wall, or they risk being marginalized and ignored.

To make an informed contribution, here and at other stages, designers should be familiar with the technology engineers are using. Designers should not just read about the technology, but play with it to find out what value it can provide beyond what users already know they want. Being able to manipulate technology toward anticipating and exceeding user expectations is a powerful thing.

At every stage, designers should be flexible and open-minded. Tradeoffs and compromises are inevitable and can help ensure success, not undercut it, so long as they are grounded in sound humanistic principles, not user dictates.

Getting down to business. What about business factors? Companies need to make money, and to keep funders happy, nonprofits need to show mission success. Working in either sector, designers need to create products that enable clients to meet their goals.

In the enterprise software sector where I work, it's vital to understand the "sales channel"—that is, the ongoing series of interactions between salespeople and customers. These interactions not only drive deals but also feed release schedules to the customer, with feature and bug-fix requests going back to the development team. The sales channel can be an extremely useful source of information for designers, though of course they should keep in mind that customers—product buyers—are not always the same as product users.

Also key is to understand customers' business models: what they offer their customers, why this offering has value, how they make the sale, and how they ensure the sales stream will hold up over time. Useful here is the recent book Business Model Generation by Alexander Osterwalder, which explains traditional business thinking through a design lens. Understanding your customers' business, you can then explain the business value of a particular design, or make a convincing case for using a particular business model to sell a proposed new product (e.g., "freemium" or "subscription-based"). And of course you'll be able to shape your designs to meet not just users' needs, but customers' business needs as well.

Revisiting the center of design. So what's the center of a design? In one sense, it is the designer's nuanced understanding of the problem or opportunity at hand—as designers love to say, the focus of design is problem solving, not self-expression. Again, this understanding must be based on balancing human, financial, and technical challenges. As design scholar Richard Buchanan has said, "Design lies at the intersection of constraint, contingency, and possibility" [2].

In the end, a successful design process and outcome revolve around principled compromise. Yes, user personas and use-case analyses are a big part of this—but remember the Eames diagram. To be influential, a designer can't focus exclusively on the needs and wants of a single stakeholder—even if that stakeholder is the end user. Ultimately, a successful designer is one who does a great job of understanding every stakeholder's needs and wants, finds the sweet spot where they all overlap, and crafts a design that "lives" in that sweet spot.

back to top  References

1. Gajendar, U. and Johnson, C. The inmates are still running the asylum: How to share a design vision with engineers. Proc. of HCI International. Springer, 2011, 276–282.

2. Liedtka, J. and Ogilvie, T. Designing for Growth: A Design Thinking Toolkit for Managers. Columbia Business School Publishing, New York, 2011.

back to top  Author

Uday Gajendar is a principal designer at Citrix. He creates attractive, useful products that enable "work and play from anywhere," and evangelizes design thinking within the company.

back to top  Figures


back to top 

©2012 ACM  1072-5220/12/0500  $10.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 © 2012 ACM, Inc.

Post Comment

@Aman Anderson (2012 07 18)

This is great
“So what’s the center of a design? In one sense, it is the designer’s nuanced understanding of the problem or opportunity at hand. The focus of design is problem solving, not self-expression.” - Uday Gajendar, Interaction Designer