A blossoming Neelakurinji flower2
A 12-year interval, give or take a few months, may seem to be an imprecise schedule when compared to the exacting timelines we use to create software. For many practical purposes, the cycle would be arbitrary and irrelevant. However, this interval works perfectly fine for observers of the Neelakurinji. Its relevancy is a matter of context. People expect the flower to bloom every 12 years, and, for them, the flower blooms at the exact right moment in time. Literary references to the flowering cycle date back to before the 17th century C.E. It may not be as fast as an app update, but the Neelakurinji has consistently hit its release deadlines for over 1,300 years.
Defining Relevancy
Terms like relevancy send epistemologists into a tizzy. What is relevancy, after all? It certainly sounds like something we would wish to achieve, but a precise definition is difficult to describe. One description of relevancy is that it is anything that furthers the completion of a goal. I like this one. If an experience helps a user complete her goal, it as relevant; if not, it is wasting her time.
Relevancy = Time + Context
The relevancy of any particular item is dictated by both time and context. A hammer is relevant when you need to pound in a nail, but it is less so when you need to turn a screw. Likewise, features of an application are only relevant when you need them.
Feature Creep
Victorinox manufactures Swiss army knives. Since 1891, the knives have held the imaginations and the occasional salvations of explorers and would-be adventurers, alike. Astronauts flew with the knives into outer space. Submariners dove with them down to the ocean floor. Their ubiquity is only surpassed by their utility.
Victorinox’s first knife contained four tools : a large blade, a reamer, a screwdriver, and a can opener. Today, the Wenger Giant Swiss Army Knife includes a telescopic pointer, flashlight, and compass, and 84 other tools.3 Weighing in at over seven pounds, spanning nine inches, and costing $1,300, the knife is about as handy as a toothbrush nailed to a 2x4.
Although the Wenger Giant sells more as a collector’s item than a functional knife, it does demonstrate how a useful and simple idea loses its usefulness over time through the addition of new features. I imagine that at some point over the years, someone thought, “hey, let’s add a cigar cutter!” Following this epiphany, subsequent tools were added, ranging from chain rivet setters to club face cleaners. Gradually, the knife grew in size and weight; adding one feature after another reduced the knife’s overall utility. For a knife is only as useful as its intended purpose: when you use its blade to open a delivery package, you are not using its corkscrew; when you use its flathead screwdriver to fix a toy, you are not using its can opener. Unneeded tools get in the way. Although a pocket knife containing five, or ten, or fifteen tools might be an acceptable tradeoff, 87 unique tools proves to be too much of a hindrance. Whereas the ratio of frequently useful to rarely useful tools is high with an original Swiss army knife, this ratio is lowered when more tools are added. As such, the extra weight and increased dimensions of the rarely useful tools become deadweight. Original Swiss army knives weigh a little under two ounces—equivalent to two AA batteries. In comparison, the two-pound Giant is equal to two, full-sized jars of mayonnaise . Which would you rather carry in your pocket all day?
As software creators, we sometimes make the mistake of providing too many features. Screens become cluttered. Menus fill with options. Paragraphs burst along their seams. Irrelevant features not only clutter interfaces, but they also blind users to the content and functionality that they need.
In 2001, Apple offered Mac users a quick and easy way to rip, mix, and burn CDs of their favorite music. They called the application a digital jukebox and named it iTunes. Its brushed aluminum interface displayed only a handful of buttons, which came as no surprise because, as Steve Jobs described his competitors’ offerings, “They are too complex, they are really difficult to learn and use.4” If only he had realized just how prescient his observation was about Apple’s own creation.
In the years following, iTunes would add its Music Store, integrate with Windows, sell music videos, rent movies, carry eBooks, roll out iTunes University, recommend Genius picks, allow Home Sharing, launch Ping, wreck Ping, remove Ping, present iTunes Match, offer iTunes Radio, push Apple Music, and market the iCloud Music Library. Though robust, the application’s user experience heaves under a thick blanket of bloated features, cryptic menus, and nonsensical signifiers. The once-promising elegance of a simple, scrolling list has been supplanted by competitive hierarchies and a fetishized affection for packaging art. iTunes contains a wealth of features; yet, the application struggles to make each feature relevant to a user’s needs.
Like the tools of a Swiss army knife, software must balance the ratio of frequently and infrequently used features. We sometimes build too much, encumbering users with the unnecessary, forcing them to hunt and pick through an assortment of functionality not relevant to their goals. Everything a user does not need distracts her from everything she does.
Humor
Mark Twain once wrote, “Explaining humor is a lot like dissecting a frog, you learn a lot in the process, but in the end you kill it.” If that statement is true, this chapter will be a bloodbath.
Humor is relevancy with a twist. We expect a particular outcome and—at the exact right moment—a twist delivers the unexpected. Uncertainty suddenly resolves, like a flower bursting into bloom.
Sigmund Freud believed the resulting pleasure of humor was the release of psychic energy.5 Try to remember the last time you did not understand a joke, and you will recall just how satisfying it can be once you figured it out. Consider the wisecracking response the writer Dorothy Parker gave to a columnist when challenged to use horticulture in a sentence:
“You can lead a horticulture, but you can’t make her think.”6
The statement supplants one context for another. Horticulture leads us to an expectation: something involving plants or gardening. We certainly do not think of a person. Only when we read the well placed “her” do we revisit our previous context and compare it to our new understanding. “Her” transforms “hor”; “ti” becomes “to”; and now we find ourselves guiding a prostitute to culture. We derive pleasure through the rapid resolution of these incongruities.
The 18th-century philosopher Francis Hutcheson wrote of perceived incongruity as the basis for humor in his 1725 work Thoughts on Laughter . Although one person’s humor frequently differs from another’s, people may find humor at all times and in all places. People quit their jobs, divorce their spouses, and attend funerals. Yet, you would be hard-pressed to not find at least a glimmer of humor within these experiences. An employee quits a job and steals her favorite stapler. A spouse files for divorce and buys hair plugs. A mourner attends a funeral and his Tainted Love custom ring tone begins to play. Reconciling an old context with a new reality can take us into the dark corners of depression or the sunlight of humor. More often than not, we choose the sun.
Especially with technology, we have become attuned to intractable frustrations, such as the “PCLOAD Letter” printer error made famous in the 1999 movie Office Space . Michael Bolton, a character in the film, pummels a printer into the ground with a baseball bat to the score of Geto Boys’ Still. Die muthafucka, die muthafucka, indeed. However, if we can intercept frustrating moments and turn them into humorous ones, we create relevancy with a distinctively human voice.
Versions of the Linux operating system add funny insults to error messaging, such as calling you a “Bonehead.” YouTube may report “A team of highly trained monkeys have been dispatched” in response to server issues affecting the site. You may have even seen Tumblr’s Tumblebeasts roam cartoon images of its datacenter. Each attempt at humor does not remedy all users’ frustrations, but it does help them adapt to their new reality.
Adaptation
Manual on Uniform Traffic Control Devices (MUTCD)7
Prior to the manual’s publication in 1937, road signage ranged from colored ribbons to hand-painted posts. Though ubiquitous on today’s roads, even the humble stop sign did not make an appearance until 1915,8 which is remarkable considering that people had driven cars for several years before anyone thought that stopping them occasionally would be a good idea.
Signage excels at helping users adapt to new information. If it did not, we would have many more highway pileups. We can leverage some of the same techniques to improve the user experience of software.
Road signs communicate by form and content. Rectangles convey guidance. Pentagons signal schools. Circles indicate railroads. Triangles relay caution. Diamonds forewarn danger. Over time, these shapes inform our schemas for each type of message. We view the shape and it sets our expectation for the content contained within it. Just as the word “STOP” written within an octagon aligns with our expectation for a stop sign, so too does an underlined piece of text set our expectations for a website’s hyperlink. People quickly understand meaning when form matches content, be it a highway sign or a sign-in button.
Reconsideration of a Goal
User experience is rarely a matter of going from Point A to B. Users confront obstacles, reconsider their goals, and sometimes redirect to new ones. Stores run out of stock. Auctions are outbid. Game characters die. Such events force users to reconsider their goals. They ask themselves: do I really need to buy this product… place this bid… complete this game? More often than not, they abandon the attempt. However, some users adapt.
Swiss psychologist and philosopher Jean Piaget first described how people adapt to new information.9 His study of childhood development led to theories about how new information is either assimilated or accommodated . We assimilate information when it fits within our expectations. We accommodate information when it requires us to update or create new expectations.
Imagine you want to send flowers to a friend. You hop online, find a floral delivery website, and browse the available options. You choose a dozen chrysanthemums and click the buy button. A moment later, an alert pops up and tells you the flowers are out of stock. You are forced to create an entirely new expectation—you must accommodate to the website. To keep the user from abandoning her current experience, we need to find a detour: rather than accommodate, we want users to assimilate .
Think about the last time you encountered a detour while driving. Perhaps an exit was closed. Did you stop your car in the middle of the highway, step out, and walk away? No, you likely quickly noticed the road closure and took an alternate route. The alternative was more convenient than abandonment. You assimilated the new information and kept moving.
We do the same when using software . Instead of presenting the out-of-stock alert in our prior example, we could hide the chrysanthemums until they become available. Alternatively, we could suggest another product or a later delivery date. All of these approaches keep the user within her current experience, because the experience remains relevant to her needs.
Relevancy redirects our behavior in curious ways. We may trek the flowered highlands of India, clobber a laser printer with a baseball bat, or zip down the highway looking for our exit. In every case, we pursue goals, seek relevancy, and adapt.
Key Takeaways
Anything that helps users complete their goals is relevant.
Features are only relevant when users need them.
Everything a user does not need distracts her from everything she does.
Use humor to alleviate frustrating user experiences.
Users assimilate new information when it fits within their expectations.
Users accommodate new information when it requires them to update or create new expectations.
Users are more likely to abandon an experience when they accommodate new information.
Questions to Ask Yourself
How can I make an experience more relevant to my users’ needs?
What might distract users from noticing vital information?
Where can I introduce humor into a potentially frustrating situation (e.g., server downtime)?
What are my users expectations for a product, service, or feature?
What ways can I make an experience feel familiar to users?
Which irrelevant features can I remove from an experience?
Are my users assimilating or accommodating an experience?