Design Intangibles

The last two on our list, Service Design and Design Thinking, are, at the time of writing, extremely popular concepts. Defining these two terms has spawned hundreds of medium articles and blog posts. They’re also a lot more theoretical, intangible, and broad practices, generally involving the whole spectrum of a human’s interaction with an entire system.

A good example of this would be if we were to consider the design of a museum. The whole end-to-end flow of ticket purchase, finding and accessing the venue, knowing which way to enter, finding a path through the various exhibitions, exiting through the gift shop, buying an overpriced scale model of a prehistoric ground sloth, finding the bathroom, exiting the building, and finding your car could be overseen by a Service Designer. At various points, UX would play a key role in the museum’s digital offerings (if we accept the common notion that UX is restricted to digital “experiences”), perhaps in a companion app that allows for interaction with the museums exhibits that could include audio commentary and maybe even augmented-reality additions to the real-world experience. HCD might come in to play when planning the ideal order that the exhibits would be visited in, either by focusing on a path that brings the most interactive, most exciting exhibitions in at a “sweet spot” along the journey, or by structuring them in a way that allows the knowledge from one exhibit to inform the experience of another. CX, then, could be arrows on the floor or a natural, followable path through the exhibits.

It’s highly likely that throughout our museum visit, we’ll encounter other, moretraditional design disciplines such as the graphic design of the exhibition summaries and a printed museum map. Furthermore, we’d also need to consider accessibility—both physical and digital—by ensuring we have things like wheelchair access, Braille translations, and audio descriptions for exhibits in multiple languages. Additionally, there’s likely a whole bunch of business- or industry-specific red tape to design around. A beautiful museum is useless if it’s a death trap that defies multiple health and safety rules. And we’ll almost definitely need to consider how we’re going to place security cameras and alarms to keep our bosses and insurers happy.

While this book is probably a UX book or perhaps (and if you ask me) an HCD book, a lot of the information from Part 1 can be applied elsewhere. I do, however, want to discuss the implications from Part 1 of this book mostly in relation to digital products—which leads us to focus primarily on UX and HCD. This book revolves around making decisions that affect the workings of digital products, with a focus on the real-world impact of those decisions. However, I do believe the discussions and ideas around Service Design, in particular, are worth exploring. Accepting that design has never started or finished on a screen is an important idea to keep in mind throughout our careers.

Another important reason for this limitation is that I’m trying extremely hard not to propose a new discipline or a new job title into this mix. Everything I’ll propose in the remainder of this book is designed to piggyback on, or bridge the gap between, existing stages of common UX approaches. When I talk about “environmental design,” for example, I’m not suggesting we adopt an entirely new design framework that we have to sell to our bosses or our clients. I absolutely do not want to spark an “Environmental Design” movement. I want to offer a few, slight mental shifts that I feel can enhance and re-frame many of our existing design practices in order to greater assist and respect the idiosyncrasies and fallibility of the human mind.

And while this list is far from exhaustive and the boundaries of a typical UX job (especially on smaller teams) are always blurred—information architecture, accessibility audits, UI, interaction design, and sometimes even copywriting and front-end development can fall into the gamut of common UX designer tasks—to discuss even this short list of deliverables in depth would be an undertaking requiring an entire book unto itself. Fortunately for us, there exist a plethora of UX-specific books that do just that, including Leah Buley’s The User Experience Team of One (Rosenfeld Media, 2013) and UX For Lean Startups: Faster, Smarter User Experience Research and Design (O’Reilly, 2013) by Laura Klein, to name but two. Furthermore, formal and informal UX courses and certifications exist in abundance—with a seemingly endless list of online courses and formal academic syllabi to choose from.

All of this is to say, while this book intends to present ideas that attach themselves to existing UX practices and processes, that presenting a deep-dive, exhaustive introduction to such is beyond its scope. Now, you don’t need to run off right away and clue yourself up on all and sundry related to UX—we’ll touch on many of its key ideas and artifacts as we progress through this book—but I’d thoroughly recommend that after—or even during—reading this book, you jump into some short beginner or refresher content on the follies of UX design if you’re feeling a little lost or forgetful when things such as wireframes, user testing, personas, and journeys are mentioned.

With a hopefully less-murky working definition of UX design, I’d like to propose what I believe to be an integral problem, both with the terminology and with the underlying practices of the discipline.

The Folly of UX: Control and Linearity

I discussed at the start of this chapter my general distaste for the word “user”—it’s cold and assumptive and just, well, a crappy way to talk about people. It also serves to create some cognitive and emotional distance from the actual human with their actual human brain and their actual human feelings, beliefs, talents, flaws, and heuristics. For some reason, at some point, someone arbitrarily decided that the correct way to talk about the people who interact with the things we make was to refer to them as “users”—and it’s stuck, and fighting it is fighting a losing battle.

Just to add to my cynical gripe list, I also really dislike the word “experience”—at least in this context. “User Experience Design” implies, intentionally or not, that experiences themselves can somehow be designed. This is a concept with which I take great umbrage—an experience is a combination of infinitesimal emotional responses, a conscious and subconscious self-deterministic processing of one’s self and one’s place in time, in space, in life. An experience happens both in the minds of the experiencing humans and the environment in which it is facilitated, and it impacts these actors in unpredictable and immeasurable ways. The outright hubris it requires to suggest that we are, to any degree, in control of the actual experiences people may have throughout even a single interaction is, to me, astounding.

Words are important, but there comes a point when one has to accept that an industry has its standards, and a big part of such standards are the arbitrary terms, job titles, and never-ending lists of acronyms that attempt to describe its machinations. UX is a thing, it has been accepted and embraced, and its impact on the design world has been, on the whole, extraordinarily positive. I do, however, feel like in our pursuit for control, and in the potential hubris that has seeped from the term to its practitioners, we’ve taken the discipline to a point where best practice, process efficiency, and ease of education has led us to an intellectual space that is a little too preoccupied with control and linearity.

This, really, is what I believe to be the root problem with the UX methodology at the time of writing. In trying to control as many aspects of an experience as possible, we’ve maneuvered ourselves into creating products and interfaces that are just far too linear. Without realizing it, the artifacts of our profession play directly into habitual restriction and attempted control. User journeys, for example, tend to be incredibly linear, as do the various “flow diagrams” we’re wont to produce. Looking more deeply, even the atomic forays into wireframing and prototyping often tend to focus on key “paths” through an interface, and user testing sessions often focus on the speed at, and efficiency with, people can complete these atomic, de facto paths. When people get confused, we add more wayfinding aides, we limit auxiliary information and tasks and we double-down on focusing on these key paths or points along them.

One of the key ideas that I hope Part 1 communicated is the notion that self-expression, displays of mastery, and perceived autonomy are key factors of intrinsic motivation. Oppressive linearity makes such activities and emotions impossible to achieve and experience. While clear wayfinding and constrained flows are critical moments of any interface, they are, quite often, far from all that is required. As we discussed in Chapter 3, when we spoke about different methods of creating learnable interfaces, linear paths and constraining of possible actions can be fantastic tools, but they should be utilized conservatively, and only when genuinely required. For many of the complex, interaction-rich digital products that we presently create, linearity should not be our default stance.

Quite possibly the loftiest goal of this book is to present a solution to this problem that doesn’t brand itself as a whole new acronymized methodology with its own manifesto and a thousand arbitrary deliverables that you have to sell upward to your bosses and clients. I believe that by focusing on creating digital places where interactions can simply happen; by eschewing linearity and pathfinding as unquestioned defaults; by designing moments and by seeing our work in terms of states, transitions, and models, we can start to hone a mindset that allows us to view our current processes and artifacts in a different light. We can create much more open interfaces where self-expression and mastery can occur, where edge-cases melt away, and where personas become a challenge to the status quo, rather than yet another tool of limitation and linearity. In my head, I call this “digital environment design”—but you don’t have to.

Linearity

When it comes to high degrees of linearity in our work, we’ve fortunately got it (mostly) figured out already. Common design practices and processes lend themselves very nicely to planning and creating linear flows and paths. Linearity is often a result of subtraction—an act that many people believe to be the core of design itself. By limiting options and removing an apparent overabundance of choice, we’ve found ourselves remarkably adept at constructing interfaces of singularity—designs that allow for the extremely efficient performance of single-to-a-few actions.

There are a number of downsides and dangers, however, to this approach. To quote Tristan Harris, “If you control the menu, you control the choices.” Our approach to manufacturing linearity in our interfaces is often one of restriction. If an action that our products are quite capable of allowing to occur is not seen as “important” (which often is simply a replacement for “profitable”), then we can just throw it in the bin. Rather than creating alternative, less-invasive ways to allow that action to take place, we’ve formed a habit of ruthless subtraction. This isn’t a negative habit at all—I’d be a hypocrite of the highest order given the points raised in the first part of this book if I were to suggest that removal-by-default is a poor design ethos—but this ruthless removal isn’t always the right tool to throw at a situation.

Harris’s menu metaphor—the notion that our interfaces, at any one time, can resemble a menu of specific options in the form of actions a person can perform—gives us an interesting heuristic for measuring the linearity of our interface at any given moment: linearity is a function of all available options. At any point, we want to be able to look at the options for action that our interface allows, regardless of how obvious they are or how they are performed, and use this number as a proxy for linearity. A small number of possible actions represents a limited menu and thus a high level of linearity. An abundance of options represents a more open, less linear state.

Simply adding or removing potential actions depending on application state, while a good start, is not going to get us far if we want to elegantly manage the linearity of our environment states. Clearly, too, some actions—regardless of state or linearity—will always be more important than others. We’re not about to start sacrificing hierarchy and categorization in some naive pursuit of openness, and it remains critical that we continue to apply our understanding of attention, information overload, and decision overload to our work. As an extremely broad metric, though, option abundance can provide a useful initial insight into how linear our application states may be.

Designing Linearity

Most of what we explored in Chapter 3 can provide us with the tools required to manipulate the linearity of an interface. Concepts like setup wizards, constrained onboarding flows, and streamlined checkout processes all utilize linearity to limit the available options and, really, that’s what most of the linearity of our environments boil down to: how many actions do they allow someone to perform?

In the case of an extremely constrained onboarding flow, such as Google’s Hangouts for iPad onboarding that we looked at in Chapter 3 (shown again in Figure 6-1), linearity is created through strict reduction.

In this flow, we’re constrained to a relative paucity of actions and information. The copy is extremely terse; there’s a single, simple illustration; and we can either click Next, or swipe left or right to navigate between sections, or click Skip to leave the onboarding flow at any time. By limiting options in this way, Google is “controlling the menu.” As we discussed in Chapter 3, onboarding can be an extremely valuable learning tool, but with Google’s example, we see it used almost as a piece of marketing design. We’re essentially being invited to scroll through a feature list one last time before we start using the application.

This has its upsides, for sure. For one, it definitely sets expectations as to what the perceived key features of the application are. It could also act as a sort of primer for the app’s audience, essentially a way of saying “These are the actions you can expect to perform.” However, as we explored, by removing so much context and not allowing concepts to be interacted with in a way that allows for deeper processing of information, its effectiveness as a learning tool—which, really, all good onboarding should be—is limited.

Similarly, look at Amazon or any other shopping site, and you’ll see their checkout processes greatly limit the number of potential options we can perform. During normal shopping, we’re inundated with navigation, categories, related items, sales, and deals. Yet, when it comes time to check out, we’re mostly limited to a few basket-related options, such as changing item quantities, removing items, and completing the checkout process. In fact, for all the talk in this book—and in the industry—about innovative, interactive applications, online stores are one of the best examples we have of linearity being manipulated at various points throughout their usage.

By allowing for exploration and an abundance of (and often far too much) choice, online stores like Amazon provide an open and almost unlimited initial state. At various points, and mainly at the checkout stages, that openness transforms into a constrained, controlled, and limited linear flow. Once the purchase is complete and confirmation is shown, the environment opens up again and more choices—more potential actions—are presented. Shopping apps tend to have a very specific cadence, or rhythm, to their linearity.

A linear flow, then, is one of constraint and rescinded control. At any given point, should we wish for our environments to enter such a state, we need to be sure of a few things. First, that there is indeed enough implicit intent to justify this rescinding of control. Second, that the transitions between any preceding, open states are managed well. We’ll discuss the latter point later on when we start looking at dissecting interactions, but understanding intent is something that can very quickly be assumed, tested, and proven. Essentially, we’re looking to deduce, based on the statement behind previous actions, what someone wants to get from our interface at that moment in time.

For a shopping app, this is quite simple. We’re often presented with a Checkout button either directly on a product page, in our basket view, and usually in both. The clicking of this button communicates very clear intent, essentially stating, “I’m done with my browsing and now I’d like to pay for this stuff.” For other apps, this can be a little more difficult to infer, but for every call to action, link, or button label you have, try to write a succinct, one-sentence summary of the intent behind the interaction. This is also a handy method of finding any vague, ambiguous action items. If you can’t clearly deduce the intent behind a specific action, try to analyze why. Oftentimes it’ll be poorly worded button text, such as Submit or “Go.”, Sometimes it’ll be the elements or copy that surrounds the action point, such as the alert mockup in Figure 6-2.

Alerts like this are unfortunately common and could be prevented rather easily with a simple audit of the copy, assumed intent, and actual action.

Nonlinearity

A less-ventured concept, in digital design at least, is that of nonlinearity. If our understanding of a linear interface state is that of limited options and constrained paths, nonlinearity may take the form of an abundance of potential actions, or a central “hub” of sorts, from which many paths can be explored. Good examples of openness and nonlinearity in interfaces can be found in many products that revolve around creativity and self-expression. Photoshop, which we analyzed in depth in Chapter 3, is a good example. So too is Reaper (Figure 6-3)—a music recording and production application from Cockos.

At first glance, Reaper seems like a textbook example of information overload. There are literally hundreds of potential actions able to be performed from this single state of the interface. To many, this is likely an incoherent mess of non-standard interface elements, yet professional music producers and audio engineers use software like this for hours on end to create, produce, mix, and master a huge percentage of the music we listen to every day.

Reaper, Photoshop and dozens of other apps that we might broadly define as “creativity tools” share a few traits that, were we to apply a reduction-first UX gaze, could convince us they were overbearing, or at least in need of simplification. While there’s no denying that many of these tools could benefit from a solid action audit and some ruthless simplification, part of their nature as creative tools means they’re playing by slightly different rules. What we initially see as complexity and a questionable density of features and information can alternatively be seen as an environment that refuses to be overly constrained or prescriptive in the name of encouraging creativity and self-expression.

Nonlinear applications often require at least some degree of learning and will almost definitely require moments of prolonged focus and deeper levels of processing. The positive side to this lies in how they allow for displays of mastery, autonomy, and self-expression. Many of the concepts explored in Chapter 3 apply directly to our nonlinear application states. We must allow for—and forgive—mistakes, focus on exploration, and teach our difficult concepts well. For nonlinear states in our applications, we lack the nice, sequential snugness of user journeys and simple flow diagrams that often work perfectly for documenting our linear flows . Attempting to document a nonlinear process can actually be a huge pain—user journeys become almost impossible in their traditional format, and flow diagrams become a tangled web of circling back and incomprehensible loops. One of my main goals for this chapter was to present a groundbreaking new method of early-stage documentation that would translate perfectly to open, nonlinear environments. On that point, I completely failed. Nonlinear environments, by their nature, don’t fit nicely into diagrams or documentation. They’re a container for elements and interactions that consistently change based on state and input. As we discussed earlier, they’re much more like the worlds and levels of video games. Without turning this chapter into a deep dive on video game design, a concept that I think directly applies to our work is that of creating an environment that has overarching rules and purposefully arranging objects within it.

In video games, rules are often a mixture of global physics and internal, codified ideas. Much of the feel of a video game lies in its use of the rules of physics, such as gravity and friction. Video game designers can essentially place elements of varying mass into their worlds and have them governed by these global rules. Gravity, for example, might dictate how high and fast a character can jump (Mario’s trademark jump went through numerous iterations, all based around the peak height he reaches and the speed at which he rises and lands), how fast they move, how instantly they stop, and so on. The purpose of these rules in a video game is not necessarily to create a highly realistic world—although, for many games, that might be integral—but to provide an engaging and enjoyable experience.

We can use a similar, albeit to a much less integral degree, approach when designing how our interactive elements behave—are our buttons heavy and stiff, or squidgy and bouncy?—and how they animate—do we have a high-gravity, low-friction environment? Is this one element “heavier” than another? Just like games designers, our environments don’t have to mimic the physical qualities of the real world (we tried that, it didn’t go well), but having a consistent and predictable rule set can make the difference between an environment that feels united and one that feels like a messy interlinking of discrete elements.

Finally, as we explored in Chapter 2, video games designers are experts at subtly communicating information that we codify within these environments. Horizon: Zero Dawn’s use of yellow as a signifier for climbable elements provides the perfect example for this. Don’t underestimate the power of allowing people to discover new ways of executing complex tasks (for example, through keyboard shortcuts or gestures) on their journey to mastery.

A rather interesting example of this is the text editor Vim. Vim (Figure 6-4) is an astoundingly idiosyncratic text editor, mostly famous for no one ever knowing how to exit it.

To the unsuspecting first-time user of Vim, it’s a complete enigma to figure out. There’s no mouse control, highlighting text is a chore, it has “modes” that completely change the function of most keys on the keyboard, and it relies heavily on people learning its own, specific way of operating. On the surface and through the gaze of ruthless simplification, Vim is a decades-old, archaic tool that should be long dead. Yet, thousands of people swear by Vim and its unabashed weirdness. A text editor that has hundreds of tutorial playlists on YouTube should not be loved by so many humans, yet it’s what Vim offers in return for learning its ways that make it so tantalizing to use.

First, Vim is set up to be 100-percent keyboard usable. While there are plug-ins that enable mouse interaction, the “pure” way of using Vim is by keeping your fingers over the keyboard at all times. The speed, so people say, of using the keyboard to navigate and select blocks of text far outweighs the initial time taken to get used to such an idiosyncratic way. Vim’s focus on keyboard control doesn’t end there. The H, J, K, and L keys replace the Left, Down, Up, and Right arrow keys. The argument here is that the “home row” (the middle row of the keyboard) is where most advanced typists want to rest their fingers for the majority of their usage and reaching those centimeters to the arrow keys is far too imposing a task.

The core reason behind Vim’s widespread usage, in spite of its inaccessibility and idiosyncrasies, is that it allows for an extremely efficient writing or coding process for those who have taken the time to learn it. By being hyper-focused on efficiency, to the point where around a centimeter of space is seen as too far to move one’s fingers, Vim has sacrificed simplicity and linearity to focus on an end goal of mastery.

One of the most intriguing aspects of Vim is just how many different ways there are to use it. Although its initial appearance is hardly delectable to the visual palate and it remains a notoriously difficult editor to come to grips with, it actually has many more layers of complexity beyond its basic usage. Through combinations of keystrokes, well-practiced Vim users can select individual words, sentences, lines, and paragraphs in a fraction of the time it would take to use a mouse or trackpad to highlight them. Similarly, one can very easily perform complex tasks such as toggling the capitalization of various words or letters or changing the text inside quotes, parentheses, or brackets in a similarly speedy combination of keystrokes. Watching someone experienced with Vim fly about their text or code at ridiculous speeds is itself a lesson in the untapped power of complexity.

While Vim looks bare and barren, it’s actually an extraordinarily powerful editor and has survived for this long not through consistent innovation, but through simply being the perfect tool of choice for people who really care about the speed at which they can code and write. Compared to Reaper, which is as visually intimidating as it is in concept, Vim relies almost purely on a willingness to learn and embrace its weirdness.

The key thing, I believe, we as designers can take from Vim is that multiple methods of execution, especially of complex tasks, can make an environment feel incredibly enjoyable to work in. I believe this boils down to mastery. While it’s extremely common to hear things like “our audience isn’t experts,” “that’s more of a power user thing,” and “we’re designing for the mainstream,” I believe that perceived mastery, especially in creative applications that are used for hours daily, is a fine goal to work toward.

Trello is another fantastic example of this. While its card-based, drag-and-drop interface (Figure 6-5) is clear, succinct, and intuitive, there’s a great deal of complexity hidden in its keyboard shortcuts.

Hover over, or keyboard focus, a card in Trello and press a key and you’re able to, for example, quickly assign a member to a card (with the M key), change the due date (D), archive it (C), or move it around and between lists (‘,’,‘.’,‘<’, and ‘>’). While Trello is fully usable as a “traditional” point, click, and type web app, watching someone extremely comfortable with its shortcuts and specifics whiz around a complicated board is a genuinely insightful experience.

Vim and Trello offer a different example of nonlinearity—multiple methods of interaction. Both applications have their own learning curve, but they allow us to explore their environments in different ways. By offering multiple paths to the same result, Vim and Trello—in their own ways—create a sense of openness and self-expression that simply doesn’t exist in the constrained, linear flows we discussed previously.

By thinking beyond the obvious visuals and offering multiple paths to the same solution, encouraging exploration and learning, and consistently providing timely feedback, we’re able to create environments that are open enough for self-expression and perceived mastery, but not so opaque or idiosyncratic that they’re too dense to be usable.

Balancing the Two

Balancing linearity ultimately comes down to how much we might limit control at any given point. A limited, constrained path has the advantages of allowing for an explicit showing of progress and a clear indication of intent, and it is relatively simple to document and design around. However, constantly seeing an interface as a sequence of interlinked, extremely linear flows can quickly lead to uninteresting, unmotivating experiences. Conversely, nonlinear interfaces allow for much greater self-expression, allow people to problem-solve within the constraints of the environment, and can play directly into the notion of self-determination and intrinsic motivation. Conversely, nonlinear interfaces require much deeper information processing, take time to master, and can often appear daunting at first glance.

One of the first considerations we should make when starting a design is the level of linearity that makes the most sense for our various application states. Many times, especially for mainstream or single-purpose apps, we’ll be heavily operating on the constrained side of the spectrum, but that decision should be informed by correct research and testing. If we don’t understand our audience, it’s impossible to deduce just how—and when—our interfaces should expand and contract. Once we do have a solid idea of what people expect from our work, we can look into crafting our moments and designing the various states that make them up.