Some rights reserved by matt.forestpath

Age Neutral Verification

This is the biggest area of impact on the interface. If you have a site which offers kid-attractive content, you’ll need to know if they’re above thirteen before making an account or storing personally identifiable information.

The problem is that you can’t actually ask that in a way that indicates that thirteen is the break point. This is what “age-neutral verification” means. If only it was as simple as a checkbox that they tick which says “I am over 13 years of age.” Nuuuh-uh, not so fast, cowboy. That’s not legal. (See FAQ #39 of the COPPA statute.)

If the user fails the age-neutral test, you must fail in a obtuse way that doesn’t indicate to them that the age check was the reason. This defies all good UX principles around writing clear error message that tell people what is actually going on. As much as this boils my cockles, it is the law. But it doesn’t end there. You must prevent them from turning around trying again. Finally, your company must delete all info from any source that you have about that user.

Options

Most providers, including the screenshot from Facebook, are asking for a birth date, as that’s the example solution given in the law. Facebook’s popup delicately explains “Providing your birthday helps make sure you get the right Facebook experience for your age. You can choose to hide this info from your timeline later if you want. For more details, please visit our Data Use Policy.”

Another option is to simplify down to only asking for the birth year. The drawback to this method is that you need to toss out all of the people who turned thirteen that calendar year who would otherwise be able to use your site.

Lastly, my favorite option is the radio buttons with age ranges approach. This example is from the Born This Way Foundation. It’s the best UX but the riskiest approach from a legal standpoint.

Tricks up our sleeve

Since Gmail, Hotmail, Yahoo all are under the same restrictions, they have already asked this question of users. A feature we’ve been talking about for Persona is to flag such users’ accounts as good to go. As we roll this future feature out, this will mean that we can give sites both a verified email address and a verified age-neutral check.  Again, check with your lawyers to see what sort of documentation you’ll need to keep around to prove that these third parties were indeed performing the check.

Designing for COPPA is a post from: Crystal Beasley, UX Designer at Mozilla

Your product is not so different from that bottle of wine. A good visual design will enhance the experience of using your product. The visual design will indicate what sort of this this is, who the product is for, how much it costs, etc. Note that it indicates this whether or not you want it to. Serving Châteauneuf du Pape in a paper cup may not be an intentional choice, it will affect the experience of drinking it nonetheless.

This doesn’t mean your visual design should be fancy or slick or nice. What’s right for wine isn’t right for everything. Beer doesn’t taste better out of a wine glass. You drink Miller straight out of the longneck. Stella Artois has made a whole advertising campaign of its signature glass. Churchkey is reviving a line of working man’s beer in 1940′s cans. Miller is for working men, Stella is for working men who wish they were hipsters, Churchkey is for hipsters who wish they were working men.

It’s all about knowing who audience is. Your visual design should say to them “this is for me.”

Originally posted on The Heretic Newsletter

UX of a Wine Glass is a post from: Crystal Beasley, UX Designer at Mozilla

There’s a common perception that people don’t care about privacy. This is sort of right. Our research shows that most users are unaware of how extensively they’re being tracked by advertisers across the websites they visit. Even those that do know are unsure of what to do about it. They know there’s a horrible legalese privacy policy hanging out somewhere. They know they should read it. They don’t. They know they should use different passwords on each site. They don’t.

Our research found a fatalistic attitude towards privacy and security. We heard everything from “No one wants my identity anyway. There’s no money in my bank account.*” to “If a hacker wanted to get in, I’m sure they could. I wouldn’t even know where to begin to defend myself.” *Note: that’s not how identity theft works.

The kind of privacy they care about is from the people closest to them that could physically pick up their phone or computer. This is why people clear browser history and explicitly log out of sites. It’s not the hacker they’re worried about, it’s their visiting mother-in-law or kid sister getting a look at their email or being able to vandalize their Facebook wall. Unlike the big “P” privacy, this consequences of this threat are immediate and visceral. The potential costs to their reputation are perceived to be higher than anything a hacker could or would do.

Further, we found that the existing password manager is under serving the majority of our users. Many people aren’t having the browser save their passwords because it leaves their account wide open to anyone who has physical access to their device. It doesn’t defend against the primary threat they’re worried about. They are left with no tools to help.

It’s little wonder we see such bad statistics on password reuse. We’ve told people not reuse passwords, but it’s a cognitive impossibility to comply. It’s like saying you could avoid drowning by walking on water. Worse, even, is that everyone I’ve interviewed apologies for not having a good enough memory. We’ve done no service to our users by making them feel stupid or inadequate.

The Persona team has been busy prototyping better tools that address this set of user needs. Follow us on twitter at @mozillapersona to hear about these experiments and more.

Check out the research that underpins the Persona team:

Identity and the Internet: A study
Some attitudes on Facebook privacy
Privacy and social media: a small German study

Photo credit: Creative Commons license by Valeria Melissia Rosalez

People DO Care About Little “p” Privacy is a post from: Crystal Beasley, UX Designer at Mozilla

===UPDATE 11/27===

I neglected to specify that of course, I’m not the *only* person interviewing developers. That would just be ludicrous. The majority of the people interviewing any given candidate will share the same skillset. Then a few others from the project team will ensure culture fit. Mozilla typically does two or three phone screens and approximately six in-person interviews.

How to Interview a Developer is a post from: Crystal Beasley, UX Designer at Mozilla

In an exasperated voice “Why is it so hard to get designers in open source.” I hear this all the time. Well firstly, it depends on what sorts of skills you’re talking about. Just like in code, there are small tactical problems that are good first bugs. Even the simplest issue requires a knowledge of the design patterns that the site employs.

Many of the bugs, however, require a deep understanding of why the product exists in the marketplace and a thorough understanding of the research that underpins the project. These strategic questions are analogous to what a software architect would do. I was on the Persona project full time for three months before I felt confident making significant choices about UX.

Open source generally isn’t welcoming to designers. A shock, I know! There are many reasons for this.

1. In general, coders don’t know what to expect from us. My conception of what I do often bears little resemblance to what coders think I do. When I join a team that’s never worked closely with a UX designer, I have to educate them. Otherwise, there’s a gap of misunderstanding that leads to stress and unhappiness. We get up in your business and ask you to change things that you don’t want to change because
   • It seems trivial and unimportant.
   • Conversely, it’s too hard.
   • You don’t agree.
2. Ultimately, we’re beholden to convince a dev to implement our bug, likely because we don’t code or even if we do it’s not the best use of our time to be implementing. (If you want to pick a fight, insult a designer by asking why we don’t “just learn to code.”) We’re starting from a disadvantaged position. In version control systems such as github, code talks and designers don’t speak the language.
3. Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code.
4. Github issues and their parallels track problems at a level of granularity that’s useful for devs. The UX problems that constitute my work are of a much larger granularity. When I add such a strategic issues to the tracker, it makes devs uncomfortable. There’s nothing actionable here. There’s nothing to implement. My job is to think through big issues. By the time I’ve converted it into something a dev would recognize as a bug, my work is done. Thus, representing the work of a designer requires a shift in culture of the dev team so that they won’t close down my issues.
5. My UX bugs are all tracked publicly in Persona’s github and yet I can count on one hand the number of UX volunteers that have contributed to the project. It’s not that there aren’t any good first bugs, its that there is a shortage of UX/UI designers in the market. Yes, I’m sure Mozilla could do a better job of getting designers to volunteer. We know it and we’re working on it.

The solutions to all these problems lie in communication and building a trusted relationship. It’s a higher barrier for designers that takes time to overcome. I’ve found all of my team to be receptive when I’ve taken the time to explain the principles that guide my decisions. I work with an awesome group of super smart folks! They just need to know I’ve got this handled. The longer we work together, the more shorthanded my explanations can be. Designers start by renovating small stuff and move up to innovating as they build their reputation. As the paid UX designers in Mozilla change the culture, it will become more welcoming because we will have laid the groundwork. Recommended reading: How to socialize UX into your project and the post I wrote a year ago about design leadership.

And yes, we are actively hiring. It’s an amazing place to work. If there’s a specific position you’re interested in, send a holler to me directly at crystal@mozilla.com.

Code Talks and Designers Don’t Speak the Language is a post from: Crystal Beasley, UX Designer at Mozilla

I’ve been thinking about log-in a lot lately. Yesterday it occurred to me to see what sites across the web were doing about it. Do they require log-in? Sure, almost all of these have user accounts, but can you use the core functionality of the site without one? The results were overwhelming, 87 of the top 100 US sites by traffic are useful without a log-in.

Let’s talk about the outliers. What can be so valuable that they can put a locked door in front of the users?

Banking is not a surprise. They don’t hand off their log-in to a third party like Facebook Connect because security and privacy are the paramount concern. Banks already have a brick-and-mortar relationship with the customer that they extend in the online space.

All of the site below started as online-only concerns, so they didn’t have that advantage.

Facebook, Twitter and a pair of dating sites make up the next category. These things are inextricably tied to your identity. It makes sense that you can’t participate in these sites without logging in, as it would destroy the whole fabric of what they are.

In the media category we have Netflix and Pandora. I should note that Hulu is in the no log-in required club, and they are challenging Netflix’s business model. All of Pandora’s direct competitors seem to require log-in. All I can surmise is, people really want this content and DRM is a bitch.

Let’s back up and talk about Twitter for one more second. I put Twitter in the category of log-in required, but it’s not that black and white. The majority of users reading Twitter do have an account, but you actually can get started with the site by following celebrities. They increased their sign-ups by 29% when they redesigned their sign-up forms with principles of gradual engagement.

Lastly, the sole appearance in the product category is Groupon. Whoa. People loves dem deals. Their disruptive idea (requiring log-in) plus an engagement model that used emails as the primary interaction created a whole new business model. You can debate whether their $12 billion valuation is correct to the nearest order of magnitude, but it’s surely a signal that they did something interesting.

Twitter flipped the paradigm on Facebook’s walled garden by replacing the private friend relationship with a public follow one. Hulu upset Netflix by dropping required login. Despite what the title of this post may imply, I don’t think the future of the web is for everyone to go log-in free. If your competitors are doing it one way, see what’s possible by reversing it. Don’t take log-in for granted. It’s crucial that you get it right.

Further reading: Luke Williams on Disruptive Thinking

Login REQUIRED

Login NOT required

9 of 10 Sites Agree Requiring Log-in is Whack is a post from: Crystal Beasley, UX Designer at Mozilla

As part of my work on the Identity project at Mozilla, I’ve been taking a look into how the average person thinks about single sign-on. It’s a complex system, so not surprisingly, it’s most often misunderstood at a fundamental level.

I ran an unmoderated user test with usertesting.com with five users. Their task was to go to Buyosphere, a site that implements Facebook Connect, create an account, then log out. Then I asked them a series of questions. All five indicated they had used Facebook to log into sites before.

“When you log out of Buyosphere, do you think it logs you out of Facebook also? Why or why not and how would you tell for sure?” Incorrect answers are red and bold.

• User 1) “i believe that once i log out of buyosphere, i am also logged out of facebook. once i am logged out i cannot see any more information regarding my account after logging out.”
• User 2) “I think it does log me out because it gave me connect with Facebook, thus it mean it is not recognizing that I have a Facebook account. I’d tell if I am or not by opening up Facebook in a new tab and seeing if it is automatically logged in or not.”
• User 3) “No, I told facebook to remember me. I would open my facebook page in a different browser window? I don’t normally tell it to log me out, so that is only a guess.”
• User 4) “Yes. I do not see a separate window for my facebook site so I would assume that Buyosphere would have set it up to log me out when I’m done on their site. I think I can check to see if I’m logged out by opening facebook and seeing if the login boxes come up or if it takes me straight to my FB page. I will try it right now….I was wrong it didn’t log me out. I am surprised by that. That makes the process of logging off take longer if I have to log out of this site and then go to FB to log out of that site separately.”
• User 5) “I don’t think it would log me out. I have used other sites through facebook and usually the log in and log outs are separate. I can tell for sure by checking my facebook page which I just did and I am logged in.”

The goal of this research was to determine if users had a mental model that would allow them to correctly log out of a single sign-on system in places where there are security concerns like a shared computer or public terminal. The answer is no. Disclaimer: Do not be tempted to extrapolate that this means 60% of people would get this question wrong. This is qualitative research, not quantitative and should not be regarded as having statistical significance.

The last little gut-wrenching nugget comes from the last 20 seconds of one test. Watch and weep.

You caught it, right? She believes she could use her Facebook user and password to log into this site. *sigh* It’s horrifying how easily a bad actor could build a honeypot to collect Facebook credentials.

In addition to confusion over when/where/how to log-in and log-out, we know that sites have big percentages of users with multiple accounts. This video clearly illustrates how that can happen.

What are sites to do? I don’t think there is a good answer. As much as your business case allows, use only one identity provider. If you’re using Facebook Connect, don’t have a standard log-in. Too often, two log-in systems are less than the sum of their parts. LukeW’s article details experiments to mitigate these problems. Some of them have security concerns that wouldn’t fly with many sites. I’m not confident any of them work massively better than only supporting one way of logging in. However, many site will feel it necessary to have a standard log-in plus Facebook Connect. Clearly more thinking and testing needs to be done in this direction.

Of course, my biased view is that we can build better solutions for single sign-on.

How People *Think* Facebook Connect Log‑in and Log‑out Work is a post from: Crystal Beasley, UX Designer at Mozilla

Making simple, elegant solutions is HARD and often invisible. These are some of the most common things I hear when heading for a bad UX decision.

And before any veteran designers go ripping me a new one, these are rules of thumb intended for a 101 audience. They do not apply in every circumstance. However, you must know the rules to know when to break them, and that requires varsity-level skills.

1. “I’ve got this really great idea for a site.”

I’ve seen entire sites built to do something no one wants, and it’s more common than you would believe. How, you may ask, does this happen? You start with a solution and then go find a problem it solves as justification. We get ourselves into this situation because of a lack of research into where peoples’ needs and frustrations lie.

2. “I’ve got this really great idea for a feature.”

Developing new features is most often at odds with making an interface that’s easy to use. Features have a technical cost, but the UX cost is much higher. Make the happy path supremely happy by rigorously pruning off features from the UI that are wanted by only 2% of users. For features 20% of users will need, it’s ok to make that flow a bit more lengthy. You’re optimizing for the sweet spot of tasks 80% of users will need. I’m sure *you* have never been guilty of having a pet feature. I’m sure everyone will want to use it. Avoid long fights on where in the 80/20/2 scheme the feature falls by employing a/b metrics and user testing. Otherwise, the loudest or HIPO (highest paid opinion) in the room will likely prevail.

3. “Let’s put a sentence under the button to explain.”

You can’t document your way out of a confusing UI. Remove half the words. Then remove another half. Kinks in the UI can usually be resolved by the next bullet point…

4. “What we’re doing here is so novel.”

Reuse existing paradigms. People don’t want to read unless required, so use patterns to make reading mostly unnecessary. The user must recognize which mental model is in use or else be able to quickly and correctly learn the model. Breaking a paradigm is serious, varsity-level stuff. Find someone who’s trained if you are convinced you need a novel pattern.

5. “I think the button should be on the right.”

It’s not about opinion. Here’s how you make design decisions. Step 1. Adhere to patterns in your designs. Ahem, we just covered that. Step 2. Test. Users are weirder and more interesting than you can imagine. Step 3. Go back to step 1 and refine with what your learned. Even pros (especially pros) test their designs. You can’t afford not to validate your assumptions. You MUST test with real people to escape your biases. Additionally, when you make a decision independent of data, you have a process that is vulnerable to organizational politics and maneuverings.

6. “We don’t want the user to do XYZ thing they want to do … Let’s make that path really arduous.”

If your users want to do something you don’t want, it’s time to closely examine why. Fix the root cause. Chances are this is damn hard or you would’ve already done it. Still, there’s no better solution. Fighting your users is never a winning strategy.

7. “Maybe we need a FAQ.”

Only put the information where/when the users will need to use it. In a flow, there should be a clear path for the user to take (either a CTA or a clear choice). The most important information on each page should be OBVIOUS. Think of every page a user would likely land on from search as a mini-homepage. Your site should have a purpose, and it should be clear to the user. Users should have enough context to know where they are within the structure of the site and what other related info is available.

8. “Can’t we just pop up a confirm dialog?”

Confirm dialogs are of the devil. Prevent errors. Support undo. Again, don’t document that something is dangerous if you can fix the danger. Instead of putting a sign up saying there’s a giant hole in the road, repair the hole or let the driver hit the magic button to fix the muffler that fell off.

9. “Let’s split this flow up into different steps so it seems smaller.”

Don’t lie to users. Set expectations appropriately. Wizards are usually not the answer. Make the flow smaller. Every field you ask from users reduces conversions. Also related “This thing is taking a long time, can we add a spinner?”
No, make it faster.

10. “Make it red so it will really stand out.”

There comes a time in every designer’s life where they have to learn about the birds and bees. Red is a very wonderful color in the palette. It’s saved for that special person, i.e. error text, critical system warnings. If you must use red because you’re a fire department or Ohio State University, use yellow for errors.

These things don’t get talked about nearly enough.

11. Navigation

Your site should be organized in the way your users think about it. If your nav mirrors your org chart, you didn’t make the decision with data. I guarantee users don’t think of your product the way you do. To escape your own bias, you’ll need metrics and analytics to understand what the most common tasks your users are trying to solve. Then, card sorts and tree testing can distill that into the correct, mutually-exclusive taxonomy with jargon-free labels.

12. Copy

Did I say jargon-free? To know what your users call things, you have to ask them. Those card sorts sound stupid easy, right? So go do it. Jakob Nielsen has great guidelines for writing for the web. In short, keep it short. Users scan in a F shape, so keep keywords toward the beginning of the line and especially in the headers. This is no place for cutesy language.

13. Login

Do you really need login or can you do the same thing with a cookie? Delay it until absolutely necessary even if so. Give users a way to gradually engage with your site. They won’t make an account until they understand the value. A registered user is like gold, so treat them as such. Nothing will destroy your engagement of returning users faster than forgetting who they are, so persist user sessions FOREVER. Go assign yourself that bug to make links from your emails automatically log them in.

Further reading

Steve Krug, Don’t Make Me Think

uxmyths

It’s Complex To Make A Product Simple

Photo credit Some rights reserved by ahp00k

13 Signs Your Site Needs a UX Exorcism is a post from: Crystal Beasley, UX Designer at Mozilla

I’m using this to improve the password field for Mozilla’s identity project. Join the discussion in comments here or on the github issue.

Simple: Getting users to pick strong, memorable passwords is a post from: Crystal Beasley, UX Designer at Mozilla

Yes, this is a post about Mozilla, but you can generalize to any open-source software project. At every conference I hear the same refrain, “Why is design so hard in open source?” It’s so hard because *drumroll please* it’s not made a priority. None of the top decision-makers are designers. Period. The End. You can stop reading.

Without someone in the c-level or steering committee with a design background to speak on users’ behalf, Mozilla is missing out. Engineers and business people see entirely different challenges. Without all sides (technical needs, business needs, user needs), we have a giant blind spot.

Chief of Experience? Never heard of one.

If everyone jumped off the bridge, would you do it too? It’s true, there aren’t many tech companies, especially open-source ones that have a design representative at the executive level. Google, Microsoft, Opera, Facebook, Intel, Amazon and even Adobe lack it. There are some surprising companies that do. Oracle has a Chief Evangelist of User Experience. Flipboard has a Head of Design. Nokia and Yahoo have a Senior VP of Design. You might’ve heard of the most notable SVP of Design, Johnny Ive of Apple. You’ll note titles of this position haven’t settled down, not surprising given the short time the discipline has been around.

There’s an opportunity for Mozilla to be the first big open-source tech company to deeply bake design DNA into the process. Gary (CEO) has been exalting us to to produce a kick-ass product. UX and UR are a source of innovation. Further, prioritizing around user needs is essential to making an excellent product.

One bit I didn’t expect in my survey was that the Chief of Design is a well-established role in car companies. Tesla, BMW, Volvo… they all have one. It’s curious to me because car manufacturers are entrenched in technical, mechanical requirements as well. Seems as though they’ve figured out that it takes more than the feature list and specifications to sell cars to people.

Get to the point

1. UX is an objective discipline, not something based on feelings about which shade of blue is prettier.
2. It should be an organizational priority that blocks projects from launching in the same way the infrasec does.
3. UX is vital part of every project. We shouldn’t DO a project unless a trained interaction designer can ensure user needs are met. Until UX is included from the very beginning, before requirements are written, it will be chasing after product and engineering.

So what do we DO?

1. We need someone with an interaction design background at the c-level and/or steering committee.
2. Hire UX at a sane number. The ratio in my group is 30:1. It should be around 4:1.
3. Until we can do that, hire contractors to pick up the slack.

[Video: the ROI of User Experience]

[Post: We Tried to Warn You, Socializing UX into organizations]

===== UPDATE 12/6/2012 =====

It’s the end of the year. Time for a progress report. Just a few months after I wrote this we reorganized user experience designers and researchers into their own functional team. I was immensely happy for one of our own, Jinghua Zhang, to be promoted as Director of User Experience. In our org chart, that makes her a level 5. VP and C-levels are as high as it goes at level 6. I’m very proud to see Mozilla’s progress this year. Onward!

Chief eXperience Officer at Mozilla in 2012 is a post from: Crystal Beasley, UX Designer at Mozilla