One of my favorite aspects of my job is discovering new workflows and new ways of using software in order to accomplish the same task. The customers I work with and their employees are always trying to do the same thing when they work with me, but because of the varied nature of their business and their offerings they do things in different ways. On top of that, everything from the staffing to the location of the computer within the organization influences the way they will use the system. When I conduct Operational Audits for our customers, I enjoy watching them go about their work, learning how they use our system.
This also gives me a unique perspective into usability, and the inevitable shortcuts people find around the system when a feature does not work well for them. Some people at the office cringe and grit their teeth when they see people using something in a way that was unintended, or outside of the normal. But me? I find it fascinating, and I always make notes and report back on what I see, especially if I am seeing the same type of work around for the second, third or fourth time. I strongly believe that if I am seeing the same shortcut multiple times at different institutions, there is an issue that needs to be addressed to enhance usability.
Tom Hulme, a designer and venture capitalist, touched on some of these same ideas in a February 2016 TED Talk titled What Can We Learn From Shortcuts? It’s a fascinating look into some common sense and yet revolutionary ideas in the world of design, as told by the most visibly invisible indicator: Desire Paths (short cuts).
What I found fascinating about the examples he presented in his TED talk is the response to the creation of these desire paths by people who are simply trying to get from point A to point B via the path of least resistance. In Brasilia, despite the danger presented to those who use the desire paths (crossing 15 lanes of traffic in one example!), people continue to use them and they remain unaccepted and ignored by the powers that be. At UC Irvine, they anticipated students creating desire paths between newly constructed buildings. Once those paths had formed, the university paved them to make them a permanent feature, thus accepting their existence. At the NIH, a desire path created by chemotherapy patients to get from the oncology building to their hotels was at first denied by attempting to cover over the path; but then it was accepted and the NIH paved it to make it permanent.
In software, when people create desire paths through a process, often they are met with a response similar to what you see in Brasilia. The system is designed to function only in one way, with one flow, and you shouldn’t be using it in other ways. But all this does is increase hostility to the system on the part of users, who are going to make their desire paths anyway for reasons that may or may not be important. Systems should be designed to be flexible (to a point) to accommodate some of these different desire paths; it boosts customer satisfaction and loyalty. I realize it’s not possible in all cases, but being a bit more accommodating can help both you and your customers work better, and isn’t that the point of software in the first place?