The theory of metaphors, or why Metaverse will fail
User interface metaphors, such as the PC desktop with documents and folders, can help people in learning to use an unfamiliar system. If the metaphor is too literal, it will lead to an inferior user experience and frustration. In this post, I’ll discuss the theory of realistic physical metaphors and why you should avoid them.
The trend of designing realistic virtual 3D worlds has emerged again. The grocery shopping demo of Walmart [1] and naturally Metaverse for remote work [2] have been going rounds in social media lately.
This is a de-ja-vu from mid 90’s when similar ideas were popular, together with the advent of “information superhighway”. There are reasons why interfaces that mimic the physical world didn’t become popular, and the same reasons still apply for the latest incarnation of this trend.
One of the reasons is the problematics with the real-world metaphors.
What is a metaphor?
Wikipedia defines the metaphor as “[…] a figure of speech that, for rhetorical effect, directly refers to one thing by mentioning another.” [3]
Let’s use as an example the phrase “TV is chewing gum for the eyes” attributed to Frank Lloyd Wright. This is a metaphor comparing TV to chewing gum: the TV keeps your eyes busy just like your teeth, yet you don’t get any nutrition to your soul.
Here, the chewing gum is called a vehicle. It carries the meaning — the properties of the chewing gum — over to TV, which we call a tenor. In this post we talk about metaphors in computing, so it’s simpler to replace the word tenor with system.
Metaphors are important tools for our thinking and we use them every day. Especially the modern-day computers are full of metaphors. We use a computer desktop with files and folders without thinking that these are metaphors that describe how the bytes are organized on our hard disks.
Why do metaphors work?
A metaphor transfers our knowledge a familiar concept to an unfamiliar one. We understand that a physical folder can contain several documents (or files), and therefore we can expect the same about digital folders. We know intuitively that on the computer desktop we can put a document inside a folder or throw it away to the trash can to delete it (or restore afterwards), just like in the real world.
At the same time, metaphors create expectations that limit our understanding of how computers work. For example, it would be technically trivial for a digital document to reside in two folders at the same time, but this would be in conflict with our perception of physical documents: you just can’t put the same physical paper in two folders.
This is the first important lesson about metaphors: the vehicles help but at the same time they limit our understanding of the system.
Mapping the vehicle and the system
We have now defined the vehicle (V) as the concept that implies functions, such as physical documents can be put in a folder, and the system (S) that implements a group of functions, e.g. the user can put a digital document in a digital folder.
With these definitions we can draw a simple diagram (as in [4]) with four categories:
1. Features of the vehicle which map completely to the system (S+V+)
These are the features that work as you’d expect. In the 3D grocery store, you can pick up a milk carton from the shelf and place it in your shopping cart.
2. System features that do not map onto features of the vehicle (S+V-)
These features are not part of the metaphor and therefore hidden from the user. For example, in the 3D grocery store, you can remove an item from the cart and just throw it away, which you would never do in a physical store, or that there is a shortcut to pay for the groceries without needing to wait in line to the cashier.
Physical metaphor can hide your valuable features
Because these features are hidden, this set is less problematic for the user but possibly detrimental to the business value of a solution.
3. Features of the vehicle that do not map onto the system (S-V+)
These are the features that the metaphor suggests that would be possible, but are not part of the system, or otherwise work differently.
These features are called “conceptual baggage” [4] and according to Anderson et al. [5] they cause most of the frustration. Users are convinced that the system possesses the features that the vehicle implies. They repeatedly seek the features in the wrong places of the UI, or they look for features that simply don’t exist.
Physical metaphors carry heavy “conceptual baggage”.
For example in the virtual 3D store, you may think that you could visit the same store with a friend, or that other virtual store visitors can see your shopping cart therefore compromising your privacy.
4. Features that are not part of the vehicle nor of the functionality of the system (S-V-)
This section is not that relevant for the design but may help the selection of appropriate metaphors.
Abstract metaphors
Why do the current desktop metaphors work, then? Why don’t people react strongly against files and folders on the desktop?
The reason for this is that they have been around for such a long time that they have evolved beyond being metaphors of their physical counterparts. In the early days, they certainly helped people to understand how to use graphical user interfaces: how to store documents in folders instead of moving them with command line operations between directories.
Since then people have learned to use the desktop metaphor so fluently that the digital versions of these concepts have themselves become vehicles. They don’t try to be realistic representations of the original physical objects, and they don’t carry the conceptual baggage of the original metaphor anymore.
Designing metaphors
Here are some recommendations, if you plan to use physical metaphors for your system.
1. Map the system features first
Plan the system functionality based on the analysis of the user needs. Don’t add or change features just so that your system would be a better fit to the metaphor you choose. If you do, then you optimize the functionality to match the metaphor, not because the features would be useful or usable. This would be a tail wagging the dog (metaphor intended).
2. Design alternative metaphors
Design several appropriate metaphor candidates. You should base the metaphors on your understanding of the target user group(s) of the system. What kind of metaphor vehicles are they familiar with?
3. Minimize conceptual baggage
Analyze your metaphor candidates by identifying how well they cover the system functions in the four areas (see the S/V chart). Select the metaphor that primarily minimizes the conceptual baggage (S-V+), and secondarily that doesn’t leave too many features hidden (S+V-).
4. Test the metaphor
See how your potential target users react to the selected design and the metaphor with rapid prototypes. If you observe that people try to find features your system does not support, you are probably witnessing conceptual baggage (S-V+). If people don’t find system features that you think they should, you are likely to have hidden features in your metaphor (S+V-).
To fix the shortcomings, it is a better idea to make the metaphor more abstract or move to another metaphor altogether than start changing the functionality of the system, as mentioned in step 1.
Conclusions and the prophecy for Metaverse
My recommendation would be to avoid using strong physical metaphors in the first place. It is quite rare that you can find a perfectly matching metaphor for your system functionality. It’s safer to use more abstract conceptual mental models that are familiar to people in graphical user interfaces, such as menus, lists, forms, buttons, etc.
If you still want to use physical metaphors in your designs, plan the system features first to match the user needs, then select an appropriate metaphor that minimizes the conceptual baggage, as instructed above.
If you find yourself explaining your user interface with sentences like “it’s like a real X but…”, it’s an indication that you should reconsider your choice of the metaphor.
Coming back to the Metaverse: it is a highly realistic physical metaphor for remote work, and because of the reasons discussed in this post (and other problems of 3D navigation) people will find it annoying and cumbersome. Collaboration tools that use more abstract mental models will win over Metaverse, just like current online shopping wins over the Walmart concept.
Oh and one more thing: skeuomorphism
When I discussed the topic of this article, the term “skeuomorphism” came up. What is the difference between skeuomorphism (s11m) and metaphors? However, for me s11m refers more to the materials how objects look and feel [6]. For example the cover of a digital book can look like leather on display.
Metaphors have their background in literature and therefore they are more abstract and refer more to the purpose or the function of the thing. This is why I think metaphor is a more accurate term for this purpose. It was used in the original research in the 90s. Maybe nowadays we could use these terms interchangeably.
References
[1] “Reimagining Retail With Virtual Reality”, Mutual Mobile 2017
[2] “Mark Zuckerberg reveals his vision for working in the metaverse”, CNET Highlights 2021
[3] “Metaphor”, Wikipedia
[4] “Metaphor Reflections and a Tool for Thought”, Smyth, Anderson, Alty, in HCI’95,1995
[5] “Minimising Conceptual Baggage: Making choices about metaphor”, Anderson, Smyth, Knott, Bergan M., Bergan J, Alty, HCI ’94, 1994
[6] “Skeuomorph”, Wikipedia
