Testing with users of complex applications is challenging. It’s true, but it’s also essential. As a practitioner, you’ve probably heard plenty of excuses about why you optimizations can’t or shouldn’t be made to complex apps like People Don’t Want Change or will they have to use our app or the popular will?
They’ll be trained on it anyway. I’m going to talk through three broad categories of complex apps users that I’ve observed, the legacy, the legend and the learner, and share how these excuses fail and marginalize each of them. First, consider the legacy user. This is someone who’s been using the app for a long time, decades maybe. But despite time on bench, they have very limited understanding of the breadth of features within the app. They’ve learned very specific ways of getting things done, often inefficient ones, and they’re set in their ways. We often write off legacy users by saying they don’t want change. They’ll hate anything we do. So why bother? But it’s not that legacy users hate change. Rather, they hate productivity loss. They’ve invested time in learning these inefficient workarounds to the poor usability aspects of the app we gave them. We put them in this position. So we have to be mindful and helping them transcend it. When the value of change is well communicated and the change is not forced, legacy users may embrace optimizations in exchange for increased productivity. Now, the second type of user, the legend, is the expert user there, the people making use of system accelerators and shortcuts and then have some pride and ego associated with their deep platform knowledge and the complex work they use it to do. The common mistake we make with the legend users is assuming that because they’re passionate about and experts with the system that they’re loyal to it, or that they have no other choice but to use our app for their work, we say, well, they have to use it because there’s nothing else on the market that does what our app does. But the truth is there’s constant domain specific app innovation. And if other apps are more useful and more efficient and the legend has reached their performance ceiling with our app, they’ll move on because productivity is more important to them than loyalty. Finally, the learner. This is the user who’s a domain expert but a complete novice to the application. They’re often neglected with the sentiment of forget them, they’ll learn it in school or they’ll be trained to use it anyway. The danger in neglecting learners is that if they can’t learn the system up front, they’ll never truly understand the app’s capabilities or transition to expert usage, and they’ll have no reason to continue using it, given the choice.
The important thing is to consider and understand where these excuses come from, often false assumptions about our users. Each of these user types can offer valuable insights that are important to consider in the design and evaluation of complex apps.