The Art of “Incomplete” Design
A map as detailed as the territory it represents is of no use. Maps become useful when they leave details out. Jorge Luis Borges’ 146 word story, On Exactitude in Science, illustrates this beautifully. A kingdom creates a perfect map “which coincided point for point”. “Following generations”, which didn’t love cartography as much, found it “useless”. They consigned the map to ruin under “inclemencies of sun and winters”.
Fair to say, Borges’ cartographers didn’t have something like Google Maps. Where you can represent the perfect detail, at least in theory. And you can have turn-by-turn directions without getting paralyzed. Also, they didn’t have machine learning to create and update map data, like Google does. So the snapshot doesn’t get stale. Google’s map data is so rich, it approaches real world like detail. So much so, people start mistaking the model for the real world. Only to their own peril. Anyone who has commuted has experienced those perils. When algorithms start re-routing people real time in rush hour, oblivious of peculiarities like steep grades and tight streets with parked vehicles, traffic jams start popping up in erstwhile peaceful neighborhoods.
Like in Borges’ kingdom, and with modern day GPS, we need models to build tools for navigating real world. But models, even most sophisticated ones, are incomplete because they have to leave some real world detail out. I call this — Model Incompleteness problem.
Designing for this model incompleteness is the core challenge of building software for complex real world domains — like human health.
This notion of model incompleteness isn’t novel. Kurt Gödel, a mathematician, implied the same for mathematical theorems in 1931. Steven Wolfram, a physicist and inventor of Wolfram Alpha, defined a concept of “computational irreducibility” in 1984. Wolfram said certain problems can’t be reduced to simpler models. There is no “fixed problem”, nor a “final solution”, determinable in advance. The solution emerges based on the path you take. In other words, the solution is path dependent. The solution design has to adapt as the problem understanding evolves, for each step you take along the path.
To understand further, let us compare an airplane and a bird. Both have the same “outer environment” — earth’s atmosphere. Their “inner environments” are vastly different. Birds are naturally evolved species. Airplanes are human designed machines. Birds have flight function evolved over thousands of millenia. We have evolved modern airplanes in less than hundred years. The resulting solutions — airfoils for an airplane and feathery wings for a bird — are different and reflect that path dependence. Despite the difference, both solutions are well adapted for the environments they operate in. Even though robustness of function depends on degree of adaptation. An albatross can fly for days on end hunting prey in raging sea storms. With airplanes, we have to be very careful about weather conditions, and the range of flight is limited by the jet fuel available.
Given the flying prowess of an airplane and a bird, it is remarkable we don’t know why things stay in air. Birds don’t know. They learn to fly from their biological programming. And while we have some theories, even we don’t know what creates aerodynamic lift. An interesting takeaway is that adaptive design can help create great technology from incomplete models. Wright brothers would never succeeded, had they pursued perfect understanding of aerodynamics. So we don’t need to pursue perfect model of understanding. Instead, we need to constantly adapt design to get to perfect understanding over time. Modern day airplane looks very different from the contraption that Wright brothers flew. It is because we have adapted design every time we ran into constraints.
Like an airplane, for any technology that has to operate in the real world, models are going to be incomplete. As a result, technology’s function has to adapt to the operating environment in a path dependent manner.
As we discussed earlier, in reference to building digital solution for the weight loss problem, you have to acknowledge model incompleteness first. And start with simplest possible design. In this case, a virtual service exploring the solution across variables concerned with nutrition, socio-economic challenges and physical activity. You have to think of it as a systems problem. As you explore, and resolve constraints, you get ideas for improvements. You try those ideas and keep exploring. The problem understanding and solution design evolve in parallel in a path dependent manner.
Google couldn’t have imagined what Maps service would look like in 2020. Just after launch in 2005, the route showed superimposed on the map image with turn by turn directions alongside. Only advantage over MapQuest was you could drag the map image around to view surrounding areas. Through constant adaptation, it is embedded in the social and cultural fabric now.
As great as Google and their maps service are, the rerouting issue demonstrates their poor understanding of model incompleteness problem as well. A design that reroutes without prompting commuters indicates complete faith in the model, over user intuition. The internet forums are rife with people discussing hacks to prevent Google from automatic rerouting. An example of well intentioned friction-less experience gone wrong.
There is nothing wrong with a design goal of making the real world easier to understand. However from a user perspective, there is a difference between “I understand what I should do” and “I don’t need to think at all.” A right question to consider is whether friction-less experience is offered as an option, or as the only choice. An alternate could have been rerouting getting offered as an option before deciding on defaults. Let commuters build their own intuition where model is incomplete.
In the same vein, the problem of improving health through digital means is exciting, precisely because, it lies at the boundary of science and art. We know better signals from data can improve decision making of patients, of care teams supporting patients, of researchers building products and services for patients. We also know any understanding solely reliant on data is reductionist and violates model incompleteness problem. The art, therefore, lies in understanding the incompleteness of models. And abstracting information for creating right decision making context for the users.
With cloud platforms scaling, all developers can build software that can be adapted for function, not just Google. We can build software without looking for a “fixed problem”, or creating a “final solution”. We can build from “incomplete” designs and let users fill the blanks. Only thing non-negotiable is commitment to iterate — to achieve better understanding.
Better still, by adapting design to resolve ever evolving user constraints, you can even advance the notion of “incomplete” design to “timely” design. As design guru John Maeda says in his new book, How to Speak Machine, “The cloud has made the pursuit of timeless design irrelevant — what matters instead is to be timely.”
Our tools have arrived in the digital age. Can we get our methods to catch up from the industrial age?
