While test driven development and solid QA processes are intended to catch programming errors, there is another category of mistakes that developers make when building applications that can really damage the user experience even if there aren’t code errors. The typical development process can often make these problems hard to detect.
“It doesn’t really come out until it’s in production.”
Programming errors are one thing, but there are other types of errors that can be just as damaging to end user experiences. These errors are easy to miss in a software development shop, precisely because of the biases that are present on the typical development team.
12:00 Incessant Notifications
“Hey! Hey! Hey! Pay Attention To Me!”
When you are testing your code, the most important thing happening on your computer is your code. That’s not true the rest of the time or for most of your users. You’ll also see the same thing with hardware. This is especially painful with desktop notifications.
17:38 Excessive Setup Ceremony.
Your app may work if all the pieces are lined up, but how long does it take to actually get going with your software?
Excessive setup effort tends to get missed in QA. Remember that people are using your app because it provides value. Anything that takes longer to get to that value is a problem.
20:40 Dumb Auto-Update Practices
If your app automatically updates, it must be rock solid, unobtrusive and capable of being deferred. If it is not you risk interrupting important work at a critical time.
“It’s their computer not yours.”
If your app interacts with an api, do not roll out changes to your API that are not backward compatible with your app. Your user’s productivity should not be destroyed just because you rolled out an update this morning. You don’t know what your user is trying to get done right now, don’t break their focus. You also shouldn’t be constantly breaking people’s workflow to remind them of updates.
25:58 Inability to Save and Recover
“This is one that just about every app I’ve worked on has missed.”
If a user is working in your app and experiences a power failure, network connectivity failure, or just needs to quickly shutdown and go do something else. Your app shouldn’t lose their work in progress. This tends to slide by QA because they are actively testing through without stopping.
29:50 Poor Idle Practices
What your app does when users aren’t using it is important. If your app is in the background, it shouldn’t be using CPU, memory, and disk in the same way as when it is in the foreground.
“How does your app act when it is not in focus.”
In other words, your app should recognize when it isn’t the most important thing on the system and should make sure that it doesn’t interfere with whatever that is. Your app should also be able to handle system hibernation and recover from it.
32:48 Poor Error Handling
Your error messages should describe what is going on in a way that your average user can troubleshoot it, at least for common errors. Have in app documentation for this so your users don’t get frustrated. You should not hide errors that lead to data corruption or to things not being saved.
34:26 Poor Timeliness
Your app should respond in a way that users can detect within a couple of seconds of taking an action. Even if the action is not completed in a couple of seconds, the user needs feedback to know that something happened.
“If you click a button you should get something going ‘OK I’m doing the thing'”
Slow feedback can cause people to click on things twice, to close the application, or to report a bug. It also is very frustrating to deal with in general.
38:45 Poor Rollbacks
An app should allow undoing actions to the degree possible. Where not possible you should notify the user and make sure they actually want to take an action. Allowing a single undo level is only sufficient when you can only take a single action at a time.
42:58 Poor Focus Management
The “focus” is the app or control that is currently receiving input. If your app takes focus away from what the user is doing in an uncontrolled manner you can easily cause users to agree to things they otherwise wouldn’t. If the user hits the enter key, it may be taken as agreeing with a popup.
46:00 Poor settings Management
Your users would generally like your app to remember the settings they used last time. When users have to reset things every single time they use your app it leads to mistakes and frustration.
IoT Pill Bottle
This project is basically a smart pill bottle that helps both doctors and patients. You’ll put a sensor on top to monitor when the bottle is opened to track time patterns of when pills are taken. There’s also one to sense when it is time to refill.
Tricks of the Trade
User personas are a great way to get into the headspace of potential users and avoid being stuck in the headspace of a programmer developing the program. You should generally evaluate the impact of your design decisions based upon how they will impact the different user personas you have.