Archives

This week’s sponsor: World IA Day

Posted by The fine folks at A List Apart |22 Dec 15 |

Join the fine folks at World IA Day on Feb 20, 2016 to celebrate advancing the practice of information architecture.

Mark Llobrera · Professional Amateurs: Write What You Know (Now)

Posted by The fine folks at A List Apart |17 Dec 15 |

Sometimes the writing comes easily, and then there’s the last two months. I really wondered if I had run out of things to say. I knew I wanted to write about how more web designers and developers need to write about their work. So I wrote a bunch of paragraphs down, and then on a lark (I’m not even a regular listener), I downloaded episode 110 of The Web Ahead.

I nodded along with host Jen Simmons and guest Jeremy Keith saying some very smart things about the web and its roots as the El train cut across Philadelphia. But at the 48-minute mark things got weird, because Jen and Jeremy basically started writing my column for me while I listened. Jeremy said:

I wish people would write more… In the future, we would have a better understanding of what people are thinking now. I’m very glad that I’ve been doing my blog for 15 years. I can go back to 2002 and get a feel for what it was like to build websites. Back then we thought X was true or hadn’t even considered Y. You forget these things. Having these written records—not of anything important or groundbreaking—but just the day-to-day. The boring stuff. That’s actually what’s most interesting over time.

The fear of stating the obvious is one of my primary personal roadblocks to writing. Jeremy’s words evoke Samuel Pepys’ diary, which is a famously important resource for historians precisely because it includes so much detail about life in the 1600s—including many items that he could have dismissed as being mundane and obvious.

Non-experts please apply

I appreciate a well-written, logically-structured, authoritative blog post about code as much as the next person. But I also have a love for the blog post that is written with a posture of humility: I know this much, so far. Or even: Why is this happening? Seeing your own stop-start journey through design and code reflected in someone else’s writing can remind you that it’s ok to not have everything figured out. Turns out nobody does.

Often when a teammate shows me something cool, at the end of our conversation I’ll half-jokingly say, “write it up.” I think that’s pretty good advice regardless of where you currently sit on the continuum of despair to triumph. Don’t even wait until you have everything figured out, at the end of the project. It’s ok to write what you know now, while everything is fresh in your mind and the sheer agony (or thrill of discovery) borders on the physical. If you’ve just solved a particularly flabbergasting problem, imagine yourself on the other side of that experience, just hoping that DuckDuckGo or Google will turn up a post with even the barest hint of a solution. If that were you, you wouldn’t care that the blog post wasn’t polished. You’d just thank your lucky stars that someone took the time to bang something out and hit publish.

Lies your brain will tell you

“But nobody will read it,” you say. That may be true. But the opposite could also happen. A few years ago I was interviewing for a job, and my future boss said, “I like how you articulate things. I’ve read some of the stuff on your blog.” I was so surprised, I didn’t even think to ask which posts she liked. For all I know it was the ones where I recount the silly things my kids say. That memory made me think of this fantastic interview with Ursula K. Le Guin, where she says, “There’s always room for another story… So if you have stories to tell and can tell them competently, then somebody will want to hear it….”

On the other hand, that might be exactly what you fear—that someone actually will read it. But that needn’t be an intimidating thought. Through your writing people can to get to know you, in a way that often gets lost in casual interactions with coworkers (or formal ones with a potential boss or client). Because if you read enough of a person’s writing, their voice comes through. It doesn’t matter if it’s just explaining a technical issue and offering a solution. Their quirks, their interests—these things bleed through if you read enough of their words.

Getting more adept at writing can help you communicate confidently in other ways too. In a recent ALA On Air live event, Jeffrey Zeldman emphasized the benefit writing can have on your problem-solving process:

I think if you can articulate your thoughts in writing, even though that’s really hard, you’re going to be better in meetings, you’re going to have a point of view; you’re not going to roll over and say, “The client said I should make the button blue and make it bigger, so that’s what I will do,” but instead will go, “What is behind the client’s request? What are we really trying to achieve?”

chmod 777

So now that you’re convinced, where do you start? You might start by giving yourself permission: “I allow myself to publish this thing.” This is one of those things that I’m still working on, myself. I’ve always found writing enjoyable, even easy. Publishing, however, is not. I’ve been blogging for several years, but my ratio of drafts to final posts is pretty dismal. This column has been good for me, because now I’m accountable to someone other than myself. I’ve got an editor that I don’t want to let down. I’ve got folks who actually read this column and respond. But maybe you don’t need more accountability. Maybe you actually need to lower the stakes, and give yourself permission to just get it out there. And again, Jeremy Keith said something along the lines of what I wanted to write:

The whole point of the web is there isn’t a gatekeeper. There isn’t someone with a red pen saying, “That isn’t good enough to be published. That’s not up to scratch. You’re not allowed to publish it.”… It could be the worst thing ever and you still have the right to publish it on your website. You should do it. Don’t let anyone tell you otherwise.

Holy smokes. I heard that, and I almost bulk-published my entire WordPress drafts bin.

Recently, CSS-Tricks ran a survey that asked its community to weigh in on topics that they face daily. I answered the survey, and one of the interesting results was for the question, “You’re stuck. You search the web. You prefer to find answers in these formats:”. The top answer was blog post. Blog post! One of the other leading answers was “Q&A format page” (something like Stack Overflow). That made me think. Why wasn’t Q&A the top answer? Maybe it’s because while web designers want something that works if we simply copy-and-paste, we are also driven by why as much as how.

Code has a story. One of my favorite posts to write (and read) goes something like: “This wasn’t documented anywhere I could find, and it’s such a weird situation that if I don’t write about it nobody would believe me.” I made a category on my blog just for those posts: Technology’s Betrayal. I feel like a web designer’s life is full of those little stories, every day. And usually you tell your teammates over lunch, or over a beer, and you laugh and say, “Isn’t that nuts?” Well, I’m here to say, “write it up.” Let someone else hear that story, too.

Interaction Is an Enhancement

Posted by The fine folks at A List Apart |15 Dec 15 |

A note from the editors: We’re pleased to offer this excerpt from Chapter 5 of Aaron Gustafson’s book, Adaptive Web Design, Second Edition. Buy the book from New Riders and get a 35% discount using the code AARON35.

In February 2011, shortly after Gawker Media launched a unified redesign of its various properties (Lifehacker, Gizmodo, Jezebel, etc.), users visiting those sites were greeted by a blank stare. Not a single one displayed any content. What happened? JavaScript happened. Or, more accurately, JavaScript didn’t happen.1

Screenshot of a completely blank website with only the Lifehacker logo displayed.
Lifehacker during the JavaScript incident of 2011.

In architecting its new platform, Gawker Media had embraced JavaScript as the delivery mechanism for its content. It would send a hollow HTML shell to the browser and then load the actual page content via JavaScript. The common wisdom was that this approach would make these sites appear more “app like” and “modern.” But on launch day, a single error in the JavaScript code running the platform brought the system to its knees. That one solitary error caused a lengthy “site outage”—I use that term liberally because the servers were actually still working—for every Gawker property and lost the company countless page views and ad impressions.

It’s worth noting that, in the intervening years, Gawker Media has updated its sites to deliver content in the absence of JavaScript.

■ ■ ■

Late one night in January 2014 the “parental filter” used by Sky Broadband—one of the UK’s largest ISPs (Internet service providers)— began classifying code.jquery.com as a “malware and phishing” website.2 The jQuery CDN (content delivery network) is at that URL. No big deal—jQuery is only the JavaScript library that nearly three-quarters of the world’s top 10,000 websites rely on to make their web pages work.

With the domain so mischaracterized, Sky’s firewall leapt into action and began “protecting” the vast majority of their customers from this “malicious” code. All of a sudden, huge swaths of the Web abruptly stopped working for every Sky Broadband customer who had not specifically opted out of this protection. Any site that relied on CDN’s copy of jQuery to load content, display advertising, or enable interactions was dead in the water—through no fault of their own.

■ ■ ■

In September 2014, Ars Technica revealed that Comcast was injecting self-promotional advertising into websites served via its Wi-Fi hotspots.3 Such injections are effectively a man-in-the middle attack,4 creating a situation that had the potential to break a website. As security expert Dan Kaminsky put it this way:

[Y]ou no longer know, as a website developer, precisely what code is running in browsers out there. You didn’t send it, but your customers received it.

Comcast isn’t the only organization that does this. Hotels, airports, and other “free” Wi-Fi providers routinely inject advertising and other code into websites that pass through their networks.

■ ■ ■

Many web designers and developers mistakenly believe that JavaScript support is a given or that issues with JavaScript drifted off with the decline of IE 8, but these three stories are all recent, and none of them concerned a browser support issue. If these stories tell you anything, it’s that you need to develop the 1964 Chrysler Imperial5 of websites—sites that soldier on even when they are getting pummeled from all sides. After all, devices, browsers, plugins, servers, networks, and even the routers that ultimately deliver your sites all have a say in how (and what) content actually gets to your users.

Get Familiar with Potential Issues so You Can Avoid Them

It seems that nearly every other week a new JavaScript framework comes out, touting a new approach that is going to “revolutionize” the way we build websites. Frameworks such as Angular, Ember, Knockout, and React do away with the traditional model of browsers navigating from page to page of server-generated content. Instead, these frameworks completely take over the browser and handle all the requests to the server, usually fetching bits and pieces of content a few at a time to control the whole experience end to end. No more page refreshes. No more waiting.

There’s just one problem: Without JavaScript, nothing happens.

No, I’m not here to tell you that you shouldn’t use JavaScript.6 I think JavaScript is an incredibly useful tool, and I absolutely believe it can make your users’ experiences better…when it’s used wisely.

Understand Your Medium

In the early days of the Web, “proper” software developers shied away from JavaScript. Many viewed it as a “toy” language (and felt similarly about HTML and CSS). It wasn’t as powerful as Java or Perl or C in their minds, so it wasn’t really worth learning. In the intervening years, however, JavaScript has changed a lot.

Many of these developers began paying attention to JavaScript in the mid-2000s when Ajax became popular. But it wasn’t until a few years later that they began bringing their talents to the Web in droves, lured by JavaScript frameworks and their promise of a more traditional development experience for the Web. This, overall, is a good thing—we need more people working on the Web to make it better. The one problem I’ve seen, however, is the fundamental disconnect traditional software developers seem to have with the way deploying code on the Web works.

In traditional software development, you have some say in the execution environment. On the Web, you don’t. I’ll explain. If I’m writing server-side software in Python or Rails or even PHP, one of two things is true:

  • I control the server environment, including the operating system, language versions, and packages.
  • I don’t control the server environment, but I have knowledge of it and can author my program accordingly so it will execute as anticipated.

In the more traditional installed software world, you can similarly control the environment by placing certain restrictions on what operating systems your code supports and what dependencies you might have (such as available hard drive space or RAM). You provide that information up front, and your potential users can choose your software—or a competing product—based on what will work for them.

On the Web, however, all bets are off. The Web is ubiquitous. The Web is messy. And, as much as I might like to control a user’s experience down to the pixel, I understand that it’s never going to happen because that isn’t the way the Web works. The frustration I sometimes feel with my lack of control is also incredibly liberating and pushes me to come up with more creative approaches. Unfortunately, traditional software developers who are relatively new to the Web have not come to terms with this yet. It’s understandable; it took me a few years as well.

You do not control the environment executing your JavaScript code, interpreting your HTML, or applying your CSS. Your users control the device (and, thereby, its processor speed, RAM, etc.). Depending on the device, your users might choose the operating system, browser, and browser version they use. Your users can decide which add-ons they use in the browser. Your users can shrink or enlarge the fonts used to display your site. And the Internet providers sit between you and your users, dictating the network speed, regulating the latency, and ultimately controlling how (and what part of) your content makes it into their browser. All you can do is author a compelling, adaptive experience and then cross your fingers and hope for the best.

The fundamental problem with viewing JavaScript as a given—which these frameworks do—is that it creates the illusion of control. It’s easy to rationalize this perspective when you have access to the latest and greatest hardware and a speedy and stable connection to the Internet. If you never look outside of the bubble of our industry, you might think every one of your users is so well-equipped. Sure, if you are building an internal web app, you might be able to dictate the OS/browser combination for all your users and lock down their machines to prevent them from modifying any settings, but that’s not the reality on the open Web. The fact is that you can’t absolutely rely on the availability of any specific technology when it comes to delivering your website to the world.

It’s critical to craft your website’s experiences to work in any situation by being intentional in how you use specific technologies, such as JavaScript. Take advantage of their benefits while simultaneously understanding that their availability is not guaranteed. That’s progressive enhancement.

The history of the Web is littered with JavaScript disaster stories. That doesn’t mean you shouldn’t use JavaScript or that it’s inherently bad. It simply means you need to be smart about your approach to using it. You need to build robust experiences that allow users to do what they need to do quickly and easily, even if your carefully crafted, incredibly well-designed JavaScript-driven interface can’t run.

Why No JavaScript?

Often the term progressive enhancement is synonymous with “no JavaScript.” If you’ve read this far, I hope you understand that this is only one small part of the puzzle. Millions of the Web’s users have JavaScript. Most browsers support it, and few users ever turn it off. You can—and indeed should—use JavaScript to build amazing, engaging experiences on the Web.

If it’s so ubiquitous, you may well wonder why you should worry about the “no JavaScript” scenario at all. I hope the stories I shared earlier shed some light on that, but if they weren’t enough to convince you that you need a “no JavaScript” strategy, consider this: The U.K.’s GDS (Government Digital Service) ran an experiment to determine how many of its users did not receive JavaScript-based enhancements, and it discovered that number to be 1.1 percent, or 1 in every 93 users.7, 8 For an ecommerce site like Amazon, that’s 1.75 million people a month, which is a huge number.9 But that’s not the interesting bit.

First, a little about GDS’s methodology. It ran the experiment on a high-traffic page that drew from a broad audience, so it was a live sample which was more representative of the true picture, meaning the numbers weren’t skewed by collecting information only from a subsection of its user base. The experiment itself boiled down to three images:

  • A baseline image included via an img element
  • An img contained within a noscript element
  • An image that would be loaded via JavaScript

The noscript element, if you are unfamiliar, is meant to encapsulate content you want displayed when JavaScript is unavailable. It provides a clean way to offer an alternative experience in “no JavaScript” scenarios. When JavaScript is available, the browser ignores the contents of the noscript element entirely.

With this setup in place, the expectation was that all users would get two images. Users who fell into the “no JavaScript” camp would receive images 1 and 2 (the contents of noscript are exposed only when JavaScript is not available or turned off). Users who could use JavaScript would get images 1 and 3.

What GDS hadn’t anticipated, however, was a third group: users who got image 1 but didn’t get either of the other images. In other words, they should have received the JavaScript enhancement (because noscript was not evaluated), but they didn’t (because the JavaScript injection didn’t happen). Perhaps most surprisingly, this was the group that accounted for the vast majority of the “no JavaScript” users—0.9 percent of the users (as compared to 0.2 percent who received image 2).

What could cause something like this to happen? Many things:

  • JavaScript errors introduced by the developers
  • JavaScript errors introduced by in-page third-party code (e.g., ads, sharing widgets, and the like)
  • JavaScript errors introduced by user-controlled browser add-ons
  • JavaScript being blocked by a browser add-on
  • JavaScript being blocked by a firewall or ISP (or modified, as in the earlier Comcast example)
  • A missing or incomplete JavaScript program because of network connectivity issues (the “train goes into a tunnel” scenario)
  • Delayed JavaScript download because of slow network download speed
  • A missing or incomplete JavaScript program because of a CDN outage
  • Not enough RAM to load and execute the JavaScript10
Screenshot of an error message reading, “HTTP Error 413: Request Entity Too Large. The page you requested could not be loaded. Please try loading a different page.”
A BlackBerry device attempting to browse to the Obama for America campaign site in 2012. It ran out of RAM trying to load 4.2MB of HTML, CSS, and JavaScript. Photo credit: Brad Frost

That’s a ton of potential issues that can affect whether a user gets your JavaScript-based experience. I’m not bringing them up to scare you off using JavaScript; I just want to make sure you realize how many factors can affect whether users get it. In truth, most users will get your enhancements. Just don’t put all your eggs in the JavaScript basket. Diversify the ways you deliver your content and experiences. It reduces risk and ensures your site will support the broadest number of users. It pays to hope for the best and plan for the worst.

Footnotes

This week’s sponsor: Padded Spaces

Posted by The fine folks at A List Apart |15 Dec 15 |

Relax smarter with your devices—wherever you are—with lap desks and bedside caddies from our sponsor, Padded Spaces.

Selecting Effective Workshop Tasks

Posted by The fine folks at A List Apart |10 Dec 15 |

Having defined goals and set an agenda for a workshop are a crucial first step. But what happens during the workshop is even more critical. Last time, we looked at how to define goals and attendees. This time we’ll look at the tasks and activities you choose to use, and how they’re determined by your stated goals. In the last post, these were our workshop goals:

At the end of this workshop:

  • attendees will be able to define, plan, and conduct UX research on a new product feature.
  • attendees will have decided on a set of research questions, so they can gather user feedback.
  • attendees will have demonstrated the power of UX research planning to the organization.

Let’s take a look at a few common types of tasks we can use to get there.

Brainstorming

The task of brainstorming simply asks participants to generate information. It’s not important exactly what they generate, as long as it’s on topic and there’s a lot of it. Using post-its, paper, and other tools for quick documentation are essential. One participant should be assigned as a scribe, so every idea is taken down. Participants should not be evaluating the worth of the ideas, just making a lot of them.

Sketching and ideation

Sketching and drawing activities ask participants to generate versions or concepts of a general idea. Sketching wireframes, tools, or content structures for example. This process is a bit more focused, as there is a concrete topic or interface structure everyone is riffing on.

Ranking and rating

Ranking is putting existing options or ideas in order from best to worst, or from one to five—just like the Olympics, where only one person can win gold, silver, or bronze. Rating is assigning a value to existing options. More than one option can have the same rating, like on Yelp, where lots of restaurants have three or four stars. These tasks force attendees to use discussion and debate to evaluate existing options and how they relate to each other.

Mapping

Mapping asks attendees to provide suggested actions based on certain constraints or criteria. It can mean mapping pathways through research questions, an interface, or even product delivery strategies. The key is that the obstacles to success are previously defined, and the attendees choose procedures that minimize those risks.

Connecting tasks and goals

These activities form a core set that you can rely on in any workshop. Regardless of the specific steps in the task, it needs to relate to your goal. Let’s look again at our example.

We want to define UX research on a new product feature. This means it’s at the beginning and all wide open. A brainstorming activity would work well here, as you want to uncover new ideas and interface concepts.

We also want to decide on a set of research questions. This could call first for ideation on a general question format, and then ranking or rating to choose research questions the team feels will be most effective.

Finally, in order to show the value of the workshop and research in general, we want to demonstrate the power of UX research internally. There are a few ways to connect this goal with the activities. First, we can brainstorm a short list of internal company objections to UI and product changes. Then, we map our research questions to those objections, in essence forcing our research to prove them right or wrong. We’re making a direct link between information we want to get, and how it will affect design changes.

Setting up and running tasks

Now that you have some ideas of tasks to run and have connected them to the goals, we can go over how to actually set it all up in the workshop.

  • Introduce the task. Say what you will be doing, and why. Restate the workshop goals, even if you don’t think you need to.
  • Set teams. Keep the energy focused by assigning teams and groups. If you have a set of particularly outspoken attendees, make sure they are in a group that is able to work with more vocal attendees. I often ask workshop groups to choose a topical name (ice-cream flavors, colors, etc.) as it fosters a group identity.
  • Assign a scribe. By asking one team member to document their task, you do two things: force the team to record their decisions, and create a shareable record for those who did not attend. (Remember how our third goal was to demonstrate the power of UX research?)
  • Set a time limit. Everyone loves a finish line. By telling people exactly how long they have to finish a task, you tell them that their time is important and that this will be a focused session.
  • Let them work. Stop talking and let the attendees complete the task. As the facilitator, you only need to intercede if people are confused or completely off topic.
  • Review. Once the time is up, call everyone back to the larger group and either solicit conclusions, or state them yourself. Even for a small groups, review is critical to making sure everyone is on the same page.

Workshops are hard work. A lot of that comes in the preparation, but carefully choosing tasks that match your stated goals is also key to success. Think carefully about what you want attendees to do, and then define the activities to achieve that. Explain what will be happening, as many times as necessary, and then step back and act as a facilitator, the person in charge, so they don’t need to worry about it. Each of these steps sets you up for success. But people are complex, and not every workshop goes according to the plans you set out. In the third installment of this series, we’ll look at some techniques for dealing with difficult attendees.

Design, White Lies & Ethics

Posted by The fine folks at A List Apart |08 Dec 15 |

Unless you’re a fan of dark or shady patterns, you probably struggle occasionally with integrity in your design practice: balancing stakeholder wishes against user needs, for example, or guiding users to hero paths while also granting them freedom to explore.

Recently, I worked on redesigning a mobile timebanking app, which helps neighbors share services and build supportive relationships. The public-good aspect of the project was appealing; the app’s values of community, trust, and support kept us focused on meeting users’ needs and being honest in our design. So of course we wanted to show users only information that was literally, concretely true. But what if a slight deviation from the truth would make users happier and more efficient in achieving their goals? What if fudging an interface helped reassure and speed the user along her way?

This isn’t an uncommon issue. You’ve probably run into “Close Door” buttons that don’t really close the elevator, or sneaky progress bars that fill at an arbitrary rate—these false affordances and placebo buttons are everywhere, and might make life seem a bit easier. But is this ethical design? And can we build a framework for working with false affordances and designing with integrity?

What’s the hubbub?

Timebanks are local, virtual exchanges in which neighbors can post requests for and offers of service in exchange for “timedollars,” a non-fungible alternative currency based on an hour of service. For example, if I do an hour of sewing for you, I can turn around and “spend” that one timedollar I earned on having someone mow my lawn for an hour. Granted, I can’t sew and don’t have a lawn, but you get the idea.

By enabling neighbors to connect and help each other, timebanks create community in what was just a location. Through mobile timebanking, people feel more connected with their neighbors and supported in their daily lives—in fact, that’s the value proposition that guided our project.

With teams recruited from PARC, Pennsylvania State University, and Carnegie Mellon University, our goal was to redesign the existing timebanking mobile app to be more usable and to connect users more easily through context-aware and matching technologies.

We started by evaluating issues with the existing app (mapping the IA, noting dead ends and redundancies, auditing the content) and analyzing the data on user actions that seemed most problematic. For instance, offers and requests for timebanking services were, in the existing app, placed in multilevel, hierarchical category lists—like Craigslist, but many layers deep.

Two screens showing long category lists for services. The third screen shows a pop-up message that reads, “No search result. Post a task in this category!”
Layers of hierarchy in the old app, requiring navigation and cognitive tasks. These categories were often empty.

Our analyses showed us two interesting things: first, that the service requested most often was a ride (such as to the doctor or for groceries; the user population was often older and less physically mobile); and second, that many postings by users to offer or request rides were abandoned at some point in the process.

We speculated that perhaps the timely nature of ride needs discouraged users from posting a request to a static list; perhaps drivers wouldn’t think of diving down into a static list to say, “Hey, I commute from near X to Y at about this time a few days a week—need a lift?” So we incorporated walk-throughs of the old app into semi-structured interviews we were already conducting in our research on peer-to-peer sharing motivations; participants’ actions and responses supported our speculations.

With that in mind, we proposed and started prototyping a new feature, TransportShare, at the top level of the app. We hoped that its presence on the app’s home screen would encourage use, and its similarity to popular ride-requesting apps would ease users into the experience.

We created a list of parameters the user would have to specify: starting/pickup point, ending/drop-off point, pickup time, “fudge factor” (how flexible this time is), one-way/roundtrip, and a text field for any special needs or considerations. Then we built prototypes, moving from sketches to low-fidelity mockups to higher-fidelity, interactive prototypes using Sketch and Invision.

The choices we make

Our ethical dilemma emerged as we designed the ride-request process. After the user specifies “Start” and “End” points for a ride, the app shows a summary screen with these points, the time of the ride, and a few options.

Screenshot of the ride request summary, showing a map with markers for “Start” and “End,” but no path between them.
Image credit: Dan Turner and Stephanie Snipes

Since you’re all crackerjack designers, you’ve noticed that there is no line connecting the Start and End points, the way there is in other apps that plot a route, such as Google or Apple Maps. This was intentional. Our user research showed that people offering rides were often running other errands or may need to make detours. Since we could not anticipate these needs, we could not guarantee a specific route; showing a route would be, to some high degree of probability, wrong. And—particularly in an app that hinged on community values and honesty—that felt deceptive.

Being truthful to the nth degree is the ethical choice, right? We wouldn’t want to display anything that might not be 100 percent accurate and deceive the user, right? Doing so would be bad, right? Right?

Oh, I was wrong. So, so wrong.

And lo, came…a test

At this point, we had solid research questions we wouldn’t have had at an earlier stage and clean, clickable prototypes in Invision we could present to participants. With no budget for testing, I found prospective participants at a Meetup designed to let people share and test their projects and selected the ones who had used some form of peer-to-peer app. (We are planning subsequent usability tests with more senior participants, specifically for readability and accessibility.)

I conducted the tests with one user at a time, first briefing them on the nature of timebanks (you’ve lived through that already), and setting the scenario that they are in need of a neighbor to drive them to a nearby location. They were given latitude in choosing if this would be a ride for now or later, and one-way or roundtrip. Thinking out loud was encouraged, of course.

As they stepped through the task, I measured both the time spent per screen (or subtask) and the emotional response (gauged by facial expression and tone of responses).

Task: Request Ride
Subtask Average Outlier Emotion
1: Set request time 11s 12s
2: Set one-way/round-trip 10s 17s
3: Pick start 7.5s 11s
4: Pick destination 6s 8s
5: Confirm request 9.5s 14s
6: Review request 14.8s 18s

The users tended to move easily through the entire task until they hit Subtask 6 (reviewing the request at the summary screen), and I saw there was a problem.

Participants visibly hesitated; they said things like “ummm…”; their fingers and eyes traced back and forth over the map, roughly between the tagged Start and End points. When I asked open-ended questions such as, “What are you seeing?” and “What did you expect to see?” the participants said they were expecting to see route lines between the Start and the End.

In debrief sessions, participants said they knew that any route they might have seen on the summary screen wouldn’t be the “real” route, that drivers may take different paths at their own discretion. But the lack of lines connecting the Start and End points disconcerted them and caused hesitation and unease.

Users were accustomed to seeing lines connecting the end points of their trip. I could see this in the time it took them to interact with that screen, in their faces, and in their think-alouds. Some thought they couldn’t complete the task or that the app wasn’t finished with its job; others reported a lower level of trust in the app. We’d made an assumption—grounded in honesty—about what users wanted to see, and discovered that it did not work for them.

The retesting

With these results in mind, I decided to run a smaller usability test with the same protocol and screens, with one change: a line connecting the Start and End points.

The same screenshot of the ride request summary, showing a map with markers for “Start” and “End,” this time with a path connecting them.
Image credit: Dan Turner and Stephanie Snipes

This time, the participants said they knew the drivers might not take that route, but it didn’t matter—route lines were what they expected to see. (Perhaps this is an indication they may not trust Google or Apple Maps pathfinding, but we’re not at that level of cynicism, not yet.)

Task: Request Ride
Subtask Average Outlier Emotion
1: Set request time 7.8s 13s
2: Set one-way/roundtrip 9.8s 11s
3: Pick start 6.5s 8s
4: Pick destination 5.3 6s
5: Confirm request 6.8s 8s
6: Review request 8s 9s

 
I graphed out the average user time per screen and averaged emotional response (observed: positive, negative, meh). I think it’s not unreasonable to see low time per interaction plus positive emotion as a good sign, while high time per interaction plus negative emotion as a sign that I needed to go back and look at a problem.

Two charts showing the time per interaction for the tested subtasks, with and without the route line on the map. The test using a route line were faster than those without.

The difference is just a line—a line participants are either explicitly or implicitly aware isn’t a true representation of reality. But the participants found the line comforting, to the point where, without it, usability took a serious hit.

Toward a heuristic

So when you get in an elevator, do you press the “Close Door” button? If so, what prompted you? Did you press it once and wait, or keep pressing until the door actually closed? How did that make you feel, the pressing, or even just the existence, of said button?

Of course, we now know that the “Close Door” button does exactly nothing. It’s a false affordance, or placebo button.

Which brings us back to the ethical question. Should I design in elements that do not technically mislead, but reassure and increase comfort and effectiveness of the product for the user? Does intention prevent this from being a dark pattern?

Remember, dark patterns are dark not because they aren’t effective—they’re very effective—but because they put the user in positions of acting against their own interests. Kim Goodwin speaks of well-designed services and products acting as considerate humans should act; perhaps sometimes a considerate human tells white lies (I’m not judging your relationships, by the way). But then again, sometimes white lies are a seed that turns into an intractable problem or a bad habit. Is there a way to build a framework so that we can judge when such a design decision is ethical, instead of just effective?

I originally wrote about this only to ask a question and open a conversation. As a result, the heuristics below are in the early stages. I welcome feedback and discussion.

  1. Match between affordance and real world. The affordance (false or placebo) should relate directly to the situation the user is in, rather than lead the user away to a new context.
  2. Provide positive emotional value. The designed affordance should reassure and increase comfort, not create anxiety. Lulling into a stupor is going too far, though.
  3. Provide relief from anxiety or tension. If the product cannot provide positive emotional value, the affordance should serve to reduce or resolve any additional anxiety.
  4. Increase the user’s effectiveness. The affordance should help improve efficiency by reducing steps, distractions, and confusion.
  5. Provide actionable intelligence. The affordance should help the user know what is going on and where to go next.
  6. Add context. The affordance should offer more signal, not introduce noise.
  7. Move the user toward their desired outcome. The affordance should help the user make an informed decision, process data, or otherwise proceed towards their goal. Note that business goals are not the same as user goals.
  8. Resolve potential conflict. An affordance should help the user decide between choices that might otherwise be confusing or misleading.

These are not mutually exclusive, nor are they a checklist. Checking off the entire list won’t guarantee that all of your ethical obligations are met, but I hope that meeting most or all of them will weed out design that lacks integrity.

One unresolved question I’d like to raise for debate is the representation of the false affordance or placebo. The “Close Door” button wouldn’t work if labeled “This Doesn’t Close the Door but Press it Anyway,” but in my case we do want to make the user aware that the route line is not the route the ride will necessarily take. How to balance this? When does it become deception?

In addition, I can recommend Dan Lockton’s Design with Intent toolkit, licensed under the Creative Commons 3.0 standard. And Cennydd Bowles has written and spoken on the larger issues of ethical design; if this is a topic of interest (and indeed, you’ve read many words on the topic to get to this point), it’s worth diving into his site.

I hope to keep thinking about and refining these heuristics with additional feedback from designers like you. Together, let’s build tools to help us design with integrity.