Let’s talk about the usability of broken systems for a moment. Have you ever truly spent the time to observe your own habits and understand what potentially broken systems you or others are working around every day? First of all, we must recognize that humans are adept at self correcting and circumventing broken systems, often subconsciously.
Usability is the discipline of methodically reviewing a design or system, observing users and reviewing real user data, and taking the sum of those internal and external efforts and constantly iterating on the user experience to make it better based on those findings. I’d challenge anyone in the web usability community to also pay close attention to accessibility and performance, if they aren’t already doing so.
Broken systems are experienced constantly: the elevator doesn’t work, the car doesn’t start, the button doesn’t click, the web application crashes and loses the user input, the door sticks and you have to lift the handle to open it, the drain pipe doesn’t flow fast enough to move water, or the door has a handle instead of a push plate but pushes open.
The door with a confusing user interface is a common trope in the context of this discussion. This is an occurrence where someone will pull a handle when presented with one, when perhaps the door needs to be pushed open instead. It’s a frustrating experience and the frequent addition of signage indicating a handle should be “pushed” is a bandage on an already broken system. Interestingly, no matter how many of these door handles someone encounters, people very often instinctively pull instead of push — even with signage indicating the opposite action is necessary.
Building upon the door push versus pull example, if any one of these simple or complex systems was corrected or improved, you as the user may save invaluable time if not simply be amazed by the change you experience. However, interestingly, humans excel so much at working around broken systems that they often won’t realize they are self correcting.
Additionally, there is certainly a range of acceptable yet functionally broken systems. For example, a stopped clock gives the correct time twice a day but requires a higher degree of adaptability while an escalator that has stopped working is still a functional staircase. So, what does usability of software and the general subject of broken systems have to do with one another?
In the ecosystem of the Internet, we encounter micro- and macrocosms of excellent usability and broken systems regularly. Not long after the Internet was invented, email, Internet Relay Chat (IRC), and web pages were created. IRC is one of those mediums that is still alive and well, however it’s quite old, and yet many people in the world have no idea that it exists. IRC is a medium that built the foundation for nearly real-time chat we take for granted today in Facebook, Google+, other instant messenger services, SMS, etc.
Look at a product like Facebook; ubiquitous now with nearly 1.5 billion users. That service is an amalgamation of many of the basic features available in those early systems. It was initially new and inventive, even though it was an improvement over earlier offerings such as Friendster, MySpace, and Orkut. Over time it’s remained relevant because of iterative usability measurements, feedback, and improvements of broken systems.
User behaviors are analyzed in realtime by many modern websites, and Facebook is a great example of real user monitoring of features as they are rolled out and tested in a production setting. If any of these systems are broken, either due to misconfiguration or software bugs, or just because the feature isn’t well received or is a bad user experience, the measurements tell the tale and corrective action can be taken.
Etsy is another great example of a team using this approach as they are known to release 50-60 small iterations of their software to production in a day and utilize feature flags around their software to toggle the availability of that feature to the public. This approach is tremendous for collecting data assuming you’ve set up your application appropriately to do so.
We follow many of these processes at Cox Media Group, but we’re always improving, too. My advice: get a handle on your front end instrumentation and testing strategy early and stick with it. Establish a performance budget with your business partners and other crucial team members, monitor and measure, and react when you start to slip. Reinforce your best practices through automation and code reviews, linters, and git hooks; reject any code that doesn’t pass the bar and help your fellow team members improve their discipline. Prototype new apps or user experiences quickly using tools such as yeoman, bower, and grunt/gulp. Sit in on user studies and really gain an appreciation for objective observation of the users of the things you build. Small development iterations provide clarity, while metrics and user feedback inform your next move.
As a frequent user of various Internet services and applications, mobile devices and computers, TVs and coffee pots, doors and escalators, take the time to occasionally outwardly observe yourself or your space, your home or work habits, your commute, whatever. What do you see that might be broken? What about the products and services you use? Are you working around bothersome or cumbersome systems just to complete simple tasks?
Usability is a discipline that always strives to observe and collect data and focus on improving the ease of use of something. We live in a golden age of information, automation, and smart devices. The most crucial piece of these systems is you, the user. Without the user, these systems become broken themselves. Do yourself a favor and break the systems that aren’t necessarily broken, correct your own behavior and subconscious work arounds, and focus on improving that next iteration. Be the empowered user and don’t just self correct but fix the broken parts of the system in your experience.