Design Mistakes

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.