There’s a big, handy black box in software development that we like to throw our complicated and annoying problems into. It’s called, User Error. It’s where we send help desk comments from people who lost their passwords, or wandered down an IA dead end, or made their browser crash and can’t explain why. We have fun acronyms for all the stupid users out there, too:
- PICNIC: Problem In Chair, Not In Computer
- TSTO: Too Stupid To Operate
- EBK: Error Behind Keyboard
- EBCAC: Error Between Computer And Chair
- PEBKAC: Problem Exists Between Keyboard and Chair.
- Layer 8/9 error: There are seven layers in the OSI model of computer networks. The 8th layer is the user.
- Code 18: The problem is located 18 inches away from the monitor.
Yeah, I’m laughing too. But then I’m putting my UX hat back on and saying that, funny as it is, it’s all complete rubbish. There is no such thing as user error.
Blame it on Your UX Team
As much as I don’t like blaming everything on product design, this one sits squarely in their wheelhouse. The whole reason we have user experience research and design and testing, is to eliminate user error. There are no stupid users, just lazy designers.
If someone is getting lost in your application, it’s because you didn’t flow out the whole application to see that some paths lead to dead ends. If a user quits while onboarding, or answers a question incorrectly, or comes up with a password that doesn’t work, it’s the UX strategist’s error, not the user’s.
If customers can’t figure out how to get through your front door into your store to buy stuff, you don’t stand at the window saying “Stupid Customer.” You fix the door. You also don’t tell them to call your maintenance man and lodge a complaint with him about the door that doesn’t work. This is your problem, not Help Desk’s problem.
UX is all about making it easy for customers to use your application, website, mobile app, phone, refrigerator, etc. The way they do that is by thinking through use cases and flows, testing those assumptions with other UX designers, PMs, Biz Dev, and users themselves, and iterating on the design until all the bugs have been worked out. The more they do this process — this design iteration process — the smarter your users will get.
If your design team is not iterating on the product flow you’ll be stunned at how many stupid users try to use your application.
Now Give Your Team Time to Do Their Job
This, of course, translates into time allocation for the product design department. The more time up front you allocate to the design team, the less time you’ll have to devote to QA and multiple iterations post launch. I’m not advocating six-month design iterations, but remember, post launch redesigning means you’re sacrificing precious“earlyvangelists” who gave the product a shot, and decided it was too crappy to stick with.
On the other hand, if you pare down your feature list for each iteration, and allow the design team to work one sprint ahead of development (rather than designing what is being built all in the same sprint), you can release well designed, cleanly developed products that attract some of the smartest users you’ve ever met.
