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. Google’s map data has gotten so rich, it seemingly approaches real world detail. So much so, people start mistaking the model for the real world. Only to their own peril. 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.Anyone who has commuted has experienced those perils.

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, self driving cars, smart homes etc.

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 millennia. 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 plausible 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 must adapt to the operating environment 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. Here is an example of well intentioned friction-less user experience gone wrong.

While there is nothing wrong with a design goal of making the real world easier to understand, 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 related 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 system confirms on defaults. Why not let commuters build their own intuition where the models are 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 in the real world, not just Google. We can finally 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. Even better, by adapting design to resolve ever evolving user constraints, you can even advance the notion of “incomplete” design to “timely” design.

Our tools have arrived in the digital age. Can we get our methods to catch up from the industrial age?

Art Credit: Photo by AbsolutVision on Unsplash