Communications of the ACM
BLOG@CACM
Matters of Design
I want to take a slight detour from usable privacy and security to discuss issues of design. I was recently at the Microsoft Faculty Summit, an annual event where Microsoft discusses some of the big issues and directions they are headed.
In one of the talks, a designer at Microsoft mentioned two data points I've informally heard before but had never confirmed. First, the ratio of developers to user interface designers at Microsoft is 50:1. Second, this ratio is better than any other company out there.
As someone who teaches human-computer interaction, I wanted to push on this point, so I asked the hard question: "On a relative and absolute scale, Microsoft has more designers than Apple or Google. However, I think most people would argue that Apple and Google have much better and easier-to-use products. Is it an organizational issue, a process issue, a skills issue? What do I tell the students I teach?"
I want to make clear that my question wasn't meant to be negative of Microsoft specifically. It actually hits on a pervasive issue facing the software industry today: How do we effectively incorporate great design into products? Because, to be blunt, a lot of user interfaces today are just plain bad. Painfully bad.
Companies like Nintendo, Apple, Google, and Amazon have proven that good design matters. Why haven't other companies followed suit? Or perhaps the real question is, Why haven't other companies been able to follow suit?
I discussed this issue with a lot of people at the faculty summit and in Silicon Valley. I used Microsoft as my example, but I think the same problems apply to pretty much every software company.
People offered five explanations. The first is the "geek culture" where engineers rule. At most software companies, there has never been a strong mandate at the top for great design. Instead, engineers tend to have wide latitude for features and implementation.
Second, there is often no one in charge of the overall interaction and user experience. As such, there tends to be no consistency and unified flow for how a system looks and feels.
Third, designers tend to be brought in the process too late, to do superficial work on a system that has already been built. One person basically said it was "lipstick on a pig." Design is more than just the surface layer of the visual interface. It's also about understanding how people work and play, how things fit into their lives, how people see and understand things, what problems they have, and how to craft a product that fits these constraints.
Fourth, designers have no real power in most organizations. They are typically brought in as consultants, but cannot force (sometimes necessary) changes to happen.
Fifth, a lot of people in technical professions just don't "get" design. They think it's just putting on a pretty interface or worse, the equivalent of putting pink flamingos on one's lawn. A lot of this is due to education in computer science programs today, which focuses heavily on algorithms and engineering, but leaves little room for behavioral science, social science, the humanities, and any form of design, whether it be industrial design, graphic design, or interaction design.
Overall, this issue of design is a fundamental problem that industry doesn't quite know how to get its head around. Just hiring an interaction designer isn't enough. Improving the ratio of developers to designers isn't enough. With the advent of trends like "design thinking," the increasing number of human-computer interaction degree programs, and visibly great products, people are starting to realize that design really matters, but just don't know how to go about making it a fundamental way for organizations to make software rather than just "lipstick on a pig." The problem becomes even harder when the system combines hardware, software, and services, which describes pretty much every system we will have in the future.
I want to make clear that we, as researchers and educators, don't know the answer either. But, in my next blog entry, I'll write about my discussion with someone who used to work at Apple, with some insights about how its process works. I'll also be visiting Google next week, so I'll be sure to ask them these same questions.
JASON HONG: "This issue of design is a fundamental problem that industry doesn't quite know how to get its head around."
P.S. I want to get your comments and feedback, but please don't use the word "intuitive," talk about "dumbing down interfaces," or say that users are "dumb, stupid, and naïve." These are signals that you really don't know what you're talking about. And, yes, not all interfaces have to be walk-up-and-use.
Readers' comments
On one side we have the "geek culture" people, oblivious of what happens to the user, doing self-referential design. On the other hand, we have the designers with their MacBooks, reluctant to delve into technical issues.
Between them there is a void that supports the "nobody is in charge" stance. Actually, the void was created before everything happened, before the software was written and way before the designers cringed. The void is, in fact, the lack of a usable user interface (UI) definition in the requirements and software design stages. If it's not specified then, the outcome might be anything. For example, the outcome might be a good UI every now and then, as it happens nowadays, making you say "a lot of user interfaces today are just plain bad."
Functional analysts and software architects have to raise the flag, not graphics designers.
See, for example, some writings by Larry Constantine. He got it many years ago, and he is a geek like Alan Cooper and Jakob Nielsen. Not a designer. See http://www.foruse.com/articles/whatusers.htm or other articles in http://www.foruse.com/publications/index.htm.
The design activity that determines the usability of a nontrivial UI is the one that happens before writing the first line of code. Moreover, before starting to envision a disposable prototype.
Juan Lanus
Many of these observations are spot oneven uncomfortably accurate. However, perhaps a missing observation is that these five different issues are not independent and many share a similar root cause. Much of it comes down to the leadership in the company and the resulting decision-making processes. Projects, resources, and timelines are typically dictated at a very high level, often by those who exclusively focus on a multiyear competitive business strategy. That calculus is generally of the form "To improve our performance in market X, we need to create product Y, with features Z by Q2 of next year because our competitors A, B, C are likely releasing E, F, and G."
The notion of "good design" ends up becoming a product "feature" that just like any other feature has to be scoped and completed by a particular deadline and preferably not revisited. Good design is typically not at the essence of a product's reason for existing. More often than not, projects are green-lit based solely on whether there is a pressing business need, rather than on the belief something genuinely great could or should be created. This core issue, in my opinion, sets into place a series of processes, priorities, and corporate culture that accounts for nearly all of your observations. Prioritizing good design requires a culture where by "creating a great experience" is a slightly higher priority than "maintaining a strategically competitive market share." It's a little bit of a "built it and they will come" mentalitywhich, understandably, is not a pill many executives readily swallow, especially if their compensation is connected to the stock price.
Occasionally, business needs and good hw/sw/ux design do happen to align. But it is fairly rare. A leadership team that can see past the battlefield of business needs with enough vision and taste to identify the seedlings of a great and profitable experience ... is rarer still.
Johnny Lee
I'd change the question to "Why is great design so infrequent?" because we have solved much harder problems. It requires a leader who needs to enforce the principle of profitabilityi.e., "We are going to design a product that will outsell our competitors' products because they will want to buy it"and the infrequency of great design is a result of the infrequency of these leaders. I suspect they are often only one person who comes to the project with a picture of what is needed.... [Y]ou don't need 50 design engineers; rather, what's needed is one responsible "profit" engineerone who is willing to delay each step of development until trial users give their feedback. You can't predict what users will want, but you can put prototypes in their hand and have them tell you what they want.
Neil Murphy
Jason Hong responds
One of the goals of emerging human-computer interaction programs is to cross-train "Renaissance teams" that can combine the best of design, computer science, and behavioral science.
I take the term "Renaissance team" from Randy Pausch, who noted that given the scope of knowledge today, "Renaissance man" is a near impossibility today. Plus, people tend to listen to me more when I quote him.:-)
On the computer science side, I've been advocating that all computer science undergrads should be required to take at least 1) a machine learning course, and 2) a human-computer interaction course. My rationale is that these two themes are fundamental to the future of computer science. Taking a machine learning course is an easy sell in CS departments and starting to happen, but it's less so with HCI.
I'm not sure yet what to advocate on the design and behavioral science side of things, though.
©2011 ACM 0001-0782/11/0200 $10.00
Permission to make digital or hard copies of part or all 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 full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.
Comments
The account that made this comment no longer exists.
Jason,
Simplistically, function tops design, and content tops design - two sides of the same coin. Here are the examples from my "technical" life.
1) Dartmouth Time-Sharing System vs. IBM (or GE) Mainfame: Time-Sharing (with BASIC) almost always won in spite of the limitations on program length and the expressive limitations of BASIC (another whole story). The sense of community and re-use that emerged around the Dartmouth Time-Sharing system was stunning. This observation was reinforced when I got to grad school elsewhere and found only main frames, initially. Computer scientists and computer engineers found the whole BASIC in a time-sharing environment offensive. In your words, BASIC+TS was "without design". Yet, I soon abandoned mainframe FORTRAN for BASIC+TS, because of function. In today's lingo is was highly available and a tool of communication and collaboration, in a way that my deck of punch cards and mag tapes were not. The fact that BASIC ignored Algol proved irrelevant, then.
2) The Internet - Prior to email, the internet wasn't used much. The internet+email changed the world. Externally both the internet and email were ugly, but the function was unbeatable, then. The internet had some good stuff under the hood, and email just needed to work reliably for folks to use it.
3) UNIX as a Homogeneous Programming Environment - Ken Thompson once told me that he rewrote the code for the "pipe" mechanism 10 times from scratch. That's design! (Compare it to the way pipes were implemented, later, in MS DOS. The C programming language was more for system programmers than "users" but it helped make things portable - so that UNIX ran on everything but the Coke machine. Unix was so good, so powerful and so productive to use that we inflicted it on beginning students, for whom it was not designed. In the end most of them thought it "cool".
4) Bit-mapped interfaces - Because of the Mac and Sun workstations interface design had a brief ascendency. HyperCard was a wonderful direct manipulation programming environment. But, the Web blew all that out of the water. Ubiquity, low cost, and rapid evolution, even of brain-damaged interface behaviors, beat any fancy interface that didn't have "Web" capabilities. I remember someone trying to give me a "Lisp Machine" - nominally an expensive piece of technology; I turned the offer down.
5) In the interface hey day, designers would say things like "if it doesn't have a good interface no one will use it." Two important counter-examples were: Really ugly access to MEDLINE - evolving from punch cards to RJE to other abusive command-line interfaces; but I saw doctors learn how to use it; and access to laboratory results - from a 40 character, upper-case only, red on black screen, the worst possible thing you could imagine. But the docs thought it was wonderful!
6) Early relational databases - Query languages were counter intuitive because, for example, they were based on the lamda calculus. "Badly" written queries ran slowly, and query optimizers were thought to be too complex to ever be helpful. Instead what I saw was users learning query languages by example, and query optimizers "training" sophisticated users in the art of query writing that led to queries that would finish in a productive amount of time.
To me, I see all these things a function trumping design and content trumping design. My iPhone is a not very good phone, but I use it for all the functions it has. My Mac laptop is expensive, but it's reliable and easy to use. I'm learning to use Mathematica's functional programming paradigm because it's powerful - it can execute huge computations quickly, with little investment in code, but the code is not easy to write, and the resulting programs are hard to read.
Etc., etc.
Still, I hope you continue to teach your students the difference between good design and less good design, but temper whatever you say with case studies - where good design either did or didn't win out, and why.
David Krum
Great points. I argued recently, in a position paper for a CHI workshop, that many interface design practitioners are isolated in several ways from the interface design community. They do not have the breadth of knowledge, connection to the latest developments, or the ability to play a decisive role in product design. The isolation can be due to current CS education curricula, corporate structures, management practices, the primacy of domain knowledge, and other issues. If you are a junior programmer who was assigned to interface development because you took a class in computer graphics, it is hard to know what to do. Even if you are well-trained and skilled, if you are a lone voice in the wilderness of your company, it is hard to create good interaction design.
We need to continue the discussion, strengthen interaction design as a part of CS education, and continue to reach out to management with the argument that good products have good interaction design.
The workshop was "Researcher-Practitioner
Interaction" at CHI 2010. Lots of interesting points of view.
Workshop page: http://research-practice-interaction.wikispaces.com/
Position papers: http://research-practice-interaction.wikispaces.com/Position+Papers
Displaying all 2 comments