Home » Tutorials » Information Architecture » Representations


A representation itself is an abstraction from an object. With that said, the state of a representation is how far it is deviated from the initial object that it represents. In terms of usability, we often study the effects of a metaphor to portray an idea, and I would state that metaphors are very similar to representations. I actually believe them to be the same thing. People tend to thing of representations as images or graphic constructions that simplify a previous object by removing the less relevant aspects of the initial object. Despite the tangent, representations are very effective ways that you can tailor your content to your visual learners. Also, representations can reduce the complexity of a situation by removing the less important aspects.

Think for a minute about how many representations that guide you through life every single day. If we didn’t have representations you would be in complete information overload. For example, in an average week, you might use Google maps or a GPS, which shows you the roads to get to a certain location. That is awesome, but think of how many aspects Google leaves out in delivering you the representation. While they do have the option to give you a satellite view where you can see the trees, mountains, etc., but they don’t include it initially because it would just confuse the user. Let’s take a look at a critique of a representation found on a refrigerator:

A critique of a Graphical Representation

The graphic, admittedly, is a very sophisticated system of representations of how this particular refrigerator operates. Without previous abstracted representations, one still may find difficulty in interpreting the knowledge embedded inside this graphic. However, it is probably expected that the user already possesses knowledge of the internal workings of a refrigerator. From the representation, I have developed a relationship between the programming concepts of inheritance and objects to relate to the understanding of representation and abstraction (Abstraction is also a term used in OOP as a slightly altered relationship to another object). This graphic can be deduced to a complicated meta(meta)representation.

One of the obvious and simple representations is the magnet inside the compressor utilizing the characters S and N. The more complex (meta) representation incorporates the basic magnet into the entire compressor. While it is interesting to analyze the representations and abstractions, they all collaborate to give us this greater understanding of the internal process of a refrigerator. Granted, the graphic lacks many fundamentals of a great representation, but it does immediately register as a process. With some external knowledge, we can guess that the representation begins shortly before the thermostat, and ends slightly after the compressor.

A final important interpretation from this exercise is not to forget the human constant when designing representations. It isn’t abundantly clear what knowledge can be inferred from this graphic. Ultimately, the graphic demonstrates how a representation system is still dependent on the people and context.

What have we learned from the refrigerator representation? We should have noticed that the representation omitted a considerable portion of context. You don’t see an actual refrigerator do you? When the person who created this representation was designing this graphical representation, they clearly believed that the image was useful for those individuals who might need to gain information about how this refrigerator worked. I would assume that the average person is clueless about what this graphic is intended to explain, which tells us that all graphical representations are dependent upon the user’s experience. Sure, an electrical engineer probably could spend the day explaining this to us, but without him, the graphic is just an image without meaning. When designing your representations, think of the knowledge dependencies that are required to understand it. Blindly creating representations is not exactly a useful practice and might actually be counterproductive for your user. Think to simplify from your users’ viewpoints.

Link/cite this page

If you use any of the content on this page in your own work, please use the code below to cite this page as the source of the content.

  • Stewart, Suzy. "Representations". After Hours Programming. Accessed on April 24, 2024. https://www.afterhoursprogramming.com/tutorial/information-architecture/representations/.

  • Stewart, Suzy. "Representations". After Hours Programming, https://www.afterhoursprogramming.com/tutorial/information-architecture/representations/. Accessed 24 April, 2024.

  • Stewart, Suzy. Representations. After Hours Programming. Retrieved from https://www.afterhoursprogramming.com/tutorial/information-architecture/representations/.

1 thought on “Representations”

  1. well structured and made sense, have that info in my brain from statistical analyses etc, but still struggle with the complexity of my website a bit, i get a conceptual idea in my mind as i’m working on it, then realise that i’m overlapping things and there are a lot of links that would ordinarily not be considered ‘right’, but when taking the perspective of different users of the site then some pages need to be accessed from different ‘angles’ it took a while for me to realise that this is ok and your tutorial confirmed my uhuh moment… thank you

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.