User interfaces building is still new compared with other professions. As a result, telling people outside the industry what UI design and development often results with me rambling and handwaving. My most common rant begins with “You know, like in apps and websites, I put the buttons and stuff on the right page…”

Many other industries have been the “technology industry” of their day. Today, those same industries can provide helpful analogies in articulating things about software. The benefit of comparing software to building construction, automobiles, or living organisms goes beyond making conversation smoother: we can better frame our rationale to non-designers, or justify certain approaches based on cross-disciplinary techniques. Moreover, analogies can inspire us with how other craftspeople approach problems.

The house or building architecture analogy

In the world of building construction, architects are kind of like UX designers. They envision an overall experience that meets the need of the structure’s future inhabitants. When people enter, how will they flow easily to their needed space? They respond to constraints and delivery deadlines. An interesting sub-discipline in construction that relates to UI’s is signage, which is just like navigation and guidance in software. For this reason, I find airports and theme parks endlessly illuminating. Consider the challenge of the original airport architects: occupants will need to quickly grok check-in desks, plane gate, bathroom of their gender, and purchase food, while not speaking a common language. So, architects and signage pros have invented a bevy of iconography, structure, and color to communicate navigation.

One cautionary note about comparing software with construction is that, software development should not end, in the same way buildings are built. Software must continue and evolve after first launch to address new constraints and performance issues, and the design iterates based on changing user needs and business goals.

The automobile analogy

Cars were the disruptive force in Western society in the early 20th century, liberating many people to move outside their agrarian origins to urban areas then suburbs. A car meant freedom, and in the US, often to go West in search of greener pastures (like my parents did). I view the web as a similar force, enabling people to have unprecedented reach beyond their geography.

The assembly line and mass production of cars transformed how complicated products were made. Henry Ford, Japanese automakers, and countless other automobile creators pioneered techniques for efficient product, like the assembly line, Kan Ban, and agile techniques. Another interesting theme I see the web development field importing from automobiles is component-ization. For instance, my Dad engineers specialty shock absorbers, one small piece of a car, and only that. His customers many different carmakers with different needs. His parts have sub-parts which have sub-parts, so the hierarchy structure matters. With web technologies like React components or Polymer, UI designers are increasingly able to just browse through available “parts” with which to assemble into a full product. Some have dubbed this atomic design, and it’s likely to increase as web development matures.

The genetic engineering analogy

Alright, I admit this one’s a bit of a stretch. But, as a recovering bioengineering major, it’s also my favorite. Geneticists are now able create man-made organisms, from bacteria to mammals. Applications for bioengineered bugs, plants, or animals can range from biofuel generation, to lab meat, to geoengineering. Now imagine if these genetically engineered creatures were then released back into the wild, to live or die based on their exhibited traits, not necessarily their natural evolved traits. This would likely resulting in death for the organism, unless the geneticist carefully imbued it with traits suited for it’s survival, knowing ahead of time which problems the organism would face, and how to build their corresponding solution.

It’s often useful to talk about software as a living thing. It can “get sick” and break down unless given the proper care, and the older and bigger it gets, the more oafish and unhealthy it becomes. There’s often a lifecycle of growth, maturity, and degradation in software, necessitating new versions of itself. Plus, that’s not even considering its survival in the marketplace. Without being valuable to buyers, it won’t survive for long either.

Like the metaphorical geneticist, UI creators are like “intelligent designers” of life, caring for and nurturing new software while ensuring that it possesses the traits necessary to endure and succeed once released. We are the builders of complex entities which must thrive in complex environments. Therefore, we need the ability to experiment, both in the lab with a variety of “characteristics” of our design, but also in controlled ways “in the wild” through techniques like split testing and limited betas.

One similar software metaphor that I love from the The Pragmatic Programmer is gardening. Plants need tending to, wither, and sunlight changes, requiring frequent care.


Look to examples in the world of tough problem-solving at scale to find inspiration for and the words to express your designs and code. I see industries like construction, automobiles, and life sciences as helpful for my communicating my UI work.