Just as you had mastered SEO, social media, and original content, along come platforms that threaten to disrupt all previous branding experiences.
According to a survey by Greenlight Insights, 53% of respondents said they would be more inclined to purchase from a brand that used virtual reality compared to one that did not.
Although we are now relatively more familiar with augmented reality (AR) and virtual reality (VR), it is still quite a challenge to understand how to design effective brand experiences with them.
You don’t want to invest in technology for it only to be a gimmick that does not significantly bolster your branding activities. And yet, there is the pressure to not get left behind while everyone else seems to be using cutting edge technology.
From start-ups to banks,design has never been more central to business. Yet at conference after conference, I meet designers at firms talking about their struggle for influence. Why is that fabled “seat at the table” so hard to find, and how can designers get a chair?
Designers yearn for a world where companies depend on their ideas but usually work in a world where design is just one voice. In-house designers often have to advocate for design priorities versus new features or technical change. Agency designers can create great visions that fail to be executed. Is design just a service, or can designers* lead?
*Meaning anyone who provides the vision for a product, whether it be in code, wireframes, comps, prototypes, or cocktail napkins.
In 2008, Lloyds Pharmacy conducted 20 minute interviews1 with 1,961 UK adults. Almost one in five people admitted to having taken prescription medicines incorrectly; more than eight million adults have either misread medicine labels or misunderstood the instructions, resulting in them taking the wrong dose or taking medication at the wrong time of day. In addition, the overall problem seemed to be more acute among older patients.
Almost one in five people admitted to having taken prescription medicines incorrectly; more than eight million adults have either misread medicine labels or misunderstood the instructions.
Medicine or patient information leaflets refer to the document included inside medicine packaging and are typically printed on thin paper (see figures 1.1–1.4). They are essential for the safe use of medicines and help answer people’s questions when taking the medicine.
If the leaflet works well, it can lead to people taking the medicine correctly, hopefully improving their health and wellness. If it works poorly, it can lead to adverse side effects, harm, or even death. Subsequently, leaflets are heavily regulated in the way they need to be designed, written, and produced. European2 and individual national legislation sets out the information to be provided, in a specific order, within a medicine information leaflet.
Adding to the design challenge is the fact that the guidelines for how medicine information leaflets are designed changes from country to country, and the guidelines are often vague.
One of the changes in the 2004 European Commission directive2 was to ensure that all medicine information leaflets ‘reflect the results of consultations with target patient groups.’ In other words, when producing a leaflet, user testing (or ‘readability testing’ as it is also known4) must be done. A satisfactory test outcome is when the information requested within the package leaflet can be found by 90% of test participants, of whom 90% can show that they understand it.3
The diagnostic testing method for medicine information leaflets also raises a unique challenge when designing leaflets and is more rigorous than the level of user testing most designers are used to.
Additionally, medicine information leaflets are required to be reviewed and approved by a competent authority, which varies from country to country, before being included in the packaging with the medicine.5
Possible Design Improvements
How can these materials be designed so that people end up taking the medicine as directed?
One issue with medicine information leaflets seems to be that most people do not read the document from start to finish, although it contains important information. Reasons for not reading or only skimming the leaflet from start to finish could be due to the amount of information or the leaflet design.
Competing sources of information introduce additional confusion. Sometimes the pharmacist will attach to the packaging a sticker with dosage instructions. That sticker can cover the dosage instructions printed on the packaging itself.
There are now potentially three sources of dosage information: the sticker, the packaging, and the leaflet, all with different densities of information. This creates an assumption on the part of the patient that everything they will need to know will be on the sticker–a dangerous assumption because patients do not read through the whole of the medicine information leaflet.
Medicine information leaflets are usually long and contain a wealth of information and complex terminology. An option would be to provide the document written to different educational levels.4
Sometimes leaflets do not make the most of headings and sectioning, which keeps people from finding quickly the information they need. Medicine information leaflets are usually minimally treated, featuring only plain text with headings in bold.
Could a more designed and illustrated appearance lead to people taking the medicine in the prescribed manner? A study6 suggests this is the case: Layouts that reduce text density, use purposeful sectioning, highlight key messages, and use a logical type hierarchy helped people to find the right information more quickly.
The example shown in figure 1.5 is a step in the right direction; the different types of information have been given a diversity of treatments to provide emphasis.
Layouts that reduce text density, use purposeful sectioning, highlight key messages, and use a logical type hierarchy helped people to find the right information more quickly.
In a similar vein, the United States Food and Drug Administration (FDA) recently proposed a redesign of nutrition labels on food packaging. Among the changes were putting calorie counts in large type, adjusting portion sizes to reflect how much Americans actually eat, and additional information about sugars in food.7
The Lloyd’s Pharmacy research stated that older people make the most mistakes when using medicine information due to either misreading medicine labels or misunderstanding the instructions. Clearer written instructions would solve the comprehension issue; a more ‘large print’ design would enable both older and a wider variety of people to better use the leaflet.
Medicine information leaflets are often printed on thin paper and folded many times to fit into the medicine package. There is a lot of show-through from the information printed on the back of the leaflet, which decreases readability. When the leaflet is unfolded, the paper crease marks affect the readability of the text (see figures 1.3 and 1.4). A possible improvement would be to print the leaflet on a thicker paper.
Article 63(2) of the European Commission, 2004,2 states that: ‘The package leaflet must be written and designed to be clear and understandable, enabling the users to act appropriately, when necessary with the help of health professionals.’
Diagnostic testing is examining an existing design to find out how it performs against the agreed performance requirements set at the scoping stage; for example, a satisfactory test outcome is when the information requested within the package leaflet can be found by 90% of test participants, of whom 90% can show that they understand it. Diagnostic testing takes the actions of people using the document as symptoms of the document’s health and is concerned with finding out what is wrong with a design. Diagnostic testing should be used iteratively—that is, repeated until its performance reaches the agreed benchmark. Diagnostic test questions are designed to see whether a consumer can find information quickly and easily and perform actions appropriately.8
Earlier research from Lloyds Pharmacy1 and Dickinson et al.6 demonstrates that design and writing has the potential to make a real difference in regard to medical errors and that design, writing, and production of a medicine information leaflet can have a real positive effect on people’s health.
The design of medicine information leaflets provides some interesting challenges because they might not be seen as a typical creative graphic design job. Just because they do not contain overly designed text or graphics, however, does not mean creativity is not needed, in fact creativity is usually lacking in leaflets typically produced.
Furthermore, creativity when designing medicine information leaflets usually comes in the form of clear writing, clear layout, and user testing—more of an information design challenge rather than graphic design.
The designer’s job is to clearly communicate the desired message. The designer also has to follow guidelines—in this case, not corporate identity guidelines but guidelines laid out in legislation and vetted by a regulatory body.
Effective design can make the difference between a person deciding to read a leaflet or not, or getting the information they need about the medicine they are taking or not. And that difference can be a matter of life or death. The not so typical design challenge of medicine information leaflets shows the importance effective design can have.
5 Medicines and Healthcare products Regulatory Agency. (2005). Always Read the Leaflet: Getting the best information with every medicine. Report of the Committee on Safety of Medicines Working Group on Patient Information. London: The Stationery Office. Retrieved January 2014, www.mhra.gov.uk/home/groups/p-la/documents/publication/con2018041.pdf.
6 Dickinson, D., Teather, J., Gallina, S., Newsom-Davis, E. (2010). Medicine package leaflets – does good design matter? Information Design Journal 18(3). Amsterdam: John Benjamins.
I went to art school. I studied painting until I fell out with the abstract expressionists and switched to photography. But I can draw.
What I cannot do is diagram. I always wanted to. I have models in my head all the time of how things work. But when it comes time to make a visual model of those ideas, I can’t figure out to to represent them. I find myself resorting to pre-existing models like four-squares or the Sierpinski triangle (I dig fractals.) For example:
Other than the oh-god-my-eyes color choices, my social architecture diagram has deeper problems. For example, the ideas in it are limited to threes within threes because that’s the form triangles take. The model served to communicate my ideas well enough for the sake of my workshop, but… shouldn’t form FOLLOW meaning? If I had more than four elements for any section, I’d have to either collapse two, or fudge it in some other way. I was sacrificing accuracy for consistency. But I didn’t know how to make to make it better.
A concept model is a visual representation of a set of ideas that clarifies the concept for both the thinker and the audience. It is a useful and powerful tool for user experience designers but also for business, engineering, and marketing… basically anyone who needs to communicate complexity. Which is most of us, these days.
The best known concept model in the user experience profession is probably Jesse James Garrett’s “Elements of User Experience.” The best known in start-up circles is the lean startup process. Both of these models encapsulate the ideas they hold in such a memorable way that they launched movements.
If you wish to clearly present a set of ideas to an audience and represent how they fit together, a diagram is much more powerful than words alone. Dan Roam points this out in his latest book, Blah Blah Blah:
“The more we draw, the more our ideas become visible, and as they become visible they become clear, and as they become clear they become easier to discuss—which in the virtuous cycle of visual thinking prompts us to discuss even more.”
Concept models can serve many purposes. You can use concept models to show your teammates how a complex website is organized before the site is built…
… or to help teammates understand how the site currently works…
… or to show end users how a service works, to help sell it.
I teach user experience design, and my syllabus always includes concept models. Students of mine who do a concept model before working on the interaction design and information architecture always make better and more coherent products. The act of ordering information forces them to think through how all the disparate elements of a product fit together.
The workshop was brain-candy and eye-opening: They covered how the brain processes information and how ways of interacting with information can promote understanding. BUT I still couldn’t make a model to save my life. I didn’t know where to begin!
At lunch, Stephen was manning the room while Karl grabbed food for them. I had been struggling with a model for negotiation I wanted for a talk I was presenting later in the program. Seeing Stephen idle, I pounced and begged for help.
Stephan P. Anderson is author of Seductive Interfaces and the upcoming Design for Understanding. He’s also a patient soul who will put up with ham-handed diagramming and ridiculous requests. He started to sketch my model and tell me what he was thinking as he drew. Then I had my bingo moment: Stephen had forgotten what it was like not to know how to begin! This happens to all experts. After a while some knowledge is so deeply embedded in their psyche they forgot what it was like not to know. They then teach the nuances rather than the fundamentals.
I suggested we do a think aloud protocol while he made a concept diagram; he would draw, and I’d prompt him to talk about what was going through his mind. He was excited to have me reflect his thinking back to him so he could become a better teacher as well. We arranged to have a sketching session after the workshop.
Later in the day, we met in the quiet hotel bar with wine and a sketchbook. I asked him what he wanted to draw. “Do you have something you are working on?” he asked. “That way I can focus on the model, rather than rethinking the ideas.”
Did I have a model I was struggling with? Always! I shared my new theory of the nature of digital products. I’ll be writing that up in another article when it’s done, but for now, the short version is that one must iterate through the elements of digital design, which include the framework, interactions, information structure, and aesthetics. But a product doesn’t become an experience until a person interacts with it; your design cannot be known until you see what happens when a human shows up.
Stephen’s first step was to ask me about my goal for the model. I said it was for students and young practitioners to understand the interdependencies of the elements, so they have a more iterative approach. And for critics to be able to understand why things are different, both good and bad.
Next, he did what I’d call a idea inventory. He brainstormed more elements that might play into the model. He made sure no ideas were left out. He made notes of those he suspected might be important in the margins. He sketched as he thought, sometimes just making meaningless marks, as if warming up his hands.
He then carefully asked about each element in my theory, making sure he understood each. What was an information structure and what was a framework and were they different? I ended up telling a little story about a product to make sure he got what I was explaining. I began to draw too, encouraged by his easy scribbles.
Finally, Stephen noted the relationships of the items to each other. Were some things subsets of others? Were some overlapping, or resulting?
Once he knew what each item was, and how they were related to each other, he began to sketch in earnest. He said, “I always start with circles because edges mean something. They mean you have four items, or five. Circles leave room for play.” His circles quickly became blobs and then shapes.
I don’t know if he’d normally talk to himself out loud when not encouraged to do so, but it was fascinating to to hear him free associate concepts, then draw them out. A string of concepts became a string of beads; moving through an experience became moving through a tunnel; intertwined ideas were a braid. Any important idea got a drawing.
Each time he completed a mini-model, he’d evaluate what was missing and what was working and take that insight to the next drawing. He made dozens of these little thumbnail drawings.
Stephen said, “one shape leads to another…a single word sparks a new representation—we’re always ‘pivoting’ from one thumbnail to the next…”
He pointed out what concepts were left out, or where they could be misinterpreted.
“You want to avoid 3-d, because it’s fraught with problems. You want to be able to sketch it on a napkin.” —Stephen Anderson, on keeping in mind the model’s goal
At one point, he became tapped out, and we spoke of other things. We stared out the window at the harbor, and I drank some of my wine, forgotten in the excitement of drawing and talking.
Then suddenly he started in again and produced a flurry of new drawings. I realized resting and mulling was important too. I was a bit annoyed with myself. An article doesn’t come out perfect in one writing session. Why should I expect a concept model to just materialize?
Finally he came to a stop, several pages filled with a jumble of images. We didn’t have a model, but we had many good directions. As we finished our drinks and headed toward the opening reception, Stephen told me, “You gotta get Dan Brown to do this, too.”
Dan M. Brown is best known in the user experience design community as author of Communicating Design and Designing Together. Both books benefit greatly by clear and succinct conceptual models, and the former even talks about how to use them in the design process:
Purpose—What are concept models for?
There really is only one reason to create a concept model: to understand the different kinds of information that the site needs to display. This structure can drive requirements for the page designs, helping you to determine how to link templates to each other. With the structure ironed out, you might also use the model to help scope your project—determining what parts of the site to build when.
Audience—Who uses them?
Use concept models for yourself. Ultimately, they are the most selfish, introspective, and self-indulgent artifact, a means for facilitating your own creative process.”
–Communicating Design: Developing Web Site Documentation for Design and Planning 2nd Edition, Dan Brown, 2010
Clearly, a guy I should be talking to!
The IA Summit was held in sunny San Diego in a hotel with not one but two swimming pools, so Dan had brought his family with him. When I asked him if I could watch him draw a concept model, he said, “I’m at the coffee shop with the boys around 6:30 every morning.”
You take what you can get.
The next morning Dan settled the boys in a corner with books, pastries, and an emergency iPad, and we got to work. We agreed he’d model the same concept, to control for variations. By now I had created a formula for the idea: (F+In+Is+Ae)+P=E. Framework, interactions, information structure, and aesthetics plus a person makes an experience. I was modeling in words as my friends were modeling in pictures.
I took Dan through the same story of an iterative product design process, since it had helped Stephen. I sketched it out. I felt like my hands were waking up from a long sleep, and they were eager to hold a pen now.
As I spoke, Dan wrote down key ideas and also began to scribble. He used the same process as Stephen: collecting the concepts then inspecting them for hidden complexity.
“A question I ask myself is ‘what needs unpacking?’ I can’t diagram an idea until it’s clear in my own brain.” —Dan Brown
He then took each concept and free associated all the sub-elements of the concept. He drew them out loosely, mind-map style.
Dan also started with the goal and wrote it out across the page.
He also asked explicitly who the model was for. To draw, he needed to visualize the audience. This reminded me of a recent presentation workshop at Duarte where we literally drew pictures of our audience. No work can be good unless you know who it’s for.
Dan made sure he didn’t carry anything in his head: All ideas were put on paper as a note or a sketch. When he had to turn a page, he ripped it out to lay it next to the other pages. I realized how critical it was to have plenty of room to see everything at once. I saw the same technique of storytelling and drawing of ideas.
Around now, Stephen joined us. He was excited to see what Dan came up with, enough to also climb out of bed at the crack of dawn. I listened as the two diagrammers discussed the poster session and the strengths and weaknesses of the ideas that had been presented.
Dan said, “You can look at people’s posters and see their process. They are so close to their own narrative…In one poster, the key framework was rendered in a very pale text. It was a good story, but there are things you want to jump off the page. For her, my guess is those steps were so self-evident she didn’t see need to highlight them.”
You have to have a beginner’s mind to explain to beginners.
“Speaking of beginner’s mind, so much of my design process is to throw it all out start all over again.” —Dan Brown
Now Dan began to model the concept. He emphasized the importance of sticking with very simple geometry–circles, squares, triangles, lines–not fussing with trying to find a perfect model at the beginning, just exploring the ideas and their relationships.
He also mentioned he begins with any concept in the model and doesn’t worry about representing order at first. He starts with what catches his interest to get familiar with the ideas.
Dan then deviated from Stephen by seeking the focal point. What concept held all the others together? What was the most important or key idea? He tried out placing one idea, then the other, in the center to see if felt right.
After scrapping one bowtie model, he paused. “I sometimes retreat into common structures and see how these common structures might speak to me. For example, time is one of those fundamental aspects, so I ask myself: How much do I need to show time here?”
He demonstrated by drawing swimlanes and sketched the ideas and their relationships in time.
“Are there other elements you often look for, like time?” I asked
“People,” he replied. “People and time are familiar concepts, easy for an audience to relate to. By using them as a foundation for a model, I’ve already made it easier for people to ‘get on board.'”
He stared at the paper, deep in thought.
Stephen then pointed at the page. “What Dan did here,” he said, poking at where Dan wrote out goal and audience, “I did also but didn’t externalize. I was holding it in my memory, but I like having it on the paper better.”
Eventually Dan, too, was tapped out, and his sons began to play Let It Go on the iPad at higher and higher volumes. He separated his sons from the electronics and left to prepare for the swimming pool.
After Dan, I knew I wanted to try to get one more person to model. Since I was lucky enough to be at a conference full of diagrammers, I chased Joe Elmendorf of The Understanding Group. He had just given a talk on Modeling for Clarity that my friends were raving about. And, with my luck still holding, I got to have breakfast with him. Happily, at 8 am this time.
Again, I saw what were becoming familiar concepts (inventory, inspection, relationships, then talk-draw.) I then focused on how he differed from Stephen and Dan. He choose to use the title of the diagram as an element. He did not iterate as widely as Stephen. He was the first person to argue with me about the validity of my theory, which was a great way to understand it (and benefited me by making it better!).
As well, he reinforced something Stephen had mentioned in his workshop and that Dan was obviously doing: Joe had a large mental library of typical models to draw upon, which got him started. Stephen keeps a Pinterest board full of inspiration, if you want to start your own “lego box” of models.
Overall, there were so many familiar patterns I saw in his approach, the differences were more interesting than important. I had my answer. I knew how they did it.
On the last day of the conference in the afternoon, Stephen and I were scribbling further on the model, playing with petals for the elements, when Dan Willis joined us. Dan is also a master of models as well as an inveterate sketcher.
Although Dan declined to diagram for me, claiming brain fatigue (a reasonable claim at this year’s Summit) he pulled up a chair and sat sketching next to us. It was companionable, to sit and talk and draw ideas. We moved back and forth from discussing life to discussing the ideas, teasing, joking, drawing. As we chatted, I realized this was a part of the secret. You need a thinking partner. Sometimes it’s paper, sometimes it’s friends; but it’s best when it’s both. It doesn’t always matter what you draw, just that you draw.
Dan Willis drawing nearby makes me happy.
Our brains work better when our hands are busy.
Later, sitting in the back of a session, I lobbed a model at Stephen, and he shot back with his own.
Then I saw another step, one which Dan had alluded to when he mentioned the poster with the key point too pale to read: You have to refine the model to communicate effectively. Type, color, and labels are all a key part of the communication process. While the model did stand alone without the color and type, adding those–and most especially getting labels right–made the model more effective.
After getting home, I started sketching how concept models were made. I drafted this article and then asked my friend Dave Gray if he’d do a quick edit. Dave was the founder of Xplane, a company that used diagrams–concept and other–to transform companies. Dave has been a proponent of visual thinking and clear modeling for years, and I consider him the master of making ideas visible.
Life then intervened and this article sat. I was busy with several things, including Lou Rosenfeld’s 32 Awesome Practical UX Tips. Dave presented right before me, and watching him sketch, I realized I just had to get one more diagramming session in. It was not enough to have him comment, I needed to see him draw. I was grateful I did; otherwise, I would have missed a crucial piece of the puzzle.
We hopped on a Google Hangout and he also drew out that same darn design model for me. I saw familiar patterns in his approach: inventory, unpack, relationship exploration. But he added a critical step I hadn’t thought of before: Test the model.
He’s currently writing a book on Agile, and it shows. He said, first design the test, then design the thing. For the model, he suggested using his WhoDo Gamestorming tool as a way to design a test of the effectiveness of the model. He lists who the model is for and what they will do if they understand the model.
Designing a test of the model’s success radically clarified the goals for the model. Testing it would make sure it did what you wanted it to do.
So then I sat down to make a model of how to make models. And it came easily.
Determine the goal: How will the model be used, by whom? What is the job of the model? To change minds, explain a concept, simplify complexity?
Inventory the concepts: Brainstorm many parts of your concept. Keep adding more in the margins as you go.
Inspect the concepts: Are there many concepts hiding in one? Do you really understand each idea?
Determine the relationships: How do the concepts interact?
Decision point: Do I understand the ideas and what I’m trying to communicate? Test: Ask yourself if the model “feels” right. If yes, then continue.
Iterate with words and pictures: Talk to yourself and draw it out!
Evaluate with yourself/the client: Keep making sure the drawings match the ideas you wish to communicate. Don’t punk out early! Rest if you need to!
Decision point: Does my audience understand the ideas and what I’m trying to communicate? Test: Can my audience answer key questions with the model? If yes, then continue.
Refine: Use color, type, line weight, and labels to make sure you are communicating clearly.
The concept model is invaluable. But like so many useful things, it takes time to make.
When my daughter first started drawing My Little Pony, she expected to start at the ears and draw it perfectly down to the hooves. She was angry when it didn’t work that way, and it took some convincing to get her to block out key shapes then refine the whole, and to use pencil before ink. When I sat down to make a concept model, I made the same mistake! I’d start in Powerpoint or Grafio, and expect perfection to flow from my mind.
No more! Stephen, Dan, Joe, and Dave taught me to play, explore, refine, test, and play some more until the result was right. Thank you all!
What makes an icon a valuable addition to the interface, rather than a mere decorative element? Intuitiveness, aesthetic value, memorability, intercultural perception? While an effective icon would combine many of those characteristics, I’d like to focus on one measure–speed of recognition, or how fast a specific icon can be discovered and identified.
In a simple leisure app, the difference in speed of recognition may be too subtle to have any noticeable effect on the overall experience.
This may be different for a complex trading application: The requirements for iconography here are more likely to prioritize speed, since every second spent on processing individual elements can have a significant impact on the effectiveness of the overall interface.
Semiotic theory and structure of signs
User interface, like any language or other communication system, is a construct, made using series of signs. Semiotics, a branch in linguistics that studies signs, defines a sign as being composed of two elements–a signifier (the form which the sign takes) and a signified (the concept it represents).1 A sign is a recognizable combination of a signifier with a particular signified.
The same signifier (form) could stand for a number of different signified (concepts), and multiple signifiers could be used to represent the same concept.2 It is this unique pairing that forms a sign and makes it meaningful in a particular context.
For example, the concept of a railway crossing can be represented in a number of different ways. At the same time, numerous interpretations can be suggested for the railway crossing road sign, by someone unfamiliar with the road sign system.
Based on this relationship between a signifier and signified, and their level of convention (symbolism), signs are classified into three categories:
iconic: relate to the concept through resemblance
symbolic: relate to the concept through convention, and
indexical: relate to the object through causation3
Typically UI icons are symbolic or iconic in nature, and many fall somewhere in between.4
Symbolic signs are often arbitrary and represent a concept in somewhat abstract way (using to represent ‘refresh’ function). Their meaning is usually difficult to guess and has to be learned.
Iconic signs, on the other hand, can represent concepts in a more literal way and their meaning can often be guessed using common knowledge (such as to represent ‘call’ functionality). Both types can adopt metaphors to enhance understanding.
Iconic versus symbolic
Some time ago I carried out a small icon intuitiveness test on Adobe InDesign and Quark XPress toolbars.5 The test participants, who were using the applications for the first time, were asked to guess the possible meaning of the icons.
I observed an interesting (although hardly surprising) pattern: When people were presented with unfamiliar signs, they usually tried to interpret them as iconic–based on the objects they resemble–and use existing common knowledge to understand them.
For example, the iconic ‘button’ sign in the InDesign toolbar was quickly understood and interpreted by all participants correctly. On the other hand, the ‘Free transform tool’ was less successful in terms of its communicative function. The latter is a symbolic sign with indexical features.
For designers, it is obvious that the icon is based on the graphical representation of the state that indicates an object has been selected for transformation. However, the people new to the jargon of the application tried to interpret it based on the elements of the sign they were already familiar with. Suggested interpretations included ‘cut rectangular shapes,’ ‘resize,’ ‘select an object by choosing points,’ and ‘select points.’
Naturally, interpreting more abstract (symbolic) icons took significantly longer than iconic signs.
Visual style and speed of recognition
If the icons have the same general shape and denote the same concept, what effect does their visual appearance have on the process of interpretation?
The author of an article recently published on Medium claims that a particular style–line icons–are harder for the brain to process than their solid style equivalents, and can ultimately lead to “cognitive fatigue.”
Setting aside cognitive psychology and theories on how brains process shapes, I wanted to compare the two styles of icons using the semiotic approach6 and some basic user testing.
This time, instead of guessing the meaning of icons, I was reading out the object names (e.g. Camera, Mail) and timing how fast people pointed to an icon that represented that concept.
Two versions, line and filled, of the same icon set were compared.
The participants7 were divided into two groups; each group was given one of the icon styles, initially, before trying the other style. The time taken to find and identify the icons is recorded in the table below.
The icons were in the same position for both rounds of the test, so due to the increased familiarity, the speed of recognition naturally increased for the second style, regardless which style it was.
On average, people who were shown the filled set first discovered the icons in 66.2 seconds, and those who were shown the line set first discovered them in 65 seconds. In the second round, the filled set was complete in 28.4 seconds on average, and the line set took about 30.4 seconds. The average increase in speed for the second part of the test was approximately 36 seconds for both groups.
There was no noticeable difference in speed of recognition for the two styles. So we could suggest that, if an icon is well designed and represents a particular recognizable shape clearly, its style doesn’t have a significant effect on the speed of recognition.8 The more notable difference, however, was in how individual signs relate to the concepts they represent–the relation of signifier to signified in particular signs.
The icons that performed faster in both sets were iconic signs–‘calculator,’ ‘camera,’ ‘mail.’ On the other hand, the icons that seemed to have required a short pause were symbolic: ‘download,’ ‘back,’ ‘copy.’ Even the ‘delete’ icon caused a slight delay in participants’ response.
Interestingly, even though some icons were slightly slower to be recognized, they were not always perceived as being harder to find. When interviewed afterwards, participants classified the ‘delete’ icon as being very easy to find even though it took them slightly longer than some of the others. My guess would be that the reason for it is psychological. We experience a certain satisfaction when discovering the signs we learned well, such as a trash can for ‘delete,’ a floppy disk for ‘save,’ and the like. They are like a secret code, and, feeling pleased with ourselves for learning them, we don’t notice that it took slightly longer to recognize.
The table below summarizes the performance of the individual icons in both sets. The icons with a red outline took slightly longer, on average, to recognize in both sets than the ones outlined in green.
Consistency in the use of terminology for the icon labels and functionality they represent also seemed to impact the speed of recognition. For example, those who were asked to find a ‘clock’ completed the task slightly faster than those who were trying to find a ‘recent or history’ function. In both cases, the function was represented by the same ‘clock’ icon.
Another aspect that could influence speed is proximity of similar shapes, as well as proximity of icons which represent related concepts. For example, both flag and folder icons (top right) are based on a similar size rectangular shape, which may have caused a slight delay in response. Another example is ‘important’ (flag) and ‘favorites’ (star)–they represent similar concepts and could therefore be mistaken for one another, particularly if placed close to each other.
Therefore, it was not the style of the icon set but rather the individual icons in both sets, their shapes, and their position in relation to each other that made the most difference in the speed of recognition in this test.
Guidelines for ‘faster’ icons
It is well known that icons with labels are more effective than icons alone, particularly for the learners of the application. This is expected, since a text label is a direct link that serves to bridge the gap between the signifier and signified.
However, sometimes, for whatever reason, you may need to use icons alone or use hover over tooltips only. You may also need those icons to be discovered and recognized quickly. Here are the guidelines when that’s the case.
When possible, choose iconic signs that relate to concepts through resemblance, rather than symbolic signs. For example, the ‘calculator’ icon on the left is expected to be discovered and recognized faster than the one on the right.9
For crucial concepts that must be understood fast and also for abstract concepts, a combination of word labels and color is more effective than an icon. For example, it’s this combination that allows the ‘stop’ road sign to be recognized quickly.
Placing icons that represent similar concepts close to each other–for example, ‘tasks,’ ‘inbox,’ ‘notifications’–may slow down the recognition of each individual icon in the group.
Terminology used in the user interface should relate to the icon labels as closely as possible. For example, if you are using a flag icon to represent ‘important,’ label it ‘flag as important’ rather than ‘mark as important.’
Above all, when testing the icons, the main focus should be not on the style but rather individual shapes of the icons, how they relate to the concepts they represent, and how they work with each other–visually and conceptually.
4This classification is made when comparing the interface icons to each other. In a more general sense, all UI icons are essentially iconic signs.
5The test was part of my BA dissertation based on a comparative semiotic analysis of the two interfaces.
6A semiotic approach views an interface as a medium of communication which operates through a form of metalanguage. All elements are seen as encoded signs and all operations represent communicative processes between the designer and the user of the system. The semiotic approach is not an alternative but rather complementary to the user-centred approach. While the choice of signs in the user-centred approach is mainly determined by empirical studies (the sign is considered to be successful when it is recognised by a statistically significant number of users), semiotics aim to provide a theoretical basis to explain the phenomenon of user-centeredness and direct the designer towards the correct choice of signification systems amongst all of the possible signifiers. A book by C. de Souza provides a great insight into the semiotic approach.
7Six people took part in the test (thanks to my brave and adventurous colleagues). While the number of participants was too low to make any definite conclusions, it helped to see the general pattern in interpreting the icons.
8It may be worth mentioning that two of the participants found the full set “easier on the eye.” While this could be the case, it could also be due to the their better familiarity with the solid style. Four other participants did not notice the difference between the two styles, and only mentioned that one was ‘black’ while the other was ‘white’ which they didn’t see as notably different.
9Note: This is based on my assumptions and observations of testing similar icons; those particular examples have not been verified by user testing.
Andersen, P. B. 1990. A Theory of Computer Semiotics. Cambridge: Cambridge University Press.