Category Archives: {categories backspace="2" show_group="3"}<a href="/topic/{category_url_title}">{category_name}</a>, {/categories}

Crafting a Design Persona

Posted by The fine folks at A List Apart |02 Jun 15 |

Every product has a personality—whether it was deliberately designed to or not. Reddit is quirky, hyperactive, and sometimes sarcastic. Amazon is like a salesperson with an eidetic memory and amazing talent for statistics. And One Kings Lane evokes a sophisticated, well-dressed interior designer with a carefully curated library of style collages.

But sometimes products have unpredictable, temperamental, or multiple personalities.

At Weather Underground, where I worked until this May, we realized our website was suffering from personality problems while taking an inventory of all our products and pages before undergoing a design overhaul last year. For example, we used far too many exclamation marks when inviting users to join and contribute to our community (“Welcome! Join the Conversation! Start a Weather Blog!”). And we gave users very little indication when there was an error, much less an apology for it. (Our 404 page said simply, “An error has occurred.”) Overall, Weather Underground came across as unpredictable, awkward, and in need of a lesson on social graces.

Weather Underground was the first weather website on the internet, so we wanted our new design to stay true to this history and even strengthen the “weather nerd” aspect of our personality. Yet we also wanted to modernize our visual design and make WU more enticing, welcoming, and friendly. In this moment of designerly tension, we realized Weather Underground’s product personality needed definition, and the best course of action was to articulate a design persona.

Unlike a user persona, which characterizes your users’ goals, motivations, and desires, a design persona characterizes how your product should communicate and ultimately build rapport with your users. Both are articulated in terms of a fictional character, but they are used to solve different design problems. A user persona helps you understand your users’ existing relationship to your product, whereas a design persona helps you understand how your product can build a relationship with your users.

In this article, I’ll show you how we came to think of our product as less of an “it” and more of a “someone” with an engaging, yet consistent, voice. I’ll also show how our design persona has become a continual source of product ideas.

The persona party

One of the most difficult aspects of creating a design persona (and arguably the most important) is to think of your product less like a collection of algorithms and more like a person. To achieve the right mindset, I asked our designers to imagine a fictitious “persona party” attended by all of our user personas, our key content creators, and, of course, our design persona. Here is the prompt I provided:

Imagine that you are WU, the essence of Weather Underground, and you’re at a party. You see [one of our meteorologists] surrounded by a small audience of enthusiasts nodding sagely as he discusses the storm system moving toward Florida. A group of Personal Weather Station owners are hanging out together discussing the record extremes they’ve recorded. In one corner there is [our comedic videographer] drinking something out of a mason jar and cracking jokes about winter storm “Janus.” There is also a gaggle of Wunder Photographers eating all the cheese dip while they ogle and praise each others’ photos. These are your friends and they are all hanging out at YOUR party…

I told the designers that if they found it difficult to imagine Weather Underground as a person, they could imagine how someone similar, like Neil deGrasse Tyson or Bill Nye, would act, and then ask whether WU would act the same or different.

We then used scenarios to brainstorm our design persona’s potential reactions. For example: “Someone wanders up to you and asks, ‘Do you think I’ll need an umbrella today?’ How do you respond?”

  • Yes. It looks like you’ll need an umbrella today, because there is a 40 percent chance of rain after 3 o’clock.
  • Don’t say a word, just point at a graph.
  • It’s going to be sunny and warm outside today, so break out those jogging shoes! (This weather update brought to you by Nike.)
  • You’ll need a bigger umbrella than the one in your cocktail! (Haha!)
  • Get out your phone, we’ve got a great app for that!
  •  

For each reaction, we debated how desirable it was and how true it was to our persona. For example, we realized that WU frequently displays graphs and tables of rich weather data, similar to the example response of “Don’t say a word, just point at a graph.” We decided that it would be much more approachable, friendly, and desirable to provide concise explanations of weather forecasts in addition to the detailed graphs and tables. However, several designers were quick to point out that WU shouldn’t be too friendly—for example, it would be off-putting and distracting to tell a joke when users are looking for the forecast.

After going through a number of similar activities and debates, we noticed themes in WU’s personality that shaped our subsequent discussions. We decide that WU should:

  • Answer questions directly, but always back it up with rich data.
  • Speak in a colloquial and friendly tone, but never oversimplify explanations.
  • Occasionally use humor in a conversation, but never in discussing current or serious weather.

These observations guided our definition of WU’s brand traits. Ultimately, we decided that WU is:

  • an advocate, but not an evangelist
  • intelligent, but not condescending
  • technical, but not unapproachable
  • playful, but not distracting

We articulated our brand traits in a “this-not-that” format, similar to how Kate Kiefer Lee and Aarron Walter described their brand traits at MailChimp, because it allowed us to qualify them against brand enemies.

These traits now act as design constraints for all projects, making consistent designs much easier to develop. They also provide heuristics for design reviews, allowing us to critique designs in terms of concrete, established goals.

Responses in context

While the brand traits highlight some of WU’s more admirable qualities, they do not identify WU’s approach to specific scenarios. Or, as Kate Kiefer Lee might put it, articulating our brand traits helped define WU’s voice, but now it was time to figure out WU’s tone.

As the next step in our activity, we decided to create a personality map. Aarron Walter uses this tool in Designing for Emotion as a way to describe a personality on an x-y axis. On one axis, you have the degree to which the person is submissive or dominant in their interactions. You can think of a dominant person as one who takes charge and presents themselves as an authority, whereas a submissive person would rather follow someone else’s lead. On the other axis, you have the degree to which the person is affiliative or unaffiliative—interested in building a connection, or interested in maintaining distance. Aarron Walter uses the terms “friendly” and “unfriendly” here, but I think “unfriendly” conveys active meanness or abrasiveness, while “unaffiliative” simply conveys emotional or professional distance. For example, your doctor may act friendly toward you, but also make it clear with their behavior and demeanor that it would be inappropriate to ask them out for coffee later.

A four-quadrant personality map, with different areas marked for WU’s personality in different moments.
The WU personality map.
     

When I asked everyone to pick the one place on the personality map that best represented WU, everyone picked distinctly different spots. And for each selection, there was a supporting story and context:

  • WU should be dominant while discussing the weather, because that is WU’s expertise.
  • WU should be submissive when apologizing for a server outage.
  • WU should be affiliative when discussing interesting weather events that have happened in the past, because we want our users to join the conversation.
  • WU should act affiliative and moderately dominant when introducing educational content, because we want to come off as a nerdy, friendly professor.

We realized that people (and design personas) behave differently, and may assume a different identity, depending on who they are talking to and the context of the conversation. For example, your doctor may be dominant and unaffiliative while discussing medical treatments with you, but will become submissive and affiliative while discussing Thanksgiving dinner plans with their grandmother. We are never just one spot on a personality map; our design persona should act differently depending on the context, too.

We decided that rather than picking a single spot on the personality map, we would draw out multiple points and context zones. For example, you can see that during “Severe Weather,” we want WU to sound and act like an authority. However, when we have a system failure and end up in the “Apology Zone,” we want to be conciliatory and apologetic.

Debate the minutia

The personality map was only the beginning of our many debates.

For the next phase, I asked everyone to think of responses WU would give in specific website scenarios, such as welcoming a new user, telling a user their action was successful, and informing the that user an error had occurred. Each team member contributed a possible response, and we discussed how well each matched the brand traits we had defined and what we knew about our persona so far.

These conversations led to a number of debates: should we ever address a user by name? (Verdict: Yes, but sparingly.) When, if ever, is it appropriate to use humor? (Occasionally, but we are always serious about the weather.) When and how should we apologize to users? (Always for technical errors, but not for incorrect forecasts.)

Each debate added to our growing library of response examples and taught us more about the nuances of our personality. And while these debates seemed, at times, tedious and narrow, we were actually working through problems in product consistency that we had previously overlooked. We were learning that to have a consistent product personality, we needed to know how WU should present itself across product, design, content, copy, and branding.

Let your light shine

Now that we had a product personality that we thought would resonate with our user base, we needed to find ways to let that personality shine. For our final design activity, we decided to brainstorm ways to create opportunities.

We started with a simple framework based off of Aarron Walter’s description of design personas in Designing for Emotion. We focused on:

  1. Creating interactions that inspire surprise and delight.
  2. Giving users a sense of anticipation.
  3. Rewarding users for their continued patronage.

We generated no fewer than 35 unique ideas to delight or reward our users, from Easter eggs on Groundhog Day to redesigned 404 pages. One of the simplest, yet most powerful, ideas was enabling our users to thank their local Personal Weather Station owners for their weather data. The implementation details of this functionality are trivial: button click → thank-you message sent. But it has tremendous product engagement potential, because it simultaneously lets users know that their weather data comes from a real human who has generously added their data to the WU community, and thanks those owners for their contributions. The team is currently working on the final details of the PWS thank-you feature and hopes to release it in conjunction with a “PWS Owner Appreciation Day” marketing effort.

Another idea that emerged was WunderPosters: artistic posters depicting interesting and beautiful natural phenomena created by one of our in-house designers. We released WunderPosters during Weather Underground’s twentieth anniversary, coupled with a contest where fans could submit ideas and vote on which weather conditions they would like to see turned into a poster. The project spanned departments (design, engineering, and marketing), and has engaged our users over multiple channels. It also speaks directly to the “weather enthusiast” aspect of our design persona.

Ideas like these confirmed for us that a design persona is not just about keeping your copy and voice consistent—it also provides a source of design inspiration.

Start your personality adjustment

Disjointed product personalities can emerge in the best of websites when small, non-technical details are repeatedly neglected over time. But solving your product’s personality problems is as important as solving the technical ones.

To start your own personality adjustment, gather a small group of people from throughout your company (including marketing, design, engineering, and product management) and take an inventory of existing copy, iconography, and content. Identify the points in which the tone of your product seems overly dramatic, familiar, brusque, formal, or odd. These will be the initial personality trouble points you solve after defining your design persona.

As you go through activities like the ones I’ve outlined throughout this article, try using this worksheet I created to get everyone thinking about your design persona individually before discussing it as a group.

Photo of a poster explaining Weather Underground's brand traits for internal staff.
WU Brand Traits poster, hung on the back of a bathroom stall.

Finally, make sure you record and summarize the insights, decisions, and examples you generate. At Weather Underground, we created a WU cartoon figure to represent our design persona and featured him with our other mascots on a series of posters. We then hung those posters in places where our coworkers were sure to see them—such as the back of bathroom stalls.

Crafting a design persona is an intense exercise that requires the the time and involvement of team members throughout your company. While the work may seem daunting, it is well worth it. By investing in your product’s design persona, you are investing in future advocates of your product—and creating a source of design inspiration for your team.

Approaching Content Strategy for Personalized Websites

Posted by The fine folks at A List Apart |19 May 15 |

There’s a curious concept in astrophysics known as the Drake Equation. Developed to quantify the potential for intelligent life in our galaxy, it raises a number of odd questions, among them: does having intelligence, in the long run, actually benefit or harm a species? In other words, will amoebas ultimately outlive humans in the face of eternity?

If you’re like me, these are the types of things you think about while listening to hold music before conference calls. But as a content strategist, I can’t help but ask the same question about something my clients suddenly seem to be clamoring for: personalized user content.

It sounds great in theory: content that is more targeted to the user can provide a richer, more precise experience. But there is also a dark side: used improperly, targeting risks invading privacy and eroding trust. As Drake supposes, true intelligent life is rare, in part because it has the potential to destroy itself.

So how might you dip into this intelligence without wrecking your content in the process? How can we approach personalized content in a way that is sustainable and respectful, not self-destructive?

Personalization basics

For good or for evil

At a basic level, personalization (aka targeting) means serving unique content to a user based on something we know about him or her—from geographic location to specific browsing history. And as you’ve likely observed, the value of personalization is largely in how you wield it. It’s helpful to us when Amazon makes recommendations based on our past viewing history. Conversely, we’ve all been bothered at some point by a creepy targeted ad—the one that either somehow knows too much about you, or is trying to sell something you don’t want.

Historically, the average UX person hasn’t played much of a role in either of these scenarios, the latter being controlled by online marketers, the former monopolized by the Amazons of the world. But the recent advent of so-called “experience management systems”—like Adobe Experience Manager, Sitecore Experience Platform, and Episerver Personalization Manager—has (somewhat precipitously) made the ability to personalize content more accessible to clients. You don’t have to look much further than the goodie bag from the last conference you attended to see that all of the big name CMSes are now aggressively marketing their own flavor of personalization software.

Do you even need it?

So what do you do when your client says they want to personalize content? The good news is that the foundation of personalized content strategy is the same set of tools you know and love: a core strategy statement, a set of guiding principles, and a basic content model. You now must consider how (or if) targeting can advance these directives. For example:

Good reasons to target site content:

  1. Your audience can be segmented in ways that are meaningful.
  2. Narrowing your message provides incremental value to your users.
  3. Personalized content is tied to specific KPIs or business objectives.

Bad reasons to target site content:

  1. Because we can.
  2. Some variation of #1.

You may face some strong headwinds if your client just bought a shiny new EMS and can’t wait to start solving world hunger. Again, as is always the case with the technology du jour, the product demos for these things are very seductive and typically involve light shows and kittens and free ecstasy. You may have to be the voice of reason. But that’s why you went to content strategy school, right?

Partial steam ahead!

Next, consider your targeting technology. As a general rule, the systems that support targeted content will be one of two things:

  1. Rules-based: The more manual approach, this involves setting up discrete audience segments in the system and writing rules for when and how to show them content. Example: It looks like Colin’s IP address is from Washington, DC, so let’s show him what we show everyone in that location.
  2. Algorithm-based: The “secret sauce” approach, this focuses less on the overall segment and more on a specific user’s behavior. Example: Colin clicks on 3.65 articles/day about soup, so let’s show him a campaign for soup.

For our purposes, we’ll take a closer look at a rules-based model, since this is more likely what you’ll be running into if your client is just starting out with personalization. You’ll first need to determine your “segments.” Similar to UX personas, segments are groups of users with some distinguishing set of traits like age, interest, or location. The difference here is that a targeted segment will be determined by real-time data, either internal or external to your site. Typically this data will be fed through some type of centralized rules engine accessed by your CMS.

Applying a personalized content framework

This is all getting a bit abstract, so let’s imagine for a moment that we’re creating a new site for An Airline Apart (obviously the next logical brand extension). We want to target busy creative professionals who travel regularly for work. What online content should we create to give us an edge with this audience?

Our first bright idea is to start a content campaign that takes the stress out of business travel. Easy enough, right? But that actually makes a lot of assumptions—what does “stressful” even mean? Can we break it down by audience?

Defining segments

A recent study from Carlson Wagonlit Travel asked 7,400 global business people who travel regularly for work to rank how stressful business travel is to them at each stage of their trip. Here’s what they found, sorted by gender:


A chart showing how men and women feel stress at different times during travel.

Source: Harvard Business Review. Data from HEC, Carlson Wagonlit.

There are clear differences: women tend to find the pre-trip phase the most stressful, while for men this is the least stressful phase. And for some reason, at the post-trip phase, it’s the complete opposite.

It gets even more interesting. Here’s what happened when they sorted the data by role:


A chart showing how people in different roles feel stress at different times during travel.

Source: Harvard Business Review. Data from HEC, Carlson Wagonlit.

According to this, business travel stress changes wildly depending on company role. For example, high-level employees are least stressed before the trip, and more stressed after; for support staff, it’s the total opposite.

Now, if we were doing this properly, we would absolutely want to drive into the “why” behind this. But for the sake of our sample exercise, we have more than enough justification to pursue a segmented content approach to our campaign. We could potentially set up 12 segments across gender and role in our system; here, though, let’s limit our focus to senior execs, male and female.

Mapping segments to content

From a technical point of view, personalizing content comes down to running targeted rules on individual components on a page. So let’s say we have our An Airline Apart homepage with typical content zones. If we didn’t know who you were, we would show our usual default content:


A wireframe showing content blocks for a website called An Airline Apart.

Art Credit: Kristina Bourlotos

Now in theory, we could write rules to target content for all of these blocks for our users. But how do we know where to begin? This is the “substance” question in content strategy, and where we need to consider very specifically what value we are adding.

To help us think through this, our team at ICF Interactive developed a framework for the four core types of personalized content. The first two have to do with the “task at hand,” or what the user came to your site to do today. The second two have to do with the “big picture,” or what you’re trying to get people to see and feel as part of your larger brand experience. Here’s how it breaks down:


A chart showing four types of content as a framework for personalization.

Source: ICF Interactive

  1. Content that alerts. This type of targeting improves the customer experience by displaying relevant, time-sensitive information, such as a weather delay, service disruption, or other real-time issue.
  2. Content that makes tasks easier. The second “task at hand” category, this type makes users’ lives easier by helping them do what they came here to do—e.g., “smart” navigation, deep links to useful tools, or automatically deprioritizing unrelated content.
  3. Content that cross-sells. This type may make your inner designer squirm, but it will realistically be one of your most important use-cases (and likely the one most directly tied to project ROI). Whether you’re a global oil conglomerate or a non-profit that provides hugs to reindeer, this is your place to market whatever it is you need to market. Again, the trick here is to show users something relevant, not just what you want them to see. Examples: ad for a new product, announcement for your upcoming conference, call to join or donate, etc.
  4. Content that enriches. A close cousin to the cross-sell, content that enriches a user’s experience is supplemental to their overall brand perception. This might include blogs, articles, community features, social networks, or third-party content. Think of this as the “soft sell” versus the “hard sell.” On a standard task-oriented page, this content will typically occupy the least critical zone.

Going back to our example, here’s how we could apply this approach to the personalized content we want to show on the An Airline Apart homepage:

Type of personalized content What to show senior execs
Alert A list of flight cancellations impacting this user in real time
Make easier Some shortcuts to content for our Priority Flyers service
Cross-sell An ad for our new business class upgrade
Enrich Tips on pre-trip (female segment)
Tips on post-trip (male segment)

Remember our bland default page? With our rules up and running, a senior exec will instead see this (color-coded by type):


A wireframe showing how content changes depending on the viewing audience.

Art Credit: Kristina Bourlotos

Notice we’re now showing content specific to our executives, with the added nuance that the bottom right zone (“enrich content”) differs for our female versus male audience, based on that research nugget around stressful travel.

Bear in mind that these two are looking at the same site at the same time from two different locations—the CMS is targeting the content based on what we know about them, so they effectively get a different experience (and if everything is set up correctly, a better one).

Content on crack

You’re starting to see the implications, right? If we were to follow this through, instead of writing one content strategy, we now effectively need to write 12—one for each audience segment we had identified. As a content strategist, you’ve probably swallowed your content gum. The technology is there to help you accelerate that process to some extent, but this is precisely why taking a disciplined approach to personalized content is critical. Otherwise, you will be quickly overwhelmed, not only in terms of creation and execution, but also maintenance and support.

Taking the first step

What’s that you say? You’re not intimidated? Great! Just a few things to keep in mind.

Have the right resources

Remember that putting personalized content in the field requires not only a sound strategy, but also the resources to support it. You may still need some work if:

  • You don’t have enough content to make targeting useful
  • You don’t have enough staff to maintain targeted content
  • Your content is not semantically rich—you need a taxonomy, metadata, etc.
  • You don’t have a CMS that supports it
  • You don’t have analytics and tracking in place to gain insights and adjust

Be respectful

There’s a whole other conversation to be had around the ethics of targeting, but suffice it to say there is a line between providing helpful personalization and invading privacy. If you find yourself trying to force content on people with your newfound power, stop. Think of Ida Aalen’s core model. Is your content truly at the intersection of user and business goals, or just business goals? Approaching targeted content strategy with respect for your users will ensure that your site lands on the right side of web personalization history.

To infinity

Sound like a lot? Consider that it doesn’t have to be that complex. In fact, can you guess the number one method of personalized content in use today? That’s right, email. So chances are you’re probably already doing targeting on some level, and have an organizational starting point from which to build. With the right strategy and technology, you’re really only limited by your imagination, and your ability to adapt to mistakes along the way.

And who knows? You may discover that the web can, in fact, support intelligent life.

Meta-Moments: Thoughtfulness by Design

Posted by The fine folks at A List Apart |19 May 15 |

Ever had a moment on the internet when you’ve been forced to stop and think about what you’re doing? Maybe you’ve been surprised. Maybe you’ve stumbled across something new. Maybe you’ve come to see things in a different light. I call such experiences meta-moments: tiny moments of reflection that prompt us to think consciously about what we’re experiencing.

Take Google. In the early days, its clean white page helped distinguish it from the pack. While its competitors tripped all over themselves telling you how great they were and how much they had to offer, Google’s quieter strategy seemed bold and distinctive. “Our search experience speaks for itself,” it suggested. No need for spin or a hard sell. Over the years, as Google has continued to develop its search technologies, it has managed to retain that deceptive surface simplicity. I love that its minimal homepage has stayed intact (in spite of incessant doodling). Encouraging a thoughtful moment remains central to Google’s design.

Yet the prevailing wisdom within user experience design (UXD) seems to focus on removing the need for thought. We are so eager for our users to succeed that we try to make everything slick and seamless—to remove even a hint of the possibility of failure. Every new service learns about our movements in order to anticipate our next move. Each new product exists in an ecosystem of services so that even significant actions, such as making a purchase, are made to seem frictionless. The aim is not only to save us time and effort, but to save us from thinking, too.

Steve Krug’s seminal book Don’t Make Me Think! may have helped to shape this approach. This bible of usability is an undisputed cornerstone of UXD. But it can be taken too far. In fact, Krug himself has unofficially rechristened the book Don’t Make Me Think Needlessly! In doing so, he acknowledges that there are times when thoughtful interactions online are worth encouraging. While we shouldn’t need to think about where to find the search tool on a site (top right, please!), we should, of course, be encouraged to think before we purchase something—or, for that matter, before we make any significant commitment.

It’s a question of courtesy, too. When asking for deeper attention, we should feel confident that we’re not wasting people’s time. What we offer should more than repay them for their efforts—though there aren’t many moments when we can guarantee this.

I’m currently working on a project—an online version of a medical self-screening form—that has a valid reason for making users think. Success will involve making sure that users really understand the meaning of each question, and that they take the form seriously—that they take the time to answer honestly and accurately. My teammates and I find ourselves designing a slow experience rather than a fast one.

But what slows people down and makes them more thoughtful? And what is it about a particular design that makes people really invest their attention?

Laying the groundwork for thoughtfulness

In my experience, there seem to be three main strategies for encouraging meta-moments.

Roadblocks

Inbox by Gmail makes you think by confronting you with a barrier. You can’t just try the service. You have to be invited. You can request an invitation (by following the instructions on their site), or a friend can invite you—but you can’t get started right away. Anticipation and excitement about the service has space to gather and develop. And it does. In its first few weeks, invites were going on eBay for $200.

This strategy certainly worked on me. Within moments of landing on the page, I went from being slightly intrigued to a state of I-must-have-it. Following the instructions, I found myself composing an email to inbox@google.com requesting an invitation. “Please invite me. Many thanks, Andrew,” I wrote, knowing full well that no one but me was ever going to read those words. Why hadn’t they simply let me submit my email address somewhere? Why were they deliberately making things hard for me?

Something clever is going on here. Adding a barrier forces us to engage in a deeper, more attentive way: we are encouraged to think. Granted, not everyone will want or need this encouragement, but if a barrier can create a digital experience that is noticed and remembered, then it’s worth talking about.

Putting up a “roadblock,” though, seems like a risky way to encourage a meta-moment. Stopping people in their tracks may make them simply turn around or try another road. For the roadblock to be effective (and not just annoying), there has to be enough interest to want to continue in spite of the obstacle. When I encounter a paywall, for example, I need to be clear on the benefits of parting with my money—and the decision to pay or subscribe shouldn’t be a no-brainer, especially if you’re hoping for my long-term commitment. iTunes’s micropayments, Amazon’s “Buy now with 1-Click,” and eBay’s impulse bidding all represent a trend toward disengaging with our purchases. And in my own purchasing patterns, things bought this way tend not to mean as much.

Smartphone apps have a similar impact on me. Most of the time, it seems that their only aim is to provide me with enough fleeting interest to make me part with a tiny upfront cost. As a result, I tend to download apps and throw them away soon afterward. Is it wrong to hope for a less disposable experience?

In-app purchases employ a kind of roadblock strategy. You’re usually allowed to explore the app for free within certain limitations. Your interest grows, or it doesn’t. You decide to pay, or you don’t. The point is that space is provided for you to really consider the value of paying. So you give it some proper thought, and the app has to do far more to demonstrate that it deserves your money. FiftyThree’s Paper, my favorite iPad app, lets you have a blast for free and includes some lovely in-app promotional videos to show you exactly why you should pay.

Roadblocks come in many shapes and sizes, but they always enforce a conscious consideration of how best to proceed. Navigating around them gives us something to accomplish, and a story to tell. This is great for longer-term engagement—and it’s why digital craftspeople need to shift their thinking away from removing barriers and instead toward designing them.

Speed bumps

Speed bumps are less dramatic than roadblocks, but they still encourage thought. They aim to slow you down just enough so that you can pay attention to the bits you need to pay attention to. Let’s say you’re about to make an important decision—maybe of a legal, medical, financial, or personal nature. You shouldn’t proceed too quickly and risk misunderstanding what you’re getting yourself into.

A change in layout, content, or style is often all that is required to make users slow down. You can’t be too subtle about this, though. People have grown used to filtering out huge amounts of noise on the internet; they can become blind to anything they view as a possible distraction.

Online, speed bumps can help prepare us mentally before we start something. You might be about to renew your vehicle tax, for instance, and you see a message that says: “Hold up! Make sure you have your 16-digit reference number…” You know that this is useful information, that it’ll save you time to prepare properly, but you might find yourself getting a little frustrated by the need to slow down.

Although most of us find speed bumps irritating, we grudgingly accept that they are there to help us avoid the possibility of more painful consequences. For example, when you fire up an application for the first time, you may see some onboarding tooltips flash up. Part of you hates this—you just want to get going, to play—and yet the product seems to choose this moment to have a little conversation with you so that it can point out one or two essentials. It feels a little unnatural, like your flow has been broken. You’ve been given a meta-moment before being let loose.

Of course, onboarding experiences can be designed in delightful ways that minimize the annoyance of the interruption of our desired flow. Ultimately, if they save us time in the long run, they prove their worth. We are grateful, as long as we don’t feel nagged.

In spite of the importance of speed bumps online, we tend not to come across them very often. We are urged to carry on at speed, even when we should be paying attention. When we’re presented with Terms and Conditions to agree to, we almost never get a speed bump. It’d be wonderful to have an opportunity to digest a clear and simple summary of what we’re signing up for. Instead, we’re faced with reams of legalese, set in unreadable type. Our reaction, understandably, is to close our eyes and accelerate.

Diversions

Online diversions deliberately move us away from conventional paths. Like speed bumps, they make us slow down and take notice. We drive more thoughtfully on unfamiliar roads; sometimes we even welcome the opportunity to understand the space between A and B in a new way. This time, we are quietly prodded into a meta-moment by being shown a new way forward.

A diversion doesn’t have to be pronounced to make you think. The hugely successful UK drinks company Innocent uses microcopy to make an impact. You find yourself reading every single bit of their packaging because there are jokes hidden everywhere. You usually expect ingredients or serving instructions to be boring and functional. But Innocent uses these little spaces as a stage for quirky, silly fun. You end up considering the team behind the product, as well as the product itself, in a new light.

Companies like Apple aim for more than a temporary diversion. They create entirely new experience motorways. With Apple Watch, we’re seeing the introduction of a whole new lexicon. New concepts such as “Digital Touch,” “Heartbeat,” “Sketch,” “Digital Crown,” “Force Touch,” “Short Look,” and “Glances” are deployed to shape our understanding of exactly what this new thing will do. Over the course of the next few years, you can expect at least some of these terms to pass into everyday language. By that time, they will no longer feel like diversions. For now, though, such words have the power to make us pause, anticipate, and imagine what life will be like with these new powers.

The magic of meta-moments

Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

A user journey without friction is a bit like a story without intrigue—boring! In fact, a recent study into the first hour of computer game experiences concludes that intrigue might be more important than enjoyment for fostering engagement. We need something a little challenging or complex; we need to be the one who gains mastery and control. We want to triumph in the end.

Our design practices don’t encourage this, though. We distract our users more than we intrigue them. We provide the constant possibility of better options elsewhere, so that users never have to think: “Okay, what next?” Our attention is always directed outward, not inward. And it—not the technology itself, but how we design our interactions with it—makes us dumb.

UXD strives toward frictionless flow: removing impediments to immediate action and looking to increase conversions at all costs. This approach delivers some great results, but it doesn’t always consider the wider story of how we can design and build things that sustain a lasting relationship. With all the focus on usability and conversions, we can forget to ask ourselves whether our online experiences are also enriching and fulfilling.

Designing just one or two meta-moments in our digital experiences could help fix this. Each would be a little place for our users to stop or slow down, giving them space to think for themselves. There’s no point pretending that this will be easy. After many years dedicated to encouraging flow, it will feel strange to set out to disrupt users. We’d be playing with user expectations instead of aiming to meet and exceed them. We’d be finding little ways to surprise people, rather than trying to make them feel at ease at all times. We might tell them they need to come back later, rather than bend over backwards to satisfy them right away. We might delegate more responsibility to them rather than try to do everything for them. We might deliberately design failures rather than seek to eradicate them.

How will we test that we’ve achieved the desired effect and not just exasperated our users? Usability testing probably won’t cut it, because it’ll be tricky to get beyond the immediate responses to each set task. We might need longer-term methods, like diary studies, in order to capture how our meta-moments are working. Our UXD methods may need to shift: from looking at atoms of experience (pages, interactions, or tasks), to looking at systems of experience (learning, becoming, or adopting).

It will be a challenge to get people behind the idea of adding meta-moments, and a challenge to test them. The next time we create a design solution, let’s add just one small barrier, bump, or quirk. Let’s consider that the best approach may be a slow one. And let’s remember that removing needless thought should never end up removing all need for thought. Putting thought into things is only part of a designer’s responsibility; we also have to create space for users to put their own thought in. Their personalities and imaginations need that space to live and breathe. We need to encourage meta-moments carefully and then defend them. Because they are where magic happens.

Do Androids Dream in Free Verse?

Posted by The fine folks at A List Apart |05 May 15 |

From ATMs to Siri to the button text in an application user interface, we “talk” to our tech—and our tech talks back. Often this exchange is purely transactional: we input commands; the machine complies. Newer predictive technologies like personal assistant apps have renegotiated this relationship, preferring to relate to us as peers, even friends. Scarlett Johansson’s flirtatious operating system in Her brought this idea to a lifelike apex, simulating love, even orgasm—all digitally mediated.

As technology becomes more pervasive and gains access to greater amounts of our personal data, how can we design successful human-machine conversations? Should user interface text approximate the lilt, flow, and syntax of human speech? Or does humanizing UI conversations create a false intimacy that distances even as it attempts to foster familiarity?

The answer, of course, is that it depends. Most of us have encountered voice-automated customer service systems. Some of them, in an effort to make their robot customer reps less droid-like, feature voices that try to approximate human diction. A calm, often female voice pauses, suggests brightly, bridges her prompts with almost-ums. Her attempts at realness further underscore the fact that she is fake, blocking you from an actual human encounter.

A computer that cheerfully calls you by your first name can either delight you or creep you out, depending on the circumstances. Just as robots enter the uncanny valley when they seem too human, a user interface that’s too familiar can push people away. The copy needs to strike the right balance.

Consistency within diversity

Until recently, I was a UX writer and content strategist at Google. Specifically, I worked on Google Apps: Gmail, Docs, Drive—all of the productivity tools that help people work and communicate. Writing for a large, entrenched company poses particular challenges because the sheer array of products and experiences offered can make it difficult to achieve consistency in tone and style.

Our audience included people who use Google tools at work. People at work are obviously a very different market from, say, a teenager absentmindedly browsing a consumer app like YouTube for video clips (though that isn’t to say that YouTube browsing doesn’t happen under the guise of work). But work tools should be as intuitive and (dare I say) delightful as the best consumer apps. They should help you be more productive and creative. You shouldn’t have to spend brain power figuring out how to deploy them.

Consider, too, the many modes of work. Some people are desk-bound, whereas others are constantly mobile. Some companies have huge IT departments that can provide support; at others, workers have to learn to use products on their own, often without much technical background. This can be overwhelming. Most workers want to spend time getting stuff done, not learning to use Google Apps. So the experience, and thus the text, must serve the overall usability and ease of the product.

There are ground rules that can guide the writing for all of these interfaces, though they exist in very different contexts and geographies. The YouTube-browsing teen can be in Osaka or Indianapolis. Modifying Chrome settings should be easy and seamless, whether in Farsi, Tagalog, or Italian.

While we can strive for an overarching level of consistency defined by some core principles—be friendly, be helpful, don’t use jargon or technical language—each product carries slightly different conventions, expectations, and contexts. Yet they all have to be reconciled within a domain that is recognizably Google, in over 50 languages. Keeping text brief and scannable, and including only the most essential words, will smooth a user’s journey.

“OK Google, search for Thai restaurants.”

One particular UI conversation that Google may continue to fine-tune is how it initiates a voice search on a smartphone. “OK Google” is the voice prompt Google suggests for striking up interactions on mobile devices. This phrasing suggests that our relationship with both our phone and Google is informal and familiar, even chatty.

If you ever actually “OK Google” your smartphone or wearable device, though, you’ll probably find that doing so feels forced and cheesy at best. I’d personally rather just say “Call Trevor” or “Find nearby Thai restaurants” and stick to semantic, if utilitarian, commands.

“OK Google” is awkward because it insists that we’re chums with the search behemoth. Google is less a company in this recasting than a helpful friend. Yet this same Google also upholds “Focus on the user” as one of its founding pillars. “User” implies both a certain ascetic distance and an unpleasantly parasitic relationship. How can I simultaneously be buddies with and just a “user” to the same company?

Language reveals social landscapes and highlights power struggles, and can shed light on intimacy or distance. When writing for an interface, the smallest words reveal relationship dynamics and cue motivations, even emotions. The microtext on, say, a button can alter the tenor of the interface conversation. Whether you label a button “Got it” or “Continue” signals more than just information conveyance. “Got it” connotes a certain confidence and informality, and assumes agency on behalf of users. “Got it” asks them to own their comprehension and acceptance of whatever information is presented before moving along, rather than merely assenting to “Continue.”

Another common copy example: “enable” versus “turn on.” “Enable” feels unnecessarily technical and implies a subtle hierarchy between the enabler and enabled. The softer “turn on,” by contrast, could indicate the flow of water from a faucet, or—depending on where the mind goes—a sexy precursor to further action. When aiming for “friendly,” where is the line between cloying and mechanical?

Brevity with soul

Being conscious of words doesn’t mean that one needs to make UI language purely functional. Balancing well-placed, clever copy with short, concise text can add delight and magic to an experience. Note Chrome’s “Aw, snap” for a page-load error, or the sly personality that suffuses the airfare purchase flow on Virgin America’s site:


Screenshot of Virgin America’s homepage.

Virgin’s brand voice is flirtatious, fun, and irreverent. Their approach resurrects an earlier age when air travel promised a thrilling luxury rather than a cramped seat, broken pretzels, and the purgatory of airport security. They don’t take themselves too seriously and their approach injects brassy humor into a task as lackluster as flight booking.


Screenshot of a modal dialog from the Virgin America site.

That tone comes through in small ways, such as this playful modal dialog about additional upgrade charges. The button is labeled not with the expected “Okay,” but with “I understand, let’s do this.”


Screenshot from the Virgin America site showing the UI text—‘Hey there’—that pops up after a user enters their first name.

When a user enters her name while booking a flight, the form field greets her with a sly bit of text: “Hey there.” Subtle winks like this can humanize an interface without being intrusive, yet aren’t so colloquial that they’re alienating.

Text should inform readers and help them along—and then it should get out of the way. A well-written UI recedes into the background, imbuing—but never overpowering—the user experience. There’s poetry in writing for the web, but it isn’t the luxuriant run-ons of Whitman. Rather, it’s the economy of poet Masaoka Shiki’s haiku—so spare it’s almost missed.

Friendly but functional

The popularity of “digital detoxes” hints at a growing frustration with our reliance on tech interactions. The future may well contain more unobtrusive and silently helpful technologies, rather than intimate human-machine relationships à la Her.

As such, UX writers and designers might consider how we can keep conversations friendly but functional. We can provide signposts without the baggage of a relationship. Sue Factor, a former colleague and Google’s first dedicated UX writer, taught me that short text is often the best text. Although I earn a living writing for the web, I don’t flatter myself that anyone opens an app to carefully read and savor my language. We’ve all got better things to do. As Shiki writes:

My life —
How much more of it remains?
The night is brief.

Building Nonlinear Narratives for the Web

Posted by The fine folks at A List Apart |05 May 15 |

The Tiv people of Nigeria tell a story about the early world, when things were different. It’s about Aondo, the Sky, and how he lost his relationship with humans. When the earth was still new, Aondo was close enough that people could stretch out their hands and touch him. For many years, he and the humans led a quiet existence, and everyone went about their business.

One day, though, everything changed. Aondo sat in his place above the earth, watching people come and go. And then: out walked the most beautiful woman he had ever seen. Aondo was fascinated by her, so he crept closer—too close—to watch her cook. As she was cooking, all of a sudden, she accidentally struck him in the nose.

Aondo was hurt and embarrassed, so he retreated. Farther and farther, until he was far above the earth. That is why, the Tiv people say, you cannot touch the sky.

Screenshot of Senongo Akpem’s Pixel Fable site, which is a collection of interactive African children’s stories.
Pixel Fable is a collection of interactive African children’s stories.

I’m Tiv, and I grew up with fables like this. In 2011, I started Pixel Fable as a way to tell these Nigerian stories digitally. That story about Aondo, “Why the Sky Is Far Away,” was the first one I designed and built. I used augmented reality to make the animations feel more interactive (along with some wonderfully spaghetti parallax JavaScript). But the story was still a single HTML page, told from one perspective, along a linear timeline. My translation from oral tale to web page was too direct—I hadn’t captured the multifaceted ways a story could exist online.

For instance, I could’ve built two versions, based on the same HTML, split into the woman’s point of view and Aondo’s. The competing narratives would frame readers as detectives, exploring and contrasting details to figure out the whole tale. Or, I could’ve incorporated data visualizations to reflect Aondo’s mood: by combining weather data like thunderstorms and temperature with a “Sky Mood Indicator,” I could’ve designed Aondo’s emotional state as a separate, visual facet.

Either route offers a way to twist or fragment the story, to add layers to the central narrative—to transform the original Tiv tale into a nonlinear, more nuanced, and linked experience, much closer to how the web itself works.

I want to do that for Pixel Fable, and I want to show you how to do it, too. That means venturing beyond our basic scrolly-telling. But first, let’s take a deeper look at what nonlinear stories do.

The role of nonlinear narratives on the web

The web operates in ways that can conflict with our traditional view of what a “story”—with a set start, middle, and end—is. Content is chunked, spread across various channels, devices, and formats. How do we define story lines, characters, interactions, and the role of the audience, given this information sprawl?

Cue nonlinear narratives. They’re collections of related content, organized around a story. They comprise video, text, links, audio, maps, images, and charts. Their chunked, compartmentalized nature gives them incredible flexibility, and makes them the perfect vehicle for how we explore online, jumping from one piece of information to the next.

Even though they don’t necessarily follow classic story structure, they still have many of the same parts: heroes, villains, locations, plots. It’s how these are developed and connected that may seem unexpected. One of nonlinear narratives’ superpowers is how they let you build on and refine them over time. For example, Vox’s cards and story streams help us aggregate information on complex news stories by posting relevant bits as they develop—whether it’s a Q&A on the human exploration of Mars that provides context in bite-sized form, or a stream of more info on a disease outbreak. These updates over time allow designers and creators to react to audience feedback.

Nonlinear narratives also offer audiences more agency. People want to learn, be surprised or intrigued, or entertained—and nonlinear stories prompt participation. Their fragmented structure needs an audience; without readers or viewers, the narrative cannot be experienced as a meaningful whole. In turn, this forces us to design stories that work with, not against, the fluid nature of the web (or what Frank Chimero calls the “edgelessness”).

Say you have an idea for one of your own. How do you link those disparate elements in a cohesive way? You can start by choosing two or three parts and combining them into a larger block, which then forms a core part of your digital story. This block can be displayed anywhere, anytime, as the story demands. For example, one Pixel Fable story in the works pairs a Google map with images and text to define key places (like the birthplace of a mad baddie) or give the factual history of a setting.

So those are the bones of a nonlinear narrative, but they come in a range of forms. Let’s take a closer look.

Types of nonlinear narratives

This format isn’t exclusive to the web. From Scheherazade’s ancient tales, which weave together multiple story lines, to the movie Memento, which mimics hypertext structures, we see plenty of effective nonlinear structures outside the internet. The same is true of Pixel Fable’s inspiration—but what started hundreds of years ago as interlocking oral histories takes new shape online.

As we examine these new forms, I encourage you to note the story’s structure, how elements are linked, and how they grab your attention. You might ask yourself:

  • What does the site or app ask the audience to do? Look at the UI and copy: is the experience active (prompting visitors to do specific online/offline actions) or passive (asking only for their attention)?
  • How do elements relate to one another? Do they reinforce the central story, or do they offer a counterpoint? What content types appear to be “natural fits” with one another? How are elements ordered—do the interactions between pieces of content create a sense of rhythm?
  • What’s the smallest collection of content you could see and still understand the narrative?

Extra-narratives

Extra-narratives combine one central story or topic with lots of tangents. National Geographic’s “The Serengeti Lion” features a central theme: life for the Vumbi pride. Videos, images, and commentary are branches that enrich that story, allowing you to see—and hear—life on the plains, offering things like aerial views from a drone or the sounds of the pride crunching on zebra bones.You can quickly hop from branch to branch via contextual links, scrolling, or an index.

Screenshot from National Geographic’s microsite, The Serengeti Lion.
The Serengeti Lion.

Disjointed narratives

While disjointed narratives revolve around a common theme, the connections are much looser. They’re typically a series of chaotic vignettes. Documentaries about large, complex places are a good fit for this kind of narrative, and “Lagos Wide & Close” does this excellently. With a variety of content blocks forming multiple perspectives, interviews, and locations, the site evokes the dusty, jumbled vastness of the Lagos metropolis, both up close and from afar. The city acts as the central character, and the different interviewees and locations become vignettes about a wild megacity.

Screenshot from the ‘Lagos Wide & Close’ documentary site.
Lagos Wide & Close.

Parallel narratives

As the name says, these show two stories happening at the same time, often with competing goals and conclusions—which makes parallel narratives ideal for contrasts.

Screenshot from UNICEF’s ‘Moon’ site.
Moon.

Moon, by UNICEF, follows the parallel lives of two kids. Each wakes in the morning and goes about their life: one ends up working in a factory for a living, while the other goes to school and becomes an astronaut. After you enter a short code to link the desktop site to your smartphone, your phone becomes a controller. When you rotate your phone, you flip the desktop screen 180° to watch that child’s life unfold.

It’s a clever use of tech, and the story itself makes a clear point about poverty, wealth, and educational inequality. (I know, there’s a particular irony in interacting with a story about poverty on two expensive digital devices.)

Database narratives

These are perhaps closest to the types of work designers and developers do every day. Database narratives use metadata, ARIA roles, and tagged content to auto-generate content. They’re most commonly deployed in data visualizations, where a story’s meaning often comes from the explanatory framing (via copy) and juxtapositions of data.

Subway-inequality map from the New Yorker Magazine.
Subway-inequality map from the New Yorker.

For instance, the subway-inequality map from the New Yorker builds an elegant, interactive narrative on wealth disparities, out of seemingly impartial census data. Visitors can click to see how income varies—sometimes dramatically—across subway lines and stations, and their neighborhoods. Database narratives are an effective way to convey a lot of data in a small space.

Micro-narratives

Sometimes we want to tell small, self-contained stories that, at most, may only share an interface with other micro-narratives. The focus is on the individual story—you can view micro-narratives on their own, with no loss of reference or concept. This structure is especially useful for user-generated content (like collections).

Screenshot from the Hi site.
Hi.

The site Hi does this wonderfully. It’s a platform for capturing and writing about different moments in real time. Visitors explore stories of photos and text—bookended with optional private comments from readers—on places all over the world. Each story is also added to a Google map; this extra layer of shared functionality gives the site a more cohesive feel, while still allowing each story to stand on its own.

Okay. We’ve covered the building blocks of your narrative toolkit. Now, let’s consider what really makes any of them truly meaningful: your audience. 

Audience participation and feedback loops

Digital narratives depend heavily on the audience experience. With so many potential entry points to your story, you must define the role you want the audience to play. One constant source of tension is who controls the story: you (as the author), or your audience? Whatever narrative form you’ve chosen, it’s something you’ve designed to achieve a specific goal. Your audience, however, probably won’t be content to sit in front of a screen and follow you around. Your visitors want the ability to choose their own paths—what they see, and the order in which they see it—into your content blocks. It’s up to you to design situations and narratives that take this into account.

Happily, we have a few strategies to help you do so—and balance the tension between author and audience.

Encourage exploration

This approach draws on nonlinear narratives’ strengths—meaningful tangents over time. Create a framework with plenty of content branches, leaving your visitors free to choose what most interests them. Discoverability is key here; your job is to offer enough guidance so visitors know what to do, and then get out of their way. Clearly mark possible routes with instructional labels, animations, and even color-coding. Provide menu structures that prioritize choice over simple information retrieval. For example, group similar narrative blocks in a large slideout menu, or pair questions and thumbnails, instead of relying only on text links. As you develop more content, add it to the framework as a new offshoot to explore.

Screenshot from the Guardian’s ‘Seven Deadly Digital Sins’ microsite.
Seven Deadly Digital Sins.

For instance, the Guardian’s “Seven Deadly Digital Sins” features an incredibly complex set of stories and dispersed content. The loose layout, which displays the sins in grouped thumbnails, and the slow, measured music encourage people to experience the narrative at their own pace.

Prompt the audience to play a part

Or, give your visitors even more agency. Build them into your story. With this approach, you take your framework and then set parameters for audience contributions.

Screenshot from the Flight Paths site.
Flight Paths.

In 2001, the Guardian reported a sad, gruesome story. The body of a man fell out of the sky and landed in the parking lot of a home-goods store in the UK. It turns out he was a Pakistani stowaway who hid himself in the wheel well of a Boeing 777 out of Bahrain. Long since frozen to death, he had fallen out of the wheel well as the plane landed.

Some years later, Kate Pullinger and Chris Joseph created Flight Paths, based on this and similar stowaway events. After devising a setup around the life of a fictional stowaway named Yacub, they invited about 70 readers to add images, video, and text to what they called a “networked novel.” They continue to develop the narrative, most recently with an API, which packages and publishes that nightmarish story in a variety of formats.

It is a great example of how an internet community created an extra-narrative in bits and pieces. Your audience may feel more invested in a story they helped construct. However, it’s important to be clear about what your participants can expect. You’ll want to model the types of content you’re most interested in receiving (include specific prompts, give sample copy, etc.) You’ll also want to work out questions of attribution, ownership, and payment beforehand. For Pullinger and Joseph’s experiment, some potential contributors rightly asked if Flight Plans would be “monetized” and, if so, what was their work worth? Make sure you supply those answers in your terms and conditions.

What is vs. what if

In all this, understand the difference between what is and what if. When I first started Pixel Fable, I wanted the audience to see my story, characters, and action through my eyes. I wanted to determine what IS. But the internet asks us to give the audience control over essential aspects of the story so they don’t lose interest and move elsewhere. Remixes are another way to keep visitors entertained. By designing narrative blocks for the audience to repurpose, we enable users to ask themselves “what if”—which results in new fan art and digital tangents we may never have dreamed of. It’s a powerful thing.

Screenshot from the Midsummer Night’s Dreaming site.
Midsummer Night’s Dreaming.

In Midsummer Night’s Dreaming, a collaboration between Google and the Royal Shakespeare Company, the audience was invited to participate in a live performance. Using Google+ as the digital “stage,” people could post videos acting out their favorite scenes, costumes, observations, and fan art. They could imagine alternate scenarios and endings for Shakespeare’s famous characters. The project let anyone who loved A Midsummer Night’s Dream answer the question, “What if I were center stage?”

Creating narrative goals (friction points) and narrative threads

So, you’ve designed collections of content for a story, perhaps even split them across sites or platforms. You have specific events you want the audience to interact with, ones that deepen their experience. Although the entrances and exits to your story are largely up to the audience, we can help their journey by defining clear narrative goals, or points of friction: places your audience will be compelled to stop, explore, and interact with key narrative elements.

What does an effective narrative goal look like? Perhaps it’s a climactic event, fascinating images and videos, or even a puzzle to solve. What part of your experience will make people look further and fit some of the disparate pieces together? In the New Yorker’s inequality map, one primary goal is getting the audience to find their home station and discover the median income. Finding their neighborhood, or a place they recognize, is a task that forces the audience to slow down and view the data. The resulting visual contrast, in this case (relative) wealth and poverty, becomes the point of friction.

Narrative threads are the pathways between your goals; they move the audience from one content block to another. A thread can be a simple link between two HTML pages, or perhaps a more complicated geotagged location on a map. In “Lagos Wide & Close” and “The Serengeti Lion,” we see these threads displayed as UI. The forward and back buttons, the location-selector menus, and other interface elements act as connectors. On the Hi site, the categories beneath each captured moment allow visitors to jump from story to story.

A place for nonlinear narratives

The internet continues to grow. As we design larger and more diffuse experiences, we need to make sure they are connected and accessible to our audiences.

My experience with Pixel Fable has forced me to look beyond traditional story formats. I know the stories I want to tell. That’s where these ideas on nonlinear narrative come in. I can identify the content chunks I want, the points of friction and participation for the audience, and the way to use narrative threads to link them—all to create immersive, nuanced digital experiences.

Throughout this article, we’ve looked at specific concepts and structures that you can adapt for your work. Entertain, surprise, and above all, engage your audience—encourage them to ask what if, as they navigate the worlds you’ve spun.

Standardization and the Open Web

Posted by The fine folks at A List Apart |21 Apr 15 |

We’re done arguing over the importance of web standards. Accessibility, stability, quality control, and ease-of-use all helped to settle the debate long ago. Advocacy websites created to promote web standards—such as Chris Heilmann’s Web Standards for Business and The Web Standards Project—haven’t needed to change at all since the mid-2000s.

What has changed, however, is the way standards are developed—an issue arguably as important as the standards themselves. The next community debate, then, isn’t about web standards; it’s about how web standards should be standardized.

What’s in a standard?

The idea that standardization is important is reflected in the language we use to describe our projects and communities. For example, the JSON API homepage states that it is a “Standard for building APIs in JSON.” The FAQ page describes JSON API as a specification, and developers are talking about its use in terms of compliance. A competing project, HAL, references the visual language of standardization on its website—the flow of the page reminiscent of a formal Request For Comment, before directing you to the actual Internet Engineering Task Force RFC.

These projects illustrate a conflation of ideas about standards, which, left unaddressed, can lead to confusion. Both the JSON API specification and the HAL specification are de facto standards—an idea for a best practice approach to a common-use problem that is spreading organically through the developer community.

The specifications we tend to think of more commonly, such as those for HTML and JavaScript, are voluntary consensus standards, meaning that international standards-setting bodies and industry consortia have agreed to work on and adopt these specifications, and create incentives for their implementation. But even in a voluntary consensus environment, differences of opinion can split a technology—JSON (not to be confused with JSON API) actually has two competing voluntary consensus specifications: one with the standards group Ecma, the other with IETF.

While the term “standard” is used here in all cases, all specifications are not created equal. We sometimes even see RFCs for technical specifications that will never become standards because they are theoretical ideas for how something might work; ergo, all standards will have specifications, but not all specifications are standards.

Making standards

“Official” standards are specifications that have gone through a process of voluntary consensus. There is potentially a clear path for projects to evolve from a de facto specification to one that is standardized through voluntary consensus:

  1. Developer identifies problem and proposes solution to peers;
  2. Peer community provides feedback and proposes potential alternate solutions in public channels like GitHub or Google Groups;
  3. Peer community reaches mass consensus and hands specification off to a standards body;
  4. Developers implement solution while the standards body formalizes and legalizes the standard.

Most developers I know are smart, resourceful, and prefer the path of least resistance; thanks to the all bugs are shallow mentality of the OSS community, they’re inclined to work together to solve issues of mutual concern. This is a fairly straightforward, not-at-all-new idea, and The Extensible Web Manifesto is essentially a call to action to implement more developer feedback on this very process.

It’s exciting to think that the next official web standards might come from the developer community, but in practice this path to official standardization has been obfuscated. The Responsive Images Community Group experienced this firsthand when it proposed a specification for the picture element—noting an issue with the way HTML handled responsive images, the RICG proposed a developer-built, de facto solution to the Web Hypertext Application Technology Working Group, maintainers of the “living” HTML standard. In a well-documented series of events, WHATWG practically dismissed the developer solution in favor of a vaguely specified solution they created over the course of a few days. If it weren’t for the passion and persistence of the community and of RICG leadership, the developer solution would’ve been defeated.

The RICG specification was ultimately accepted by WHATWG and the W3C, but the experience of the standardization process certainly left a bad taste in developers’ mouths. It would be easy enough to focus our attention on improving this process for community groups like RICG, and the web would certainly be a better place for developers if we did so—but wouldn’t it be nice if we could define standardization not as “a process that makes technology,” but as “a process that makes agreements about technology”?

In reality, open standardization is a fundamentally power-laden and political process, and it’s making its way into how we think about Open Source project and community governance. Put in the terms of Eric Raymond’s seminal essay, we’ve built web technologies in the bazaar-style of the open source development ethos, but standardizing those technologies is a cathedral-building activity.

As we seek to standardize technology, we need to recognize the tension inherent in building cathedrals that will later become central authorities for us to reject. Our challenge is to find the balance between capitalizing on the benefits of standardization processes without eroding our community ideals. Thankfully, there are long histories of standardization efforts in other industries and communities that can provide insight for standardizing the web.

Old models for modern standards

Open source communities can learn a lot from the histories and governance models of different standards organizations—indeed, web standards consortia like Ecma International and the W3C already have similar organizational structures, but it’s helpful to understand the prior art upon which we are laying our community standards-setting foundation. After all, the “keep what works” mentality only works in the long run if you understand why it works in the first place.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

Eric Raymond

The ideological origins of web standards bodies come from early efforts to standardize telegraphy and engineering in the 19th century, through committees such as the American Society of Civil Engineers, American Society of Mechanical Engineers, and American Institute of Electrical Engineers. Many hosted regular “congresses”—Victorian-era precursors to today’s web development conferences—that helped to create standards and to further define the identity of the professional engineer.

As engineering disciplines began to overlap, it became clear that cooperation between these industrial societies would be necessary, so in 1918 the American Engineering Standards Committee was formed to encourage cooperation and coordination of standards across groups. The resulting structure was an “organization of organizations” that facilitated consensus-building among multiple engineering organizations, each comprised of a diverse pool of engineers from a diverse set of companies.

Today, the AESC is known as the American National Standards Institute, but its 100-year-old model of governance—rife with community crises and ideals—is reflected in web standards groups. Then, as now, organizational disputes often arose between “shop culture” practitioners and “school culture” academics. A certain amount of tension between groups is healthy for moving ideas forward, and these early groups evolved organizational means for creating and releasing tension as necessary. Today’s default response to disputes in open-source software is to fork the specification in question, producing a network of rival camps who are incentivized to emphasize differences instead of areas of agreement.

When ideals compete

“Openness” is a core ideal in the Open Web community, as well as something of a polluted word. The rhetoric of openness is meant to communicate a favorable set of values, and those values often depend on the speaker and the audience. In his book Open Standards and the Digital Age, Professor Andrew Russell notes that “for individuals, ‘open’ is shorthand for transparent, welcoming, participatory, and entrepreneurial; for society at large, open signifies a vast increase in the flow of goods and information through a global, market-oriented system of exchange.” In the absence of a single definition that suits all parties, we tend to take “open” to mean “inclusive of everything.”

Standardization, on the other hand, is often a process that defines what something is in terms of what it is not. Russell notes that the broader societal goal of standardizing technology is to create a “cohesive and flexible network” that can sustain complex social and economic activity. Thus, the process of making standards means incorporating a wide range of practices and ideas with political, economic, and cultural dimensions—all of which may be of strategic importance to creators, implementors, end users, and the general public. Put this way, standards are technically-oriented instances of diplomacy.

In establishing the ISO subcommittee for developing open working standards in 1977, Charles Bachmann noted that “the adjective ‘open’ means to imply that all participants come to the system as equal partners.” In reality, participants don’t often come to the table as equal partners—the OSI’s own progress was stymied by organizational power plays and the growth of a competing technology, TCP/IP. But equality as an ideal of open standards-making has remained. This ideal is rooted in a deeply held opposition to centralized power, which, according to Russell, is reflected in the histories of many standards-setting organizations. Upholding this vision of equality and achieving successful implementation meant, at times, hiding conflicts and issues from those outside the meeting room—not exactly the transparent behavior one might expect from an “open” system. 

If standards really are agreements between equal parties, then the agreement is the controlling authority. And if standards-setting is a rejection of centralized control, then the standardization process becomes one of creative destruction. It’s the ideological circle of open-standards-making life: a group makes a consensus standard on some technology; as the standard circulates, a new party arises to point out a flaw or an unconsidered use case for the existing standard. The original group then has to make room for the new party and rework the standard, or else face rejection of the group and the standard. In rejecting the original group, the offended party forms a competing group and standard, and the cycle begins anew. 

It’s complicated

It’s a tangled web we weave standardizing the Open Web—political, economic, and social relationships between people, technologies, companies, and industry groups are difficult to ascertain at a glance. On closer inspection, one can see that these organizations and communities are complex systems forming a complex network—so complex that I was compelled to create this interactive Open Standards network graph to help keep it all straight as I researched.

Before we rush off to create a complex, decentralized network of open source standards groups, it probably warrants mentioning that complex systems fail 100% of the time. A decentralized network may let us fail smaller in most cases, but the key to longevity of the system is failing smart—and if the research has taught me anything, it’s that standardization fails on the human, not the technological, element. For better or worse, complexity is not viral—so to mitigate this, we need to make the complexity of the standardization system consumable without abstracting away meaningful parts of the process.

In the absence of community coordination, methodless enthusiasm will ensue—and caught somewhere in the Bermuda triangle of competing standards bodies, implementers, and OSS maintainers is the developer community. If we want our community-driven projects to become official, internationally recognized standards, we need to understand the impact of our governance processes as well as we understand the technical specifications for our technologies.