Can user-centered design steer you wrong?
It’s not unusual for us to operate under the assumption that different people perform different tasks… well… differently. The personas we craft to represent our users help us remember our audience — their preferences, their demographics, and their technical knowledge. But what if personas aren’t the answer to everything?
Comrade collaborated on a study that examined the adoption rates for Mobile Check Deposit, the feature that many banks offer allowing customers to deposit a check by taking a picture with their phone. We looked at various factors, including different personas, and we made a surprising discovery: the findings were the same, regardless of the user. Persona differences didn’t seem to matter – users of different demographics, technical savvy, income levels, etc. all exhibited the same findings. What seemed to matter was not who was using the feature, but the nature of the activity itself.
Enter User-Centered Design
User-Centered Design, or UCD, has been with us for so long that we almost forget the days that came before. Back then, technology seemed almost like magic – it was difficult because it was powerful, and a steep learning curve was just part of earning the right to wield that power. Users were asked to adapt to the technologies and tools that engineers gave them, as though from on high.
Since Donald Norman coined the term User-Centered-Design in the mid-1980’s, putting the user at the center of the design has become not just commonly accepted but devoutly unquestionable. Personas, usability testing, joint application development, and co-design had fundamentally changed the design process. Focus groups, not engineering teams, determined what features should exist in a product. After decades of technological products that forced users to conform to them, we finally had empathy in our design process – and a way to design that put users first.
Not the “who,” the “what.”
In 2005, the same Don Norman published an article titled “Human-Centered Design Considered Harmful.” In the article, and in a follow-up, he challenged the idea that asking users what they want and giving it to them was the right way to approach design. Norman proposed Activity-Centered Design, or ACD, as an extension and expansion to UCD.
The thesis was that UCD, and in particular the way it had come to be practiced, had become too narrow and focused on individual differences and wants for specific screens and interfaces. As a result, it lost the larger context of interruptions, ill-formed goals, conflicting motivations, and unexpected conditions or needs. ACD represents not a refutation of the empathy and dedication to user value that is at the heart of UCD, but an extension of it that addresses the things that UCD overlooks.
Activity-Centered Design, or ACD, focuses not on the different demographics, psychology, and technology skills of individual users, but on the context and composition of activities – or collections of tasks, goals, rules, and tools that group together. Is this a step backward towards more task-based design? Not really – because activities are more than just tasks. Whereas a task might be “send an email,” it might be part of a larger activity, say, “keep up with correspondence,” which also includes reading new mail, figuring out who really needs to hear from you, and updating your contact list.
UCD states that technology should always adapt to users; users should not have to adapt to technology. ACD recognizes that humans do, indeed, adapt to technology. Take the invention of the clock – the mechanized measurement and tracking of time changed almost everything about how we approach our days. We absolutely adapt to technology as another element in our environment.
UCD focuses solely on the participants (primarily the direct users) and the individual tasks, while ACD considers these components of a larger context that supports the fulfillment of the needs of people – needs much more complex than simply successfully completing a use case. Tools, rules, other participants in related tasks… all of these are part of the context that UCD often leaves out of the picture.
Paying attention to the broader context
So as designers, should we abandon our UCD practices? Certainly not, but we have to start considering them in a broader context. This is already happening in the field of Service Design. Customer journey maps take into account multiple tasks in various combinations, with multiple touchpoints represented, often over a long period of time and multiple contacts. Ecosystem Models represent the context of various systems, tools, processes (controlled and otherwise), and rules that make up the context of an activity. They are great lenses through which to view activities in context.
In addition to what we’re already doing, UX, CX, and other solution design professionals need to do a few new things. First, we need to start thinking of and representing activities the way we currently consider personas. The model illustrated here is one structure that can be used, but just as there are many ways to crystallize a persona, there are many ways to encapsulate activities. Let’s get creative – it’s what we’re good at:
The second thing we need to get good at is understanding the readiness to employ ACD of our clients, their customers, their industries, and the individual products we’re designing. Not every project is ready. ACD is the next step along a maturity curve – and it’s very hard to skip steps effectively.
Consider the iPhone. In 2007, when the whole concept of a “smart phone” was totally new, we couldn’t really even employ Human Centered Design (who would the personas be? What do they need or want from such a device?), much less ACD (what activities will this device support?) to designing a product like the iPhone. In that case, capabilities really WERE the driver – though clearly, that didn’t last long.
If you consider the Mobile Check Deposit research in this light, the findings become a little less surprising, and a lot more understandable. What mattered more than the users themselves is the activity. If we can develop ACD practices to the level we have done for UCD, we will be able to do more than just solve users’ problems – we’ll be able to address people’s real needs. And what’s more human than that?