A few months ago, I wrote two CACM blog entries examining why great design is so hard (here and here). There have been a lot of great comments and insights from a bunch of people.
There’s one comment in particular I’d like to respond to, because it poses a good question about the nature of functionality with respect to design. In the comment, Mark Tuttle argues that the functions offered by a system outweigh design, citing examples of time sharing systems, email, Unix, bitmapped interfaces, MEDLINE, and query languages for early relational databases.
To a large extent, I do agree about the point about the importance of functionality. If we had a system that could predict tomorrow's stock market prices but was completely unusable, I'm sure we'd still see a lot of people making the effort to learn how to use it.
However, functionality and design aren’t separate things. A large part of design includes understanding what needs people have and what technologies can be applied to solve those needs. Design also isn’t just about the user interface “skin” of graphics, icons, and aesthetics that people see. It also includes the internal “skeleton” of how the application is organized, the conceptual model and metaphors conveyed to end-users, as well as its functionality.
It’s also worth pointing out that in many of the above examples about functionality, the systems were designed by and used by people with intimate knowledge of software. The designers already had a deep understanding of what the problems at hand were and how people did their work. In other words, the designers *were* the users. That’s not really the case anymore, though. Information and communication technologies are pervasive in all aspects of modern society, from finance to manufacturing, from health care to consumer products. We can’t rely solely on our intuitions anymore because the users are no longer like us.
Second, while functionality is a key differentiator for technologies in the very early stages of adoption, it isn't as strong a draw in the middle and late stages, especially when competitors have arrived that offer products with comparable functionality.
A lot of researchers have developed models of technology adoption. My favorite one is presented by Everett Rogers in the well-known book Diffusion of Innovations, which summarizes the literature in that area.
The five factors
At this point, you can probably see where I’m going. Innovators and early adopters have a higher tolerance for risk and complexity, and often have significant pains that need to be addressed *now*. In these cases, functionality dominates factors like aesthetics, usability, simplicity, and cost. If you’ve ever seen (or worse, had to use) anything created for the Department of Defense, you’ll probably agree it fits this description quite well.
However, the early majority, late majority, and laggards have very different profiles and thresholds for complexity and value. In these cases, the ability to create a product that fits into people’s lives plays a significant role, especially when competing products are available. This is where great design matters a lot, as demonstrated by products like the Nintendo Wii and the iPod. When the Wii first came to market, it was competing against the large and well-established base of XBox and Playstation consoles, and succeeded by dramatically simplifying game play and targeting casual gamers rather than hard-core gamers. The iPod came out a few years after the first mp3 players were already being sold, and made huge inroads by forging a strong emotional connection to people with its sleek form factor and fun user interface.
At its core, interaction design is about understanding at a deep and visceral level the needs, desires, values, and processes of people, and then applying those insights in the creation of technology. It’s about empathy, seeing and experiencing the world from the users’ point of view. And it’s about always remembering the mantra: the user is not like me.
It is important, as the author pointed out, to consider design and functionality as two important and complimentary aspects of systems development. I like to use the sand in the beach analogy when working with developers and engineers by explaining to them the design of a system looks at the entire beach to include the sand, water, etc, where the functionality is the particle of sand or the wave in the water that is a part of and contributes to the entire beach system. Too often developers and engineers are too focused on the one speck of sand in the beach losing site of the entire beach, which runs the risk of breaking the systems design. In simple terms, the design is how the system looks from an abstract perspective, identifying the elements, interactions, and users, where the functionality is how the elements, interactions, and users will engage and work with each other.
I totally agree with you. It is very important to address the issues of early adopters of the product. Also, like you pointed out regarding Nintendo Wii, the emphasis on great design and innovation in a product/software is always dependent on how established the competitor's product/software is? Whereas, for established products (like Microsoft Office) change and innovation on product's design has greater risk as users tend to get confused (like Ribbon interface on Microsoft Office). UX on the whole is a major factor in early stages of adoption but emphasis on it gradually fades away as product becomes more popular (and users don't like a change).
Developers and Designers are in peril when they ignore the Functionality and UX AFTER a product becomes very much established as run into the risk of competitors rolling out a product with same functionality but better UX.
1. When you point out that "...the early majority, late majority, and laggards have very different profiles and thresholds for complexity and value", this is one of the points Gladwell also makes in the last few chapters of The Tipping Point, in a similar analysis of why some products take off and some don't. Part of the point he makes though is that you still need the favorable opinions of the early adopters because they're the ones who create buzz. Get them excited, and they're the ones who will tell their non-early-adopter friends to dive in.
2. You conclude that "At its core, interaction design is about ... empathy, seeing and experiencing the world from the users point of view. And its about always remembering the mantra: the user is not like me." While I deeply agree with the point about empathy, I wonder about the latter statement. I know it's a core tenent of UX teachings, but the more I look around at the best designs, they seem to be made BY someone like me FOR someone like me. Apple and Nintendo have excellent empathy for their users, but they're both targetting consumer markets. Ultimately we're ALL consumers at some point, which means we ARE ALL the users.
Many tech folks are early adopters, but certainly not all. And some tech folks are early adopters only for a specific product niche, and tend more on the early majority or even late majority side for products outside of their comfort niche. By tapping into our own non-early-adopter mentalities, don't we fundamentally address the concerns of these groups?
Put another way: Is it wrong to think that empathy is enhanced by actually BEING a user? ("I'm not only the president of ____, I'm also a client.") I don't think so.
I would argue that the worst breakdowns of empathy occur when the designers are the farthest removed from their target market. The more alike we are with our customers, the less the empathy must be forced, and the more naturally it will come. This means better designs for all.
Displaying all 3 comments