Most successful applications do a good job of onboarding users to teach them how the basics work. After that, good applications also make it easy to learn more advanced features simply through repeated use. You might make a wrong turn once, but if the application corrects your course, you never make that mistake again.

But sometimes there are features that fall between the cracks of onboarding and self-learning. It usually happens when there is some unique behavior in the app that is not only presumed to be commonly known by all users in the community, but is also small enough so that it’s not worth making a big deal out of during new user onboarding.

I recently thought of two such examples that I wanted to share, along with some suggestions for addressing the issue.

Twitter mentions

First, there is the issue of Twitter mentions. I still see people who I know have been on Twitter for years, who don’t know that if they start a tweet with ”@”, not all their followers will see it. This information is buried deep in Twitter’s Help section, where I’m guessing very few people venture to. From Types of Tweets and Where They Appear:

Users will see @replies in their Home timeline if they are following both the sender and recipient of the update. Otherwise, they won’t see the @reply unless they visit the sender’s Profile page. 

This is fairly clear, but if you don’t think about this as an issue, you won’t know to ask the question, so it’s not information you’re likely to seek out.

Instagram replies

Second, there is replying to comments in Instagram, which I’m sure trips up quite a few people. If you comment on one of my photos in Instagram, I will get a notification. But if I respond to your comment without including your @username, you won’t get a notification. This is not how it works on Facebook, where you get notified of five comments after the one you posted1. Instagram does have an easy way to reply to people with their usernames, but it’s a slide gesture I discovered by accident:

So the easiest way to reply to someone is to slide from left to right on their comment, then tap on the arrow. Or you can start the comment with an @, which will then autocomplete the name as you type. But it’s not something they tell you about explicitly. It’s also, again, not information most people will seek out actively, since they’re getting notifications for each comment on their own photos, so why worry?

A proposal

My proposed solution for this type of situation is fairly simple. In the case of features that don’t behave as people expect them to, show a lightbox-type message to explain how it works just one time — the first time they perform the action. For example, the first time a user sends a tweet that starts with an @, show a message to explain who will see it. And the first time a user comments on one of their own photos in Instagram, show a message that explains when people get app notifications.

These are small but important details, especially for social services where understanding exactly what happens when you hit “Post” is essential to the enjoyment of the app.

Related post from the Elezea archive: Best practices for user onboarding on mobile touchscreen applications.

---

1. I think it’s five. But I’m not 100% sure. Come to think of it, it’s probably a good example of this type of confusing behavior as well. ↩

I spent the past two days running usability tests on websites that sell financial products like life cover, funeral policies, and annuities. The target market is lower-income users who access the Internet at least once a day on a desktop at home or work, or on their phones. They are, for the most part, tech literate, and very used to finding their way around the Internet. I wanted to document some of the more general findings while we’re knee-deep in analysis and everything is still fresh.

What follows is a list of interaction design elements that I believe should never, ever be used on a website. They might seem like small issues, but I’ve seen time and again how small things add up, and eventually end with frustrated users who abandon a site altogether. Also, if you’re tempted to think that your users are different and somehow more sophisticated than the ones we tested, please consider the growing digital usability divide.

So, here it is — an incomplete, top-of-mind list of usability sins your website should never commit, based on data gathered through in-person usability testing:

• Don’t use an asterisk (*) to mark required form fields — especially if there is no explanation of what the asterisk means. Most users do not understand this at all. Instead, state that all fields are required unless indicated otherwise, and then mark optional fields with the word (optional). By the way, Luke agrees with me on this one.
• Don’t open links in new browser tabs. Tabbed browsing is for advanced users. If you open a page in a new tab, most users will get lost, start clicking the back button, and then not understand why they can’t get back to where they started. Remember that they’re not focused on the chrome when they click a link, they’re focused on where they’re clicking. So it’s very easy to miss the fact that a new tab has opened.
• Don’t have an FAQ page. Most users don’t know what FAQ stands for, and besides, it’s bad practice to answer questions outside the context people want to ask them in. Figure out where in the process each question in your FAQ might come up, and provide the answer right there within the flow. Don’t expect people to click to a different page to find the information they need.
• Don’t use PDFs at all (unless you’re explicitly stating that it’s a downloadable research paper or something). Many users have no idea what a PDF is, and can’t even tell when they’ve clicked on one. There’s no reason to have your rates/menus/timetables as a PDF as opposed to standard text. This was a recurring theme, but one user in particular clicked on a PDF, didn’t realize it, and continued interacting with it as if they were still on the website.
• Don’t give table rows highlighting mouse-overs if the rows aren’t clickable. This confuses users. Any mouse-over movement gives users a trigger that they can click on the thing. Don’t think they’ll look at the cursor and distinguish between an arrow and a hand — most don’t look past the hover effect.

This is obviously a fairly random list of UI transgressions, but I feel like we talk about the big issues so often that we tend to skim over the smaller ones that can really add up. If you were observing the usability tests we ran this week, you would have felt the same way I did when you saw person after person struggling with the most standard of UI conventions. Let’s just not do these things, for the love of the web and everyone who uses it.

I really like Mike Monteiro’s “Dear Design Student” series on the Mule Design blog. The latest entry gives advice on how to deal with clients who say things like “I hate green!”:

When a client says, “I don’t like green”, most designers translate the sentence into “You must change the green.” But no one asked you to, did they? They merely made a statement about their subjective dislike of a particular color. Your job, as a designer, is first and foremost to listen. And then to gather data. Don’t jump the gun. How, if at all, does the client’s subjective taste enter into the success of the project?

He proceeds to give some good advice about how to figure out what the real problem is that the client is commenting on (if there is one).

(My other favorite post in the series is I want to start a company right out of school!)

Marcelo Somers wrote a good article arguing that to compete with the likes of Amazon, e-commerce companies need to focus on telling stories through the products they sell. From Disrupting Amazon: Rethinking eCommerce:

An eCommerce site should be about more than just selling stuff. It should embody a set of values that are distilled in how the product looks, how it feels, and what it contains. It should have an opinion - the story is how we go about telling it through our interface, how we merchandise, the photography, and the products on the site.

He also provides some examples of companies that do this well.

Related post from the Elezea archive: The welcome shift to context-based e-commerce.

Elliot Jay Stocks in Made to measure:

Responsive web design isn’t about filling every available bit of whitespace — it’s about balancing the innate flexibility of the web with a designer’s desire to control the output.

Jesse McKinley explores a fascinating trend in industrial design in the article The Cult of Disappearing Design:

Part interior illusionist and part aesthetic anorexic, Mr. McInerney is a practicing member of the cult of disappearing design, the now-you-see-it, now-you-don’t ethos that aims to secrete away anything that needs a button, a cord or a subwoofer to work.

Check out the slideshow as well. I think there is a point where invisible design becomes a bit too devoid of emotion for my taste.

Yesterday I read an opinion piece on a local news site that was just one long, scathing attack on the writer of another opinion piece on the site. No substance at all. You don’t have to go far on the web to see that kind of behavior. There is something about the false sense of anonymity provided by web sites, blogs, and comment sections that just bring out the worst in us.

Don’t get me wrong — I love disagreements. I believe that an essential quality of a good designer is the ability to balance his or her confidence in their proposed solution with an openness that they might be wrong. But we don’t disagree online any more, we just attack. I’ve often thought that new users of the Internet should be forced to read Paul Graham’s How to Disagree before they’re allowed to go any further. When it comes to online discourse we are, for all intents and purposes, locked in an Eternal September.

It is with these types of thoughts on my mind that I wrote a talk about how I think we can do better. I also turned the talk into an article for Smashing Magazine, which was published today under the title Making A Better Internet. The summary:

In this essay, I’ll weave together a story about the current state of Internet discourse. At the end, I’ll tell you how I think we can make it better. And then, we’ll most likely all go back to what we were doing and forget about it. Despite the probable futility of this exercise, I’ll carry it out anyway, because I love the Web and I really don’t want us to destroy it.

I don’t know what the reaction to this piece is going to be. I’m quite nervous about it, but we’ll see how it goes. If you’d like to see the slides from the talk, which I gave at a recent Cape Town Content Strategy Meetup, they are embedded below:

Read article on Smashing Magazine | View slides on Speaker Deck | Discuss on Google+

I can’t shake this nagging feeling that we’re changing our focus from “mobile context” to screen-size thinking and responsive design so quickly that our users won’t know what hit them. Although I fully agree with articles like Mobile Context Revisited and Design Process In The Responsive Age, I think there is a missing step we haven’t explored enough: how to change the mental models of users who have become used to separate sites on their mobile phones and desktop computers. Let me illustrate with an example.

During usability testing last week I noticed an interesting trend. It was dormant the whole time, but I just couldn’t put my finger on it until one participant explicitly articulated the problem. I asked her if she has ever visited the e-commerce site we were about to use. She told me that she’s never gone there on her desktop, but that she has browsed the mobile version of the site on her BlackBerry1. So far, so good.

But then she mentioned that when she found a product that she liked, she decided to switch from the mobile version (.mobi) of the site to the desktop version (.com) — while still on her phone — to try to buy it. Her reason? She assumed that the desktop version of the site will have more information about the product than the mobile site has.

The rest of the story gets even bleaker. She tried to force the .com version of the site, but her BlackBerry couldn’t handle it — she tried multiple times and it just kept hanging. So she gave up and never went to the site again.

The experience highlights a few assumptions made by this participant:

• She assumed that the site will have separate mobile and desktop versions.
• She assumed that these two versions will have different information on them.
• She assumed that it is up to her to decide which version will best suit our needs.

Can we blame her for these assumptions? Isn’t this how we trained her to think about mobile sites vs. desktop sites? We kept building sites with reduced feature sets on mobile phones because we didn’t want to overwhelm users. We taught users that mobile sites are inferior versions of their desktop counterparts, and now we have to live with the consequences.

Now, fast forward to the future we’re all driving towards: fully responsive sites that don’t abridge content, but adjust to the screen sizes they are being served to. Considering this participant’s assumptions, you can imagine how confusing a site like that would be to her. She’ll wonder where the mobile site has gone. She’ll wonder what content she’s missing. She might try to enter .mobi and not know why the thing keeps going back to .com. She (and millions like her) has never heard the term “responsive design”, and couldn’t care less about it. We’ve cemented users’ mental models over the past few years of mobile-specific sites, and it’s going to take time to change that.

So, what can we do? When we build responsive sites, we need to communicate to users that they don’t have to worry about finding the mobile site any more — everything they need is right there. This can be as simple as a message on the home page, or relevant microcopy at key stages of the journey, like on a product page.

I’m not trying to stand in the way of responsive design or screen-size thinking over mobile context thinking. But I am arguing that most normal users will be confused by this trend, and we need to manage that. Because we don’t want incorrect user assumptions to cause lower-converting sites that end up killing organizations’ commitment to responsive design.

---

1. Nope, I’m not misremembering what phone she used. ↩

One of the hardest things we have to do as a User Experience Design agency is to sell usability testing to clients. The concerns are usually some combination of the following:

• It will take too long (no, it won’t).
• It’s too expensive (not if you consider the potential ROI).
• You can’t learn much from 6 users (yes, you can).

But we keep at it, because we know that if we’re successful in our efforts to convince clients to try it just once, we’ll never have to sell it to them again. It’s a methodology that completely sells itself. Once a client sees real users struggle with their product, they immediately become believers and staunch evangelists of usability testing.

The situation was a little different for a recent project we worked on with Obox, creators of premium WordPress themes. They came to us already sold on the benefits of usability testing, they just needed our help with research design and execution, and to work with them on some of the design recommendations based on the data we collect.

Yesterday, CEO and co-founder David Perel did a write-up of the project where he explained the process and the changes they’ve made. It’s great to see such an open discussion about how they are implementing their relentless pursuit of delivering value to their users. And even though they already understood the value of usability testing going into the project, I still loved this sentence from The User Experience Experiment:

The bottom line is it doesn’t matter how good looking your site is. Watching a layman use your product will blow your mind. You cannot even begin to imagine how your users interact with it.

If that’s how they reacted, just imagine the power such a revelation can have on people who don’t believe in the method. David also says this in his post:

We’ve been so taken aback by what we learned that when we looked for new office space, the most important requirement was that it had an extra room for user testing.

I know this means that they won’t need to hire us again, but I don’t care. That type of full-scale adoption of user-centered design makes me infinitely happy.

Be sure to read the full post, it’s a great case study.

Hannah Donovan wrote a great article for A List Apart proposing some solutions to the problems of real-time communication feeds. From Everything in its Right Pace:

We struggle not only to keep up with each other’s data trails, but more importantly, to know which crumbs in those trails are worth picking up, as well as how to find them again later—like when you want to relax on the sofa after a hectic week and you know there must have been a bunch of cool things to listen to or watch that flew by on Twitter, but gosh, where are they now?

Once you’ve read Hannah’s article, also read Michael Angeles’s follow up called Pace, in which he explores how the Slow Movement impacts designers:

I have mostly stopped consuming from the firehose, and seek out the products that deliver a signal that I get more value from, more satisfaction, or that fulfil my basic needs with less fluff and noise. The decision to work with a product and team that follows those ideals is important to me as well. […] The Slow Movement is not just a lifestyle choice, but as designers, we can choose to have an impact on the world based on these ideals.

Last night I joked on Twitter:

Sometimes I want to break up with the Internet, but I just don’t have the guts to ask for my records and Phil Collins t-shirts back.

— Rian van der Merwe (@RianVDM) August 25, 2012

It’s only a half-joke though. I don’t want to break up completely with the Internet, but we definitely have a codependent relationship that might require some better pace so we can sort out our issues.