Ask any seasoned app developer if they have a “problem user” story and the reply usually begins with something like, “You would not believe what this one person used to do.” We’ve all experienced them. They’re the people who do things with our apps that we never dreamed anyone would do when we designed them. They frustrate us by breaking our “well thought out” designs. But they also provide us with important opportunities. Problem users make us better developers when we learn from them.
“If it weren’t for users the software would work great” –Rick Sall
Technical skills are great, but they’re not enough
As app developers we tend to use technical skills and knowledge as the metric for proficiency. Let’s face it, without them it’s impossible for us to be competent developers. But there are other skills and knowledge that many of us pick up in the course of our careers that are harder to measure. But they are equally important in making us good at what we do. One of those skills is paying attention to the so called problem users, learning from them and taking steps to proactively foil them.
One user in particular inspired this article
About 10 years ago a new person started using a FileMaker database solution we’d built. This solution had already been in use by about 50 users around the world for a couple of years before the new user came on the scene. As expected, we’d had the occasional bug reports when we first delivered it, but they had tapered off over time because we’d fixed them all along with a few bugs we caught ourselves.
Then all of a sudden bug reports started coming in at an alarming rate. Features that had been used without problems were now behaving in unexpected ways at a concerning rate. And the majority of the bug reports was coming from one person. The new user.
The new user had an uncanny knack for using the software in ways we’d never dreamed of.
After a few years of adding more features to the software, which this particular user found ways to break more than other users, I came to realize that despite all the headaches and stress these bugs had caused us, this person had made us become much more savvy developers than we would’ve been had this person never become one of the users.
No one would ever do that. Or would they?
I used to believe there were things that no one would ever do, even if they were allowed to do it. In all fairness, not all unexpected actions by users are intentional. Some are just a result of accidents that are hard to plan for if you’ve never seen them before. Here’s a sampling of some of the more unusual things I routinely prevent users from doing because experience tells me that if it happened once it’ll happen again:
- Selling a fraction of something that makes no sense at all (e.g., an egg)
- Scheduling an appointment to start later than its end time
- Putting a text string into a container field for storing images (yes, it can be done)
- Entering every value from a popup menu in a single field (yes, that can be done too)
- Tricking a script into running when it shouldn’t (see the article ‘Using Hidden State For Validation‘)
The list is longer than this, of course, and includes some of the usual suspects like stripping unwanted invisible characters out of fields and removing text formatting.
Problem Users aren't The Problem
Users that are prone to breaking things aren’t on a mission to drive you crazy. Nor do they cause bugs; they merely uncover ones that other users couldn’t find. They uncover them by doing things in a way that either makes perfect sense to them or they made an unusual mistake that no other user had ever made before them. They have certain expectations of the software, and if it doesn’t work as they expect it to work, then it shouldn’t break because of that.
From my perspective that’s a perfectly reasonable expectation. It’s even arguable that we developers are the problem because we’re letting them do things that break our software. And that brings us back full circle to the point of this article. If we pay attention to how these users manage to break things, we become better at building apps that are less likely to break.
Opportunities disguised as problems
If you’re a seasoned developer and you’ve never had a problem user, first of all, how did you manage to do that? Second, I have to tell you that you’ve missed out on some excellent training on how to build better apps.
I have no doubt that no matter how many ways I’ve seen users break an app I’ve built, there are still more that I’ve never imagined. But thanks to numerous ways I’ve seen users break apps, those users now have a lot less ways to break the apps I build.
Next time you end up with one of those problem users that manages to break things in ways you never imagined, take a deep breath and look at it as an opportunity to learn something that’ll make you a better developer.
I hope you enjoyed this piece.
Have any thoughts on it? Leave a comment below. I’d love to hear your feedback or one of your own personal stories of how a user broke something in a way that you’d never imagined possible.
