It turns out that some people do spend a lot of time pondering the contents of their pockets. A couple of months ago I heard a podcast by Adam Townsend musing on the how to make change with the fewest number of coins. He noted that in the UK, self service checkout machines are generally not very efficient about the process. While the mathematical challenge intrigued me, it is the design problem he presented that has stuck with me, because it highlights the challenges we face we don’t consider that the tools we build may need to adapt to broader contexts of use.
In the case of the coinage, most of the automated checkout machines in use worldwide were designed in the United States and made to accommodate American coins--of which there are a limited number. Thus, there are not enough tubes for the range of coins used in the UK (and many other countries). In these places, the machines do not may return change in non-optimal coinage combinations (at least if you consider optimal to be the fewest number of coins).
Other than a potentially heavier wallet, I will admit that this particular example doesn’t reflect a situation of large consequence. But it does illustrate what can happen when specific use cases get hard coded into design--a challenge just as relevant for physical products as software.
The reverse side of unintentional consequences happened with the Honda Element. The car was designed with active younger men as a target audience. In order to understand this demographic, teams visited the X Games, and ran interviews and focus groups. Their learnings led them to design a vehicle that was inherently flexible, with folding seats, side doors and an easy access tailgate. It turned out that this flexibility appealed to a far wider audience. Pet owners could load in messy dogs without getting the seats dirty, older people could load groceries without bending over, and it was fun, sporty, and reliable. By designing a vehicle that was adaptable to a broad range of uses, Honda created a product that worked well for a lot of different people.
Both of these example raise the question of how do we do what we can to ensure designs are flexible, and can push beyond the bounds of their intended use, instead of potentially forcing people to adapt to someone else’s ideal use? A starting point comes from thinking through the different possible contexts in which a tool or product may be used. Some may simply require broadening the field of possible users. Although I am right handed, in my family I am in a minority so I notice all tools and desks that do not work for lefties. Beyond what are (hopefully) clear cases that should not be overlooked, a bit of research can quickly uncover a range of unanticipated uses, as humans are extremely good at not following expectations!
Kleenex tissues were originally sold as makeup removers, but people started using them as disposable handkerchiefs and the company soon went along with it as its primary marketing angle. Wordpress had a theme aimed at weddings that was co-opted by sports teams.
This not not an argument to build for all possibilities, or to cater to the minority. For instance, several years ago I worked on a project that revealed that equipment in certain countries required a robustness that was not needed elsewhere. To build this into the entire product line would not have been a good use of resources and would have raised costs (but it did tell us the existing product would not export well). At the same time, creating a base product architecture that is adaptable to retrofitting as appropriate could be the basis for a flexible solution. While there is no one solution, ensuring there is more than one use simply requires an open approach to what other people might need.