The software design process is a gold mine for metaphor

I realized this when I started getting into web design. Coming from a Studio Arts and Design/Build construction background I was once pleasantly welcomed with familiar terms like page, window, artboard, framework, architecture, parent, host, developer….the list is endless. In fact, the vast majority of these technological terms seem to be terms that already exist. Designing for web is a breeze! But for better or worse, metaphor can only get you so far, and one must try to leverage the similarities and side-step the limitations as much as possible.

Software design thinking cannot even exist without interface metaphor. You want something to disappear? Click the trash can. You want that file to appear? Open that folder. This makes sense, and we need it to. The early tech pioneers had to start somewhere, right? After all, the software systems design industry was not the first to use metaphor. Ideas have precursors, and the argument for absolute creativity is a difficult one. The more people who can relate to an idea or product generally translates to its success.

The floppy disc: the floppy frontier?...

However, sometimes even universal icons aren’t that cut and dry in our post-digital era. The race for representation is ruthless. And at that, how can you be sure you are representing something (or even a process) that you can’t see?

Take the floppy disc for example. Although the physical floppy disc has gone the way of the dodo, we still seem to accept it as the universal ‘save’ icon. I guess this is only because we haven’t come up with a better icon yet. It’s like the floppy disc icon is awaiting its impending doom for not being self-referentially competitive anymore.

Who knows, maybe it will be the final conqueror (or... saviour...) whose bust is gilded onto one side of every bitcoin, whose symbol represents the mythical god of Information Security in an age of accelerating change! (trumpets die down…). Whatever its final destiny, the floppy disc icon seems to still fit within the canon of UX best practices. But if you do opt to use it in your design, just remember to not overlook what, where, when, why, how that something is being saved. And talk to the developer about it.

Metaphor as Medium, at Ludicrous Speed!

To take this critique on metaphor to perhaps its most outer limits, let’s consider a scene from Mel Brooks’ 1987 spoof Spaceballs as an example: Dark Helmet and his evil henchmen are actually watching the movie Spaceballs to locate the whereabouts of their nemesis Lone Starr in future scenes. They acknowledge they exist in a movie, and choose to leverage this, however ridiculous it seems. Alas, they quickly encounter a minor glitch in their plan when they find themselves wedged in the infinity mirror of watching themselves, in real time, in the movie you and I are watching.

That glitch represents the boundaries of their strategy, or metaphor. Luckily, Helmet and his men are cunning enough to hit the fast-forward button to climb out of the rut of self-reference and gain the information they need. But not all of us may be so fortunate.

Depending on how you use it, the medium or metaphor you choose can help or hinder your strategic process. However triumphant Dark Helmet was with this particular plan, he ultimately does get defeated by the forces of good. And whether his looking for short-cuts lead to his ultimate demise, we will never know.

As UI/UX designers, we must strive to be as cunning as to throw in a VHS of ourselves to view the future iterations of our ideas; we also sometimes need to just say enough is enough. And yes, there are real tools of the user experience design process trade that are effective in doing so, not to mention other team members that thankfully keep designers in check :)

Design/Build, Rinse, Repeat, Rinse, Build/Design…

What I’m getting at is this: designing for web applications is not anything else. Sometimes a project seems so complex you don’t even know where to start the conversation about it. Designing a product with a rich user experience is difficult to do in a vacuum, and to try to explain this to clients and stakeholders is sometimes painstaking, but very necessary. We can use simple comparisons to help paint a picture (like saying the designer builds the forms and the developer pours the concrete) but we may be doing a huge disservice to the creative process. It infers that things fall easily into linear handoffs, that developers only come in after the decisions were made, and that the entire prototyping/testing stage can be bypassed. These things are advised against.

Good design is group design. Group thinking is good thinking.

We all know that involving the whole team from the beginning has enormous benefits, so maybe that conversation should involve more individuals from more corners of the project. In other words, the goals of the project will tell us which tools/team members to use. Or to pose a further question: what strategies can we use to better understand the goals of the project?

Design by Analogy, not Metaphor

Metaphors help to bridge the gap of misunderstanding, but should set out to describe the reality on either side of that gap. To say something is analogous to something else is less restraining than saying it is something else. It’s a simple yet effective solution. If you’re constantly tethering a new idea to an existing idea, for ease of understanding, you forget that you are working on something unique.

And if you want a clear definition of the literary terms, here’s a helpful link: https://copyblogger.com/metaphor-simile-and-analogy-whats-the-difference/