May
29

We (Still) Have Work to Do

Source: A List Apart

We’re here, and we’re on the record: the web industry has a diversity problem. It’s got a misogyny problem. It’s standing in the way of the web we want, and we are all—every one of us—responsible for changing that.

I wrote these words one year ago today, at the peak of the #yesallwomen discussion. They’re just as true now as they were then. But as Nishant Kothary wrote in his column a couple weeks back:

Even with its hundreds of contributors, columnists, and bloggers, ALA has very little to show for this aspiration in a year (interestingly, what it does have to show was contributed almost entirely by women).

I make this point not to criticize ALA…but to highlight just how difficult it is to talk about difficult things even when you explicitly and publicly set the goal of doing so.

So, what have we done? It’s a fair question, and one that’s worthy of a response. Because the answer is this: everything, and also not nearly enough.

Over the past year, we’ve started discussing inclusivity constantly, across every facet of our work—the authors we encourage, the messaging on our website, the people we invite to events, the way we edit articles, the topics we cover.

And yet, we screw up constantly. We cringe when we notice too late that we published an article with a biased example, or used words that defaulted to male. We struggle to include more people of color and non-native English speakers in our pages. We hear that our submissions copy feels alienating.

We’re trying. But what we haven’t been doing is talking about it publicly—because it takes time, yes, but also because it’s scary to lay bare all our decisions, discussions, half-baked ideas, and partially executed plans. It’s scary to say, “we don’t know all the answers, but here’s where we’ve started.”

That changes today.

What we’re up to

“We have work to do,” I began last year. And we still do. Sometimes, that work feels overwhelming. Mostly it’s exciting, because it reminds us why we’re here, and what we want this industry to look like in another year, in five years, in ten years.

Here’s what we’re working on so far:

More inclusive editing

When we edit, we no longer just look for stuff that violates the style guide: website as one word, or 4g with a lowercase g. We also look for biases and non-inclusive language in the words our authors use, and we challenge them to come up with words that pack power without excluding readers.

It’s not black and white: reasonable people have conflicting opinions on the use of you guys, for example. And some things are so deeply embedded in our culture—like calling things crazy or insane—that’s it’s tough, at first, to even recognize that they’re problematic.

One change you may have noticed, if you’re as nerdy about words as we are, is our move to the singular they. Writing “he” or “she” is fine, if you’re talking about a person who goes by “he” or “she.” But when we talk about a person in general, or someone who doesn’t identify as male or female, they’re now a they.

The most important part of this process is that it’s just that: a process. We haven’t “fixed” our editing style. We’re just having an ongoing conversation that gets more nuanced with time—and that everyone on the team is encouraged to participate in.

Some people might find the prospect of hashing and rehashing language tedious (ugh, do we have to talk about this again?!). But I’ve found it incredibly rewarding, because every discussion forces me to challenge my beliefs and biases—and to be a little more willing to listen.

Recruiting diverse authors

When I joined A List Apart in 2012, every issue was a nail-biter: we were never sure until the last minute whether we’d be able to get the new articles together in time. I wanted to recruit and encourage diverse authors—I think everyone on staff did. But when everyone’s brain is stuck on “do we have something to publish?,” it’s hard to make space for questions like, “are we consistently presenting a realistic view of our industry?”

We should have. It wasn’t until the end of 2014 that I stopped and looked—and I didn’t like what I saw. In 2013, for example, only about 25 percent of our feature articles (that is, not blog posts or columns) were by women. One in four!

Last year’s numbers were more balanced: about 40 percent of our authors were women. But here’s the funny thing about that number: I thought we were publishing lots of women in 2014. Our pages seemed to be full of ’em! Which just goes to show how easy it is to normalize lack of diversity when you’re not paying attention: 4 in 10 feels like “a lot,” instead of “less than half.”

That said, 40 percent is better, and we expect this year will be even more balanced—and more diverse in other ways as well. So what have we done? First, we invested in defining our acquisitions and editing process, making clearer decisions earlier about which articles we were accepting, and developing more specific expectations with both editors and authors about deadlines. This isn’t about diversity directly, but indirectly, it’s made a huge difference—because rushing around pushing articles out the door meant that we were never really building a solid pipeline. We were running ourselves ragged without addressing problems up the chain. Formalizing our acquisitions process and clarifying roles and responsibilities freed us up to spend time on bigger picture issues.

We’re also actively reaching out to more prospective authors, and encouraging them to write—especially people of color and women who are just emerging in their fields. Oftentimes, these folks have viewpoints and ideas we haven’t heard before—but they’re more likely to think they’re not “experienced enough” to submit an article. There is no shortage of articles talking about why this happens. The problem is, many of those articles simply end up telling marginalized groups that they’re responsible for solving the problem: here’s the careful tightrope you need to walk in order to promote your ideas without coming off as “pushy,” they seem to say.

We’re not buying it. Women and people of color—and particularly women of color, who often feel sidelined by the largely white “women in tech” movement—already have enough to deal with in this field. The least we can do is put in some effort to reach out to them, rather than complaining that they don’t come to us.

Another area we’ve focused on is ensuring our ranks of bloggers and columnists—the people who write for us regularly—reflect the range of people in our industry. I don’t think we’re quite there yet, but we’re working on it—because the more often diverse faces show up on our site, the easier it is for everyone to imagine themselves there.

It’s not easy to recruit diverse authors, and there are still lots of reasons smart, talented people from marginalized groups don’t want to expose themselves to the risks of writing publicly. But here’s the truth: finding diverse authors isn’t that hard, once you’ve started.

Changing our tone

In addition to changing our submissions and editing processes, we also took a look at how we were talking about ourselves, our authors, and the process of contributing to the magazine. Here’s what the copy on the submissions page used to say:

So you want to write for A List Apart Magazine.

What we’re looking for

We want to change the way our readers work, whether that means introducing a revolutionary CSS technique with dozens of potential applications, challenging the design community to ditch bad practices, or refuting common wisdom about, say, screen readers.

If your article can do that, we want to see it.

“So…” So? That tiny word sets a tone of disbelief—like we might as well have added “then prove it” at the end. And don’t get me started on those verbs: challenge, refute, revolutionize. Why are we being so aggressive? What about articles that help our community grow, learn, or improve?

We had good intentions here: we wanted to make readers feel like an ALA article was special—not just a post you whip out in an hour. But it wasn’t working. When I asked people whom I’d like to see submit what they thought, I got responses like, “sending something to ALA sounds scary,” or “that seems like a really big deal.”

Oof.

Writing publicly makes most people feel vulnerable, especially those who are just starting to put their ideas out there for the world—in other words, the very people we’re most interested in hearing from. You might get rejected. People might disagree with you. You might even get harassment or abuse for daring to speak up.

We can’t remove all the risks, but what we can do is offer a more nurturing message to new writers. We started by overhauling our contribute page—in fact, we renamed it Write for Us, with an aim of making the message a little more human. Then we got feedback from a couple prospective authors, which led to another round of tweaks. Here’s what it says right now:

Write for Us

Yes, you. We’re always looking for new authors. If you’ve got an idea that will challenge our readers and move our industry forward, we want to hear about it. But you don’t need to wait for an idea that will redefine web design. Just aim to bring readers a fresh perspective on a topic that’s keeping you up at night.

Rereading it now, I don’t think it’s quite right yet, either. It’s still got more of those aggressive verbs than it needs. But one thing I love about it is this:

Yes, you.

Those two tiny words speaks directly to someone who’s not sure they’re in the right place, not sure we really want to hear from them.

Of course, there’s more to our tone than what’s on the submissions page. We’ve also started making other communications less aloof and a bit more approachable. We’re not some impenetrable entity in the sky, after all. We’re your peers.

It’s funny to admit this, because it sounds so obvious. But one thing we’ve started doing just recently—as in, this spring—is tweeting about accepting new authors. Nothing fancy: just kindly, and regularly, reminding people that we’d love to hear from them.

Why didn’t we do this years ago? The easy answer is that we just never thought about it. We are all busy, working on ALA on the side, and “social media strategy” has never been our top priority. But if we’re being honest with ourselves here, the real answer is this: we didn’t want to admit that incredible, mind-blowing, ready-to-publish content didn’t just come to us.

But getting great articles about a big, changing industry simply isn’t easy, no matter who you are or how long you’ve been publishing. And, admittedly, our editing process isn’t exactly a walk in the park: we have high editorial standards, which means we don’t accept everything that comes our way, and we ask writers lots of tough questions even when we like their work. What that adds up to is that many submissions won’t pan out, and many already established authors aren’t looking for the kind of editorial commitment writing for us entails.

So, now we do a better job of reaching out to the people who do want that commitment, and that opportunity to learn.

All it took was swallowing some pride.

Inclusion is a practice

I wish I could say that all these changes have been easy for me. But wanting to be more inclusive and actually doing what it takes to be inclusive aren’t the same. Along the way, I’ve had to let go of some things I was comfortable with, and embrace things I was profoundly uncomfortable with.

For example: I hated the singular they for years. It just didn’t sound right. That’s not how subject-verb agreement works, dammit. Our columns editor, Rose, suggested we start using it forever ago. I vetoed the idea immediately. I edited it out of articles. I insisted authors rewrite examples to avoid it. I stuck to my she and he like they were divinely prescribed.

Only grammar isn’t gospel. It’s culture. Language changes constantly, adapting endlessly to meet the world’s new needs and norms. And that’s what we have right now: a cultural shift toward less gendered thinking, less binary thinking. I wanted the culture change without the language change.

I was wrong.

If someone has a problem with it, they can complain to me.

What’s next

Our process is evolving constantly, and I can’t tell you exactly where we’ll be this time next year. But I can promise this: we’re going to keep talking about it—inside of ALA, and, more often, publicly, too.

We still have work to do. But our industry—our peers whose paths are more difficult than ours—deserve it. We hope you’ll join us.


Read the full article

May
22

On Our Radar: The Empty Space That Is Not Empty

Source: A List Apart

“Being in tech and not caring about tech culture is a luxury, only affordable to those with enough privilege to ignore it and too little empathy to care.”

In her beautiful, award-nominated “A Talk About Nothing” at the 2015 .concat() web development conference, Lena Reinhard delivers a luminous exposition of how tech’s version of meritocracy is a brilliant system—for the people who get to define what merit is. When we overlook entire groups of people who could be making fantastic contributions to our future, we all end up with less. Don’t miss this talk. It’s full of stars. —Rose Weisburd, columns editor

Your weekend reading

  1. “Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?” In The Sliding Scale of Giving a Fuck, Cap Watkins shares a useful framework for communicating how strongly you feel about a topic you’re debating with colleagues. I appreciate that it’s intuitive enough to use without explanation, and provides a way to engage on opposite sides of a subject without needless drama. —Aaron Parkening, project manager
  2. You may be intimately familiar with a typeface like VAG Rounded from (until recently) Apple keyboards. Or perhaps you’ve chosen a rounded sans like Process Type’s Bryant for a project. But how well do you know the history of these letterforms? FontShop’s Ferdinand Ulrich recently published the second part of his comprehensive survey of rounded type. (Part 1 appeared in March, and Part 3 is on the way.) —Caren Litherland, editor
  3. I’ve been doing some research into virtual reality (VR) and, although this is a few months old, I’ve just stumbled across it and wanted to share it. Mozilla has a team working on virtual reality and the open web. Their video presentation, Virtual Reality & The Web: Next Steps, is a fascinating introduction to how VR works, with demonstrations on how to build experiences for it using HTML and CSS. —Anna Debenham, technical editor
  4. “Progressive enhancement just works.” Aaron Gustafson compares two real case studies—one built to progressively enhance and another built to degrade gracefully—to show how progressive enhancement from the ground up can save considerable amounts of time and money for a project in the long run. —Michelle Kondou, developer
  5. I can’t say that I’m 100 percent sold on my own lifelong vegetarianism, but I like to think that it lends me a small amount of objectivity in hamburger-related matters. As such, I’m on the same side as the BBC when it comes to hamburger menus and their inscrutability for the average user: just because we designers and developers have a taste for them doesn’t mean they should always be on the menu. —Mat Marquis, technical editor

Overheard in ALA Slack

“What kind of bears are we talking about here, exactly? The article is light on the details.”

Your Friday Vine


Read the full article

May
21

15 Years Ago in ALA: Much Ado About 5K

Source: A List Apart

15 years ago this month, a plucky ALA staffer wrote “Much Ado About 5K,” an article on a contest created by Stewart Butterfield that challenged web designers and developers to build a complete website using less than five kilobytes of images and code. Hundreds did, and their work far exceeded what any web professional could have reasonably expected:

Halfway through the judging, we hated this contest. Not because the work was bad. But because so much of it was so very, very good. Arguably, more great work was submitted to this contest than to many of this year’s big-time awards shows. It was nearly impossible to pick a clear winner from among so many instances of sheer creative excellence.

And we couldn’t help feeling unworthy, as one artist after another did more with their 5K than we typically pull off with 50.

Having learned once again the importance of constraint and the empowering creative influence it can have on design, our community high-fived itself…and promptly forgot everything it had learned as we started building heavier and heavier sites.

Soon, driven by fear that apps would make the web irrelevant, we began relying on frameworks that made even the simplest website act and feel like a mind-blowing application. Serving reams of code we didn’t need because, hell, it came with the frameworks, and abandoning principles like progressive enhancement because, hell, everybody uses JavaScript, we soon fell in love with high-resolution, full-screen background images, then fell even harder when those images quadrupled in weight thanks to Retina.

And still the little article memorializing the little 5K contest sat online, its lessons forgotten in an arms race wherein the average home page now weighs over 2MB. Put that in your Edge network and smoke it.

Ah, but what goes around (performance) comes around (performance). Beginning in 2013, conversations about responsive web design “shifted from issues of layout to performance” as leading web designers and data sifters came to realize that, even on speed and bandwidth-limited networks, users expected sites to render as fast on phones as they do on the desktop—if not faster. That if your site didn’t render as quickly as users expect, they would abandon it, perhaps forever. That a traditional, desktop-first approach to responsive web design guaranteed user disappointment and site abandonment; that, performance-and-bandwidth-wise, at least, a “mobile first” approach made far more sense—and not just for mobile users. That you could no longer give high design marks to a site (however innovative, however visually arresting) if it took forever to load over constrained mobile networks. Because performance was part of design, and always had been.

As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.

For more on performance:


Read the full article

May
21

Mark Llobrera · Professional Amateurs: Instant Web

Source: A List Apart

Instant Articles are here, and the announcement is all about speed. From a user perspective, I think that Instant Articles are a good thing. But I bristle at the implications for the open web. Implicit in the sales pitch (and explicit in much of the commentary that followed) is the familiar criticism that the traditional HTML/CSS/JS web stack is too slow to deliver a first-class experience. Facebook may have been throwing shade, but others were more overt in their criticism.

John Gruber put it in stark terms:

I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.

I don’t believe that the web is inherently slow, although I do acknowledge that over-produced web design could give rise to that assertion. But that’s a fine distinction, because in practice it might as well be true—as Scott Jehl says so very succinctly:

So yeah, I think any criticism of the web’s terrible performance is totally valid. We can choose to do better, but our focus is elsewhere.

— Scott Jehl (@scottjehl) May 14, 2015

That the performance of bloated websites is the norm is profoundly disappointing, all the more so because we’re the ones who made it that way. Users of all kinds need the open web, because it serves everyone—including people without a Facebook account and people without access to the latest mobile devices. But even without the Instant Articles bar to measure against, we’ve been shipping slow sites and thus failing those very users. Tim Kadlec gets to the heart of the matter in his post “Choosing Performance,” and it’s simultaneously simple and complex:

It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

This goes back to what many have been stating as of late: performance is a cultural problem.

I think Tim’s point is dead on. Later in the piece he points out how culture change usually moves more slowly than technical solutions, and that’s specifically true for the folks building the web.

In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast. Unless you make some fundamental choices and set up clear constraints, you can—and will—build and ship beautiful sites without feeling a single ounce of the pain and frustration that your users encounter when all of that beautiful imagery, CSS, and JavaScript comes trickling down their mobile network.

My family and I are big fans of cooking-competition shows. I love how the judges save their harshest criticism for chefs who let their dishes leave the kitchen without tasting them. “Did you taste this dish before it went out?” they ask, and the chef can do nothing other than hang their head in shame and reply, “No chef, I did not.”

That’s my biggest takeaway from Instant Articles: we (designers and our clients) have to start tasting our work. Not just in our proverbial kitchen, but where our users actually eat the stuff. How do we do this? Some of it is tactical. Dan Mall has a great primer on setting up a performance budget. Scott Jehl’s Responsible Responsive Design has a lot of good, practical advice on tooling and testing to make things fast, in both absolute and perceived respects.

But again: we can’t just engineer our way to a faster web, because for every bit of extra speed we wring out, we’ll find a way to fill the gap with even more over-produced design. M.G. Siegler’s analysis of Instant Articles comes to this conclusion:

Not only is the web not fast enough for apps, it’s not fast enough for text either.

It’s a funny line, but it also rings a bit false to me. Because it isn’t just text, is it? Our sites feature more and more images, webfonts, CSS, and JavaScript layered over the basic text and markup. Siegler’s line raises a particularly difficult question, though: why? Of late it seems that many of those elements layered on top of the content are an attempt to emulate the slickness and behavior of native apps. And to an extent that can be a good thing—the web has always been great at absorbing and expressing characteristics of other mediums: books, magazines, movies, video games, apps—anything and everything, really. But that impulse needs a counterbalance: we can do this on the web, but should we, if it means users won’t even stick around to see the content?

I don’t want this to be tantrum trigger, where we throw up our collective hands and yell, “We can’t do anything cool on the web! Fine! Just make it all text! ARE YOU HAPPY NOW?” I think we do have to be better at weighing the cost of what we design, and be honest with ourselves, our clients, and our users about what’s driving those decisions. This might be the toughest part to figure out, because it requires us to question our design decisions at every point. Is this something our users will actually appreciate? Is it appropriate? Or is it there to wow someone (ourselves, our client, our peers, awards juries) and show them how talented and brilliant we are?

Lara Hogan’s Designing for Performance might be the most useful resource in this regard, because it talks about how to educate and incentivize our teams toward a performance-focused culture. If you, your team, and your client build that culture with your user in mind, then the sites you build can be beautiful and immersive without negating the accessibility and reach that makes the open web so vital.

What’s exciting about this user- and performance-focused mindset is that it will still be valid and useful even if we see some much-needed advances in browser-based capabilities. I hold out hope that components like HTTP/2 and service workers will allow us to build smarter, more performant sites. But we have the means to build sites faster right this minute. If nothing else, Facebook just turned that into a higher priority for the entire web community. And that’s a good thing.


Read the full article

May
19

Journey Maps: Not the End of the Story

Source: UXMatters

By Ronnie Battista

Published: May 18, 2015

“Many in our field, including me, strongly believe in the potential of journey mapping for helping companies to achieve human-centric business transformations.”

Recently, during an early scoping effort for a project with a new client who needed our help transforming their retail experience, we proposed their considering a journey-mapping exercise. Their response:

Please! I do not want to see another journey map.”

Were we surprised? Meh. It was only a matter of time.

This response—or perhaps lament might be a better word—came from the client executive who is responsible for leading the effort. I was not at that meeting, but was curious about where this comment came from, so I probed for more detail about the context. There wasn’t much more to learn, but it was clear that this person had experienced a few journey-mapping efforts in the past and failed to see their value. And it confirmed what a lot of us have been expecting.
Journey Maps: Not the End of the Story

May
19

Asking Probing Questions During a Usability Study

Source: UXMatters

By Janet M. Six

Published: May 18, 2015

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our panel of UX experts discusses how to pose probing questions to participants in a usability study and get the answers you need, without leading them to a particular answer.

You are in the midst of a usability study and, when testing one of the tasks, you observe that participants do not seem to see a design element that would help them to finish their task. What do you do now? Do you ask them whether they see the element? Do you just continue and say nothing? Do you ask them later? Is it even possible for the moderator to avoid affecting the test results in some way?
Asking Probing Questions During a Usability Study

May
19

Designing an Effective Contact Form

Source: UXMatters

By Monique Rivers

Published: May 18, 2015

“Business owners who think that contact forms are nothing more than an easy method of communication that they provide to users of their Web site are making a huge mistake.”

Business owners who think that contact forms are nothing more than an easy method of communication that they provide to users of their Web site are making a huge mistake. Contact forms should not be passive elements of a Web site that gain meaning only when visitors have a problem and use them to find out an easy way to solve it.

Great contact forms inspire people to reach out and play an active role in a company’s online presence. But what makes a contact form really effective? What are the key features of the best contact forms? Read on to find out.
Designing an Effective Contact Form

May
19

How to Respond to Typical UX Project Challenges

Source: UXMatters

By Baruch Sachs

Published: May 18, 2015

“My expectation is that, at some level, most people recognize the importance of user experience these days.”

After nine years of building a robust UX consulting practice within a large software consulting firm, I sort of expect certain things. For one thing, I expect that the people in my organization understand the basic importance of what I do. I’ll bet you do, too. While we might not always get all of the time we’ve scheduled or be able to do all of the things we want to do on a project, in general, our expectation is that, at some level, most people recognize the importance of user experience these days. After all, even when some auto parts store in some remote part of the world revamps their Web site, they tout their “simplified user experience.” When you see that, you start to think that this whole UX thing has become institutionalized to some degree.

That’s why it came as a bit of a shock to me recently when I realized that the issues one of my consultants was having on a project were the result of a development team that felt a good user experience just wasn’t critical to the project’s success—or to the product’s overall user adoption.
How to Respond to Typical UX Project Challenges

May
19

If Congress Went Agile

Source: UXMatters

By Shannon McHarg

Published: May 18, 2015

“Last year’s rocky roll-out of healthcare.gov … got many people talking about why government agencies should join the rest of the technology industry in using agile development practices to improve the delivery of digital services.”

A positive outcome from last year’s rocky roll-out of healthcare.gov is that it got many people talking about why US government agencies should join the rest of the technology industry in using agile development practices to improve the delivery of digital services. What if we took that notion a step further and considered how the government could use agile practices to fix some of the problems we have with gridlock in Congress?

Google defines a democracy as “a system of government by the whole population or all the eligible members of a state, typically through elected representatives.” [1] However, the current state of our democracy has more to do with what lobbyists want, what would get legislators re-elected, and what would persuade the few who are willing to cross party lines to vote for a particular piece of legislation. Did you know that only 9% of bills actually become laws? [2] And 42% of all Senate votes in the last year required a filibuster-proof two-thirds majority vote? [2] If we look at this problem from a designer’s perspective, we can start to find ways to improve the system.
If Congress Went Agile

May
19

Meta-Moments: Thoughtfulness by Design

Source: A List Apart

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.


Read the full article

Older posts «