Shady Patterns
The company wants you to share. You don’t want to. When a UX design choice drives the company agenda over the user’s agenda.
This week an internationally renowned researcher at a major technology foundry and I spent an hour with a shared screen, trying to puzzle out the UI and interaction mysteries of Google Drive. It wasn’t pretty — I wish we’d recorded the video and audio to share with you, though the audio content would frequently be NSFW.
But today I want to talk about a very specific interaction in Google Drive, one that is probably fundamental to why people use Drive: the sharing interaction. There’s a lot of complicated magic in the infrastructure to make this work, and it works, and I celebrate that, but the current interaction design potentially traps users, puts them in endless loops, and veers awfully close to dark patterns. Let’s go through the interaction itself, see where the problems arise, and think about why this user-unfriendly state of things may have come to be and how good research practices could help.
First, let’s express respect for the initial step of the process. Every page has a big button on the upper right, labeled “Share”. I don’t even need to put a screen shot here, which is a testimony to the design. You’ve got it: a big, bright button, clearly labeled, prominent. Aces.
And then my troubles begin.
I started, from my frustration at one point, noticing how this was a pattern. Patterns in design are common frameworks that people can build upon; some are good, some are counterproductive (called antipatterns), some are intentionally deceptive, though effective (called dark patterns). What I was seeing was a pattern that was problematic for users, but probably not due to evil intent on the part of the designers and developers.
We can all these shady patterns.
The Troubles
It can’t be that uncommon the case that someone clicks on “Share”, then realizes a few things. One might be that you’re not quite ready to share the document yet (“Oh, crap, I forgot something”, etc.). Another might be that you’ve forgotten exactly with whom you should be sharing the document — or, whom you should most certainly not be sharing the document — and you need to go back and look up email addresses or other things. Or you may have clicked the button accidentally. In any of these cases, and in many others, you’d want to cancel the process you’ve just begun.
Basically, you’re saying, “Hey, Google Drive, we’ll get to this later, okay? It’s not you, it’s me, no harm no foul. We cool with that?”
No, Google Drive is not cool with that.
Now, this overlay is facing the challenges of being a hybrid. It’s not really an application, though it has application-like buttons. It’s technically part of a web page, but it doesn’t have controls (chrome, etc.) like a web page would have. So the visuals lead me to treat it like a modal dialog in an application, which limits me to pushing one of the buttons or entering text I don’t want to enter. (Note: just clicking outside the overlay did not dismiss it; it was this or closing the tab and starting over.)
Sidebar: On Shady Patterns
A digression. I’d like to point out how the design here is blatantly trying to manipulate (or “Nudge” or “Hook”) the user. It’s the way animals are wired; our eyes will go to and stay on the colored item by default, to the point we may not see the not-a-button-but-functions-as-one “Advanced”. Google is trying to herd you. This isn’t always a bad thing — a key part of good design is helping users find the easiest path to get done what they need to do — but this is to the point of depreciating options for the user.
Google got in big trouble with an only slightly worse case when it rolled out the late-but-not-lamented Buzz. When users went to their Gmail web page, they were presented with the message Buzz was here, and an option to “Sweet! Check out Buzz” or “Nah, go to my inbox”. (We’ll leave aside the automatic opt-in and inability to opt out.)
This is placing punitive work onto the user: visual recognition, extra reading (not much, but still), cognitive load. Doing this doesn’t remove options for the user, but certainly makes certain options cost more, and doing this means you’re driving your needs and agenda, not the user’s. It’s not quite a dark pattern, as it doesn’t drive people for strictly nefarious ends, but it’s… more opaque. It’s a shady pattern.
Back To The Point
I understand the designers may be trying to avoid the old Microsoft Windows pattern of “OK/Cancel/Apply” (seriously, that was never not confusing), but here I was, wanting to back out of an action and not seeing how to.
Also of note is that you can’t see if anyone is currently sharing the document or if it is shared already from this overlay. I guess it’s okay to send people duplicate invites?
(Update: With trepidation, I tried it again and clicked “Done”. What would that do? Would it share this not-for-sharing thing? No, apparently “Done” serves as both “Do this action” and “Do not do an action”. Of course it does.)
So I clicked the “you don’t want to click there” word “Advanced”.
Pretty much the same conundrum. This does show I am the owner of the document (okay, cool), and that it is private. Okay, that’s what I want. I’ve now spent minutes and brain cycles and clicks to know what should be — though that there’s already a link for this document could worry some people (not everyone thinks all information should be free). But still, how do I cancel? I can’t click outside the overlay, there’s no “x” in the overlay, there’s no “Cancel”.
So I can do nothing but hit “Done”, which, see above. That’s not the same action as “Cancel”. I finally ended up doing what I wanted to do — not do anything — but following a rabbit hole to its end, and there’s no confirmation outside of stepping through the whole process again that what I’ve done did what I wanted it to do.
Just To Complicate Matters
The smart cookie @aquazie pointed out to me that you can start typing in an email address makes a “Cancel” button appear. I appreciate her insight, but two things make this not a good solution from a user’s standpoint.
First, this is totally hidden. If you don’t want to share, why would you start entering in an email address to share with?
Second, this means to halt an action you don’t want to do, you have to move forward on that action you don’t want to do.
Third, I guess this means Google does, after all, know how to make a “Cancel” button. As pointed out by Mike Monteiro’s in his must-see talk, “How Designers Destroyed the World”, everything you put out into the world is a choice. Someone made a choice not to put a “Cancel” button into this interaction, and someone made the choice to put a “Cancel” button in this interaction only after the user moves forward with the action they want to stop.
So, basically, the quickest, easiest, and most sure action for the user is to close the browser tab. Or quit the browser. Or take off to orbit.
What Is To Be Done?
Sure, design is hard. I know that personally, but don’t take my word, go read Chris Noessel’s great “7 Things I Wish Everyone Knew About Interaction Design”, especially Point #3. And I’m being conscious about punching up, not down; I don’t want to point fingers at individuals, but at a company with virtually unlimited resources and talent.
So, why are there such glaring errors in a product millions use and often struggle with (I can share with you research papers on this topic)? How could they, and you, work to avoid things like this that are so easy to pick apart by some guy on Medium?
Actually, let’s step back in time, in the process, and as a more fundamental question: How do you learn what you don’t know? How do you learn to see things?
I say this because these are unfortunately common errors produced by companies that do a few things a certain way. I have no behind-the-scenes knowledge, to be clear (no hunting for leakers!), but so much of this is familiar as to make this a fairly educated guess, and a cautionary tale for your project or company.
Common Problem 1: Serving Your Own Dogfood
Some companies create and test new features or products only within the company’s employee pool, or only with that plus friends and family. This does a few potentially nasty things.
First, these are highly motivated populations. You’ll have users who are highly motivated to tell you the product is good, you’re a good person, and you should move full steam ahead on almost anything you put in front of them. They’ll trust you and are more likely to assume any interaction issues are with them, or that you’ll be fixing them awesomely. So your data will be skewed and corrupted.
Second, these populations may already be familiar with your product, maybe to an extreme degree. They already know what you think the goal of the product is, so you may completely miss low-hanging issues that only inexperienced or new users will run into. For example, there’s a turn arrow in the left pane of the Google Drive web interface; it turns when you click it, but doesn’t reveal anything (or turn back if you click it again) if you don’t have any folders in your Drive. Experienced users will see the arrow disclose content, but if you only test with experienced users, you’ll never see this baffling UI bug (this video is from before the recent visual makeover, but the control behavior remains).
Common Problem 2: User Research != QA
Some companies structure usability testing as a walkthrough. That is, they don’t give users tasks and sit back and observe, but walk users through a scripted “click here, then do that” process. This is QA, or bug testing. You can dress it up with asking the user to think out loud, or asking them if they expected X to happen when they pressed Y, but you will never discover what you don’t already know (or, rather, think) about what users need, understand, or feel. This is basically upping the stakes of the gamble you’ve made with your design decisions, not testing them to failure and revising them.
Common Problem 3: You Are Not The Use Case
This builds on the two points above.
A related problem is ideating features through a conference room full of product managers. Without going back to actual (non-employee, qualitative) user research, negotiating “what feature can you think up to make in six weeks” becomes an exercise in building things centered on mental models users may have no concept of.
So
Again, I do not have full knowledge of how they do things, their processes, and so on. I do have some exposure and insight, though some of it is “I can’t tell you all of it” or second-hand, which always suffers from people speaking outside their area of expertise. And I’m sure they’re all really really nice people.
But we do know, and there are documented processes in place, that help thousands of companies and independent projects avoid these pitfalls every month, if not day. They might not even cost extra money or time; see Erika Hall’s excellent “Just Enough Research” and Steve Krug’s work for examples (some companies, of course, may require long lists of requirements, and I’m sure it works well for them).
Treat every design decision as an hypothesis. As with science, test each hypothesis against the real world.
As to that last, remember that “the real world” means “people who are not you, your coworkers, your family”. You can do this without divulging trade secrets or “your brilliant startup vision” (really, how many people are going to care?).
Don’t get only people who know your product well. Find people who have real tasks your product could, if it works, help them accomplish.
Observe people facing actual tasks they need to accomplish in real life. Where do they struggle, or get frustrated? That’s an awesome window for building something people will want.
Don’t be this guy. He’s sweet, and means well, but he’s been up for a very, very long time and is making poor decisions.
tl;dr
I can’t create or recommend a whole new research and design workflow for a global company (not like I’m privy to all they do, or that they’d listen to me), but the point is, I shouldn’t have to. There are basic principles — if you know how it works, you are not the user; test to break, not to confirm; discover user needs through observation rather than ask them to select from a menu; find people who don’t have a vested interest — that correlate strongly to better products, with little cost. Don’t test to confirm your assumptions, test to confound them. And use beginner’s mind, and empathy. Observe, don’t prompt. The rest, as they say, should be commentary.
Have you run across this shady pattern? Do you have others? How do your work processes end up producing or preventing them?
