Engineers, by the nature of their work, cannot objectively experience their product like a legitimate user. While busy cranking out new features and pushing the product forward, it’s common to accrue some technical debt in the codebase. However, sprints to the finish line are likely increasing debt in an arguably more critical area: usability.

Usability is the measure of ease-of-use and learnability. In product design, it’s the glue that keeps people coming back and compels them to tell others about their indispensable discovery. Without it, they’ll give up, move on, and may very well feel insulted on the way out - all in the blink of an eye, pound of a key, or in the quiet defeat of not knowing what the hell to do next. It’s easy, on a product team, to build and pave our workflows with blinders on (makes sense on my machine!). We know how the thing works so well that our empathy becomes lost in the assumption that everyone will find their way through our tried and not-so-tested paths.

Empathy - the ability to understand and share feelings - is increasingly obscured when we don’t check in with the people for whom we’re building these tools. Examining new perspectives and understanding different personas are key to detaching from our own well worn assumptions. By observing user behavior in a few test sessions, interaction patterns begin to surface that expose design flaws varying from simple fix to total redo: words that go to waste, workflows that frustrate, and features that intimidate. These are a few common challenges facing product usability that engineers may fail to notice, or inadvertently train themselves to ignore.

Words That Go to Waste

Words often go unread. The more words there are, the less likely someone is to read them. When features and functionality are explained left and right, users feel fatigued. Verbose dialog causes people to turn the other way, assume it’s complicated, and disconnect. Maybe they’ll just ignore that feature and carry on with vague dissatisfaction, or maybe they’re one step closer to signing out forever. Describing a feature isn’t inherently bad, but if it comes with an instruction manual it’s likely to be ignored. If the message isn’t short and sweet, save it for the docs.

Workflows That Frustrate

Many times, users are forced through a set of instructions that might not make sense to them, in order to serve needs of the app (e.g. data gathering and 3rd party integration). Users forced into a prerequisite workflow - requiring them to perform actions before they can explore - may result in frustration as the first impression or ultimately, a rage quit. Instead, maximize functionality by minimizing restriction. How far can a person get in the experience just by signing in? Reducing barriers enables experimentation and learning. Isolating constraints to an atomic level - the moment of need - liberates the user experience and showcases what the product can do.

Features That Intimidate

Features require discovery and learning. Ideally, that occurs intuitively and without cognitive awareness. One of the toughest pills to swallow during usability testing is finding that robust functionality is cryptic, intimidating, or elusive. A test participant waves their mouse over an entire area: “I don’t know what thiiisss does.” It’s likely doing too much or lacks useful context. The single responsibility principle that shapes sturdy application development can provide a solid construct for product design as well. When a feature is overloaded with functionality, consider ways to split it into smaller parts, provide clear context, and support intuitive discovery.

These are some common pitfalls we found through our own user testing that will help inform design decisions going forward. Usability testing isn’t an end-all to holistic product design but it is a necessary practice for gaining insights into pain points, drop offs, and blind spots. In addition to revealing design flaws, these tests are imperative in reminding us that people will use an app much differently than those who build it.