[caption id=“attachment_1181” align=“alignright” width=“240” caption=“Thinking about writing at Melissa’s Food Shop, Cape Town.”][/caption]

How good I am at my job as a software Product Manager depends on my ability to do two things: Understand the needs that real people have when they go online (whether they can articulate it or not), and building products that satisfy those needs as well as meet business goals. It occurred to me this morning that in many ways writing is about doing the exact opposite. To a large extent, writing is about being selfish.

Virtually any book or article you read about writing gives the same advice: Write what you know and what you’re passionate about. Write what’s in you, not what you think people want to read. Just last week James Shelley reminded us that people cannot help but notice an individual with passion. In another post he says:

Although passion may at times appear dangerous, the planet does not need less human passion right now, it needs more passion than ever before ”” passion that refuses to be immunized by the lulling caress of consumption and the crippling inundation of knowledge.

But it is this apparent struggle between Design and Writing (with a big D and W) that makes it so damn difficult to write sometimes. As user experience designers we’re trained to get out of our own shoes and into those of others. It’s about their needs, not our likes and dislikes. “You are not the user,” we often say.

But I have a feeling that the best writers (and designers, for that matter) are those who are able to balance this apparent conflict between user needs and internal passion effortlessly. Writers and designers who truly astound us with their work are those whose understanding of what people need are so ingrained in their beings, so much part of them, that they’re able to express their passion in a way that meets those needs “without fuss or bother,” as the NN Group definition of User Experience states.

It is for this reason that I think if you’re in software, you should write. Anil Dash got me thinking about this when he said:

Some ideas are just bigger than 140 characters. In fact, most good ideas are. More importantly, our ideas often need to gain traction and meaning over time. Blog posts often age into something more substantial than they are at their conception, through the weight of time and perspective and response.

If nothing else, the practice of writing down your thoughts (yes, about the things you are passionate about) will teach you how to create words in a way that resonates with those who read it. And just go ahead and try to convince me that won’t make you a better designer.

The biggest problem is, of course, that we all hate our own work, especially in the beginning. As Ira Glass so eloquently puts it:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit.

He goes on to give this advice:

And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.

If you’re noticing a change in this blog over the past few weeks, you’d be right. I’ve redesigned to put the focus on the content, and I hope to write just a bit more - even if that means fewer long-form posts. I have to test this theory that writing better words will help blur the lines between what I’m good at and what people need from software. We’ll see how it goes.

And you - yes, YOU. Go write something, ok?

I’ve been thinking a lot about the importance of humility in design. About a month ago David Gillis said the following in a great article for UX Magazine:

When it comes to designing experiences, cultivating a humble approach is absolutely essential. The sheer complexity of the design challenges we face demands open-mindedness - a willingness to test and modify assumptions, to make mistakes and be proven wrong.

Humility is about knowing what you don’t know, and when it comes to dynamic, interdependent, multi-platform systems, there are an awful lot of unknowns.

And then there’s this tweet by a good friend that’s been on my mind for a while now:

Ain’t that the truth.

But let’s also clarify: I’m talking about true humility here. Not the “Oh, I’m so humbled by your praise so let me retweet it to all my followers” humility. I’m talking about the humility that comes from realising that Design is about meeting user needs, that it’s a study of human behaviour so if any of us want to call ourselves experts at it we are sorely mistaken.

I didn’t think that a medieval monk could teach us much about design, but I recently stumbled on a quote by Thomas Kempis that brought this whole concept home for me:

A true understanding and humble estimate of oneself is the highest and most valuable of all lessons.

Should you see another person openly doing evil, or carrying out a wicked purpose, [or launch a really bad website,] do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.

We are all frail; consider none more frail than yourself.

I don’t think this means we should stop being critical when we see bad design. But I do think it means we need to criticise with the aim to contribute to the design community, not break it down. If we learned anything from the Dustin Curtis “Dear American Airlines” story, it’s that we cannot possibly know why people make some of the design decisions they make.

So let’s help each other out, is all I’m saying. Because one day you might put a bad design out there, and all you’ll ask for then is a little advice and lots of grace.

Last week I delivered a new talk at a Cape Town SPIN meeting (the Software Process Improvement Network). While I was preparing for it I thought of a working title for my next talk:

A talk about preparing a presentation for a talk about preparing a presentation for a talk.

You see, I have a love/hate relationship with new talks. I love delivering a new talk, and I love getting feedback on what worked and what didn’t. I love making it better. And I hate pretty much every moment leading up to delivering it.

But this is, of course, the problem with the creative process.  It’s blood, sweat, and tears, most of the way. Rands recently wrote a post entitled A Hard Thing is Done by Figuring Out How to Start. He writes:

Those who do not understand creativity think it has a well-defined and measurable on/off switch, when in reality it’s a walking dial with many labels. One label reads “Morose and apathetic” and another reads “Unexpectedly totally cranking it out”. This dial sports shy, mischievous feet - yes, feet - that allow it to simply walk away the moment you aren’t paying attention, and each time it walks away, it finds a new place to hide.

I’ve spent a good portion of my life wondering where that damned dial is hiding.

He goes on to explain how random moments of discovery and seemingly useless tangents are all part of the preparation process, and that we shouldn’t be so hard on ourselves when we’re struggling to get started. He closes with this:

W’re addicted to quick fixes, top ten lists, and four-hour work weeks, but the truth is - if it wasn’t hard, everyone would be doing it and a hard thing is never done by reading a list or a book or an article about doing it. A hard thing is done by figuring out how to start.

You’ve been spending a lot of time thinking the result is what matters. You have a bright and shiny goal in mind that is distracting you with its awesomeness. It is this allure of awesomeness that is the continued reason why you keep searching around your house looking for that mischievous walking dial.

My guarantee is that what is going to make this bright and shiny thing awesome isn’t finishing. It’s all the little, unexpected details you discover trying to start. It’s all the small pieces of unexplainable execution that will not only make it yours, but also continue to teach you how you get things done. And when you’re done, you’ll discover finishing, while cathartic, is just a good reason to go start something else.

I’ve absolutely found that to be true. My basic process for preparing a new talk is as follows:

• First, I spend weeks researching and saving articles to Delicious.
• Then I live in FreeMind for a few days, building the outline of the talk.
• I then proceed to tell myself I’m ready to roll, so I  spend another week or more getting all those thoughts onto slides.
• This is followed by several nights of bad sleep as I start seeing the holes in my thinking, and struggle to find the right words/pictures/length/style/order.
• And then, suddenly and without fail, about two nights before the talk, I hit Flow. That “mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.” Things suddenly fit, I spend 10 minutes re-ordering slides and it suddenly all makes sense. From that point on, the process is an absolute joy.

Why is Flow so hard to find? Or is it meant to be hard to find, because the creative process requires struggle as its fuel?

Whatever the reason, Rands helped me relax a little bit and panic less during the beginning phases of the creative process. Because all those starts, stops, and anxiety eventually come together to collide in the ultimate high that happens when things just… flow.

We’ve received quite a few questions about why we changed kalahari.net from a fluid layout to a 960px fixed width layout. There are pros and cons to both approaches, and Smashing Magazine did a great job of explaining those trade-offs in Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?

For me, the most important reason to use a fixed layout is that it allows you to have full control over the experience and what the user sees on the screen.

But since a picture is worth a thousand words, I guess you can sum up the problem with fluid layouts with a single screenshot:

About a week ago I had a discussion with a colleague in our development team about the new product development process we rolled out a few months ago. One of the words he used to describe the new process is fair.

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession.

Loads of articles have already been written about the characteristics of a good Product Manager (see the end of this post for links to some of them). They’re all fantastic, and I go back to them constantly when I’m in the hiring process or looking for personal development areas. But I’ve never been able to find the one characteristic that I think a PM simply cannot do without. I now think that fairness is that characteristic. Here’s why.

The role of fairness in effective product management

Let’s look at one definition of the word fair:

fair. adjective. free from favoritism or self-interest or bias or deception.

Free from favoritism

One of the fastest ways to become ineffective in a PM organisation is to start playing favorites with a particular internal group, product line, or user base. As soon as people sense that you are not looking at all ideas and input equally and fairly, a lack of trust inevitably follows. And without trust, you’ll have to work a lot harder (and longer) to bring people along for the ride on your roadmap.

Free from self-interest

If you start doing things purely with reasons like “because I want to” or “because I’m being measured by this metric,” that same lack of trust happens very quickly. You cannot be effective by nursing your own pet projects and ignoring all the other needs around you.

Free from bias

This often happens when PM’s get news they don’t want to hear — especially from the user research team. If something doesn’t test well, don’t make up reasons why you are right and the users are wrong. Do the right thing and realign the design.

One of the hardest skills for a PM to learn is to take their own emotions and feelings out of the equation when it comes to decision making. Yes, a lot of gut feel goes into a product vision, but that cannot be based on personal preferences or preconceived ideas.

Free from deception

This one seems obvious, but you see it often, especially when it comes to metrics and assessment. Don’t ignore/distort negative data or make a problem someone else’s fault. The PM’s job is to own a product — and this means owning its successes and its failures. You’ll gain trust and respect if you not only claim the successes, but also acknowledge the failures and commit to do it better next time.

The elements of fairness in product development

The PM role is often referred to as “the great diplomat,” and with good reason. It is our responsibility to balance a variety of needs from inside and outside the business, and somehow turn that into a roadmap that delivers business value as well as meets user needs. A focus on fairness accomplishes that goal:

• Fairness to users. Approach users with respect, openness and transparency. Understand their needs, and explain to them when you’re doing something that makes it more difficult for them to meet those needs. (Don’t be like Twitter and hide behind reasons like “consistent user experience.”)
• Fairness to the business. Do everything you can to understand the needs of marketing, merchandising, customer support, etc. Pull them into the planning process, be clear about how projects are prioritised, and help them adjust to that process so that they can define their project goals in the right way to get on the roadmap.
• Fairness to technology. Don’t force the development team to make the technology do things it’s not capable of doing. Understand the technical debt in the organisation, and work actively to make those improvements part of regular development cycles.

A lot of this comes naturally in good product managers, but we need to be conscious of it every day. Fairness is a table stakes characteristic for an effective product manager. If you do it right, the real work of building great product can begin. But if you don’t, you’re dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

More characteristics of good product managers:

• Recruiting Product Managers
• The desirable characteristics of a Product Owner
• Owning an Agile Product

The Twitter iPhone app is getting a world of criticism right now, and I have to say I agree with most of it (for an excellent overview and analysis of one of the main issues, see Why the Quick Bar is still so offensive). But let’s also give credit where credit is due. As Little Big Details has shown us - sometimes small UI touches can take a user experience from “meh” to “awesome” pretty quickly. And I think the Twitter iPhone app’s implementation of replying to a tweet with multiple users in it does just that.

If you respond to a tweet with two or more usernames in it, you technically need two options: Reply (to reply just to the person who wrote the tweet) or Reply All (to mention everyone that’s mentioned in the tweet). So, two buttons needed, right? Not in the Twitter app. There is just one icon to reply to such a tweet, and the screen you get then looks like this:

The screen automatically selects all users that appear directly after the user who wrote the original tweet. So in essence the reply button gives you three options:

• Just start typing if you want to erase other users from the tweet and just respond to the original user.
• Place you your cursor after the original user if you want to /cc the other users.
• Place your cursor after all users if you want to write a traditional “reply to all” tweet.

This is such a small thing, but I can guarantee the implementation was a deliberate design solution to a specific problem:

How can we reduce the need for a Reply button and a Reply All button while at the same time improving the user experience?

Little details like this should inspire all of us to sweat the details and not go “Ah, that part doesn’t matter, it works fine, right?”

One of the most often violated principles of visual design is, ironically, also its simplest — the principle of proximity:

Put things that are related close together, and space things that need to be seen as separate

One of the more extreme and frustrating examples of this can be found on the online banking site for ABSA (a South African bank):

The problem here is that if I select a beneficiary from the list I have to click the “Next” button that is at the bottom of the screen — far removed from the action I took in the dropdown. Instead, the “Add new” button, used to create a brand new beneficiary, is in close proximity to the dropdown, and therefore gives the sense that the dropdown and the “Add new” buttons are grouped together. The solution to this problem is so incredibly simple: just switch the buttons around.

Another example I came across recently lives in Outlook for Mac 2011. Let me first say that as much as I’m not a fan of Microsoft, Outlook for Mac is still so much better than any version of Entourage, so for that I am eternally grateful. But the implementation of email search really needs some work.

Say, for example, I am looking for all emails that include the term “Clicktale.” My starting point is this text box, which states that I will be searching the current folder only. I knew that the email I was looking for wasn’t in the current folder, but on hover an additional message told me that after I searched I’d have the option to expand my scope, so I wasn’t too worried:

Things got tricky the minute I started searching though. As I typed, a dropdown appeared:

The email I was looking for had the word “clicktale” in the body, so none of these options applied to me. I didn’t know what to do, so I just stopped typing, wondering what to do next. Well, suddenly all email disappeared from my Inbox (current folder), so I assumed that meant the search somehow happened. But there was no feedback about this, I had to figure it out based on my knowledge of what’s in the folder and what I was looking for.

Well, ok then. Now to figure out how to expand the search to more folders. First I went down a completely wrong path. I clicked on “Advanced”, and found this dropdown:

Hmm, no good. I needed to expand to different folders, so clearly this was the wrong direction to go. I started over, and after much searching, found the “All mail” button. Can you spot it below? (Click to enlarge the picture)

Even by pointing out what you’re looking for, and removing some of the clutter in the rest of the page, I bet it took you some time to find it. Why? The design principle of proximity. The filtering action is so far removed from the search box where you type that your mind just doesn’t make the appropriate grouping.

Now, I appreciate what the designers tried to do here. Instead of presenting you with all options upfront they designed a good experience for the majority use case (searching within the same folder), and used progressive disclosure for advanced usage after the initial search is done. But by breaking the principle of proximity this results in a big reduction in usability.

These are two quick examples, but keep an eye out for proximity issues as you browse the web this week, and let’s make a point of adhering to this principle in our designs. There are so many hard usability problems to solve that we really should make use of the easy wins. This is one of them.

Read more about the proximity principle:

• Using Power Structure and Gestalt for Visual Hierarchy
• Design Note: Similarity and Proximity
• Gestalt Principles Applied in Design
• Perception and the design of forms ”“ Part 5: Proximity

This is a question that doesn’t seem to go away: “How do I convince my company that good design is worth investing in?” It’s frustrating to work in an industry where you have to spend so much time showing the value of what you do.

At first I placed all the blame on (big) companies who are too cheap to pay for good design because they don’t think it’s necessary. But then I started to wonder… maybe some of it is our own fault? Maybe we just haven’t yet proven, within our industry and the companies we work at, that good design will result in positive ROI?

If I remember one thing from Marketing 101, it’s this obvious (but often forgotten) truth: Businesses exist to make money. Companies work so hard to make us happy for one reason only: so that we will buy more of their stuff. This seems obvious, but it’s important to remember. Because when you talk to the management teams of your organization/clients, telling them how beautiful their site will be once you’re done with it is just not going to cut it.

To prove the value of user experience design, you have to prove that by investing in it, the business will make more money. It’s as simple as that. Well, the concept is simple. The execution is… complicated. In this post I’d like to propose some ways to help us prove the value of design, so that we can spend more of our time building great experiences and less time telling people why they should build great experiences.

Design = Money

Proving that good design will make your organization/client more money is not something you can apply a formula to and do overnight. It involves some hard work and clever thinking (time well spent) to figure out what works best for the context you’re designing in. In some cases, like designing a Checkout process, it is relatively easy to define success metrics, benchmark, and show that a redesign resulted in more money - because checkout is where the money is.

In other cases, for flows that are further removed from direct revenue generation, it can be much harder to find the money link. In those cases, a conversion model is often the right way to go:

In most online user flows you can make a strong case that an improved conversion rate (or reduced drop-off rate) will result in increased revenue. Once that link is made, what remains is to prove that an improved user experience results in improved conversion rates. But there are immediately two challenges with this approach:

1. How do you buy the time you need to prove that UX works?
2. How do you find the right conversion rate model to link UX to conversion rates (and ultimately revenue)

So let’s dive into that.

Buying time to do the right thing

Getting an organization or client to invest in UX can be quite tricky in the beginning. Without real data, it’s hard to show the value. But without the time to do the process right, it’s hard to get real data. And so the vicious circle continues.

One way to buy some time is to show case studies where an investment in UX design has resulted in significant revenue lifts. One of these case studies is Jared Spool’s The $300 Million Button, where a simple design change resulted in an enormous revenue lift. Spool writes:

When the team contacted us, they’d already pretty much decided what the problem was and how they were going to fix it, even though they had never watched any shoppers make purchases. And they were dead wrong. Not only was their fix not going to help, our research showed that it was going to increase abandonment.

Two weeks of usability testing on the live site (and on competitors’ sites), followed by two weeks of iterative paper prototype testing produced a streamlined checkout process, which, once implemented, showed a dramatic increase in revenues. It’s amazing what you’ll learn when you actually watch your users.

Obviously not all UX changes are going to have this much of an impact. But sharing cases like this with senior management or clients should help in making the case for investing in a proper user-centered design process. I know this is easier said than done, but mountains can be moved with some solid data and stubborn persistance.

So, let’s assume you’ve shown that a good UX can increase revenue quite significantly. How do you go about proving it for one of your own projects?

The three A’s

One of the marketing principles that are quite useful for user experience design is looking at the source of revenue as coming from one or more of three sources:

• Acquisition. Getting new users to sign up for your site/service
• Activation. Getting those new users to make their first purchase
• Activity. Getting those first-time purchasers to come back for more

If you can tie a UX project to one or more of these sources of revenue by showing that you increased conversion rates in those areas, you’ll have what you need. You’d have shown that design=money. Here are some hypothetical examples:

• A registration flow redesign can be shown to improve conversion from sign-up landing page to signed-up users. This ties into Acquisition.
• Improvements to a search results page can be shown to improve conversions from search —> items placed in a shopping cart. This ties into Activation and Activity.
• Home page layout and content changes can be shown to improve click-through rates on merchandising offers specific to new users. This ties into Activation.

And this list can go on and on. It won’t always be easy, but every UX project should be measurable in terms of its impact on the business, and tying it to one of the three A’s is a good structured way of anchoring all design changes in business goals (and ultimately, revenue).

Define your success metrics, benchmark those metrics before any changes are made, and then measure the (hopefully improved) increase in metrics.

In summary

As designers, we need to assume some of the blame of working in an industry that often has to fight very hard for appropriate resources to do our jobs. We need to understand why businesses exist, and follow a strategic approach to proving the ROI of design:

• Show historical case studies to buy some time and resources to follow a proper UX design process on one or more of your projects.
• Start on a project where changes can be measured by an improvement in one of the three A’s of revenue generation: Acquisition, Activation, or Activity
• Benchmark well before the start of the project, follow through on the UX design commitment, and measure your results - see this post on Six Revisions for some tips on which measurement tools to use. (What to do if the results are negative is a topic for a whole different post).

There is no perfect way to prove the ROI on design - this is just one proposal. Another side that I didn’t explore in this post is the many ways that UX can result in cost/resource savings. That’s deliberate since I wanted to focus specifically on the positive side of the revenue equation (for a discussion of some of the savings benefits of UX, see this great video by Susan Weinschenk from HFI).

I’d love to hear your thoughts on this important issue. How else can we prove the value of design?

I just found out about the redesign “project” (not sure what to call it) that South African radio station KFM is kicking off (thanks for the heads-up @1rene, @kerry_anne, @allankent, @wendyrobb, and many others). Here is the ad for it:

I’ll stay away from the cheap shots you could take on the ad itself, because granted, they’re admitting they need a designer. Instead, I’d like to focus on two major problems with the idea itself, and what that means for the web design industry.

1. Design is not “colours, fonts, textures, spacing, layout and images”

It’s really shocking that we still need to have this conversation in 2011, but guys, what you’re asking for is Visual Design. What you should be asking for is User Experience Design, which is made up of so much more than what you’re asking for:

There is no space or time to go into it here, but the point is that you need a User Experience designer to help you understand these elements, and not just give you a pretty design that doesn’t meet user needs.

• User research helps you uncover user needs and expectations for the site.
• Content strategy helps you define the voice and tone of your site, and writes content that meets the needs of your target visitors.
• Interaction design helps you design an information architecture and a flow through the site that lets users accomplish their goals in the most efficient way possible.
• Visual design provides the appropriate visual language to guide users along this ideal path that you define (and, fine, it also makes it pretty).

I think @allankent summed up my feelings about this issue the best:

Please KFM (and everyone else thinking about a redesign): don’t just make your site pretty. Make it something that allows your visitors to find the content they’re looking for, and enjoy it while they’re there.

2. “If you’re good at something, never do it for free.”

The second problem with this project is almost worse than the first. And that is the expectation that a designer should give up his or her time for free to work on this. Just, you know, for love of the game. The Joker’s words in The Dark Knight bears repeating:

If you’re good at something, never do it for free

If KFM is serious about a site redesign, they’ll pay for a proper redesign project, not ask people to give away their skills for free. Good design is hard, and if you paid the price it takes to become good at it, you should be compensated for your time. After GAP asked designers to redesign their logo for free a few months ago, Mike Monteiro wrote a great post on this that you must read. In Dear Gap, I have your new logo, he says:

Man, that stuff took time. A lot of time actually. And a tremendous amount of effort, as well as expertise. Expertise that came from a combination of training, which I had to pay tuition for, and experience. I’m good at this because I’ve done it a lot. Sure, ther’s some natural talent there, but by and large I’ve gotten good at my job the same way every other worker has. By experience, by focused effort and by learning from my mistakes.

So as much as I’d like to just show you the greatest logo I’ve ever made for anyone (“¦and trust me, if Paul Rand himself saw it, he would realize he was merely the Pippen to my Jordan.) I’d like to be properly compensated for it. Because I put a lot of time and effort into it. And it’s how I earn my living.

And that time and effort was used to make sure I delivered something that actually met your needs and objectives. You guys have numbers to meet. And plans for the future based on meeting those numbers. So do I.

And for the sake of full disclosure I should let you know that I’ve also frequently shopped at your stores. You sell good stuff. But never in my experience has any of your employees offered me a free pair of pants because the ones I was wearing looked bad. I wouldn’t expect them to. Their job is to sell me clothes.

My job is to sell design.

To designers: please, please don’t cheapen our industry by doing something you’re good at without compensation.

And to KFM: please don’t ask people do this work for free. I’m really happy you want to redesign your site, but you should pay UX professionals to help you do it. I guarantee you will be happy with the result.

If we’re going to move this industry forward in South Africa, we’ll need to start being serious about what design really means. And that means putting money behind the education and employment of user experience professionals.

As the UX field grows and more companies start taking user-centered design seriously, we need to start thinking about how we’re going to rescue all those stray sheep of the UX world — those areas that are getting left behind because we’re (understandably) focusing on the obvious, most important things. Two of these “stray sheep” issues come to mind immediately.

One is bad error messages, which is the subject of a whole other rant, so I won’t go into that now (I’ve started a Flickr group to collect examples - come join and contribute!). The second is user onboarding, which Whitney Hess defines as follows:

Onboarding is the process by which you can help users overcome the cold-start problem””a blank profile, an unfamiliar interface, a general feeling of “what the heck do I do next?”

And that’s what I’d like to address in this post.

The importance of user onboarding

When Jakob Nielsen wrote his 10 Heuristics for User Interface Design in 1990, he devoted one of his rules of thumb to user assistance and help documentation:

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Yes, first prize is to have a system that doesn’t require onboarding or documentation. But that’s not always possible, especially in the fairly new field of mobile design. So, if you need to provide onboarding help, what’s the best way to do it?  A List Apart recently published an excellent article (Good Help is Hard to Find) on how to write good Help content, with specific reference to the importance of context:

Help content can be rendered in many ways, but if possible, embedding it directly within the feature it serves is almost always the best choice. When help is offered in context, affordance is high: That is, the help is obvious to the user. Even better, context-based help is the least disruptive to workflow, as it doesn’t require the reader to view a separate page.

To name one example of contextual onboarding: when you first sign up for an account on website builder Yola.com, you see this screen, which provides tips on how to get started:

You can write whole books on good and bad implementations of user onboarding in web apps (The Baymard Institute recently posted 3 Examples of Inline Help, which is well worth reviewing). But I want to focus specifically on how user onboarding should be applied to mobile touchscreen applications, because we don’t yet have best practices for that.

Here are some best practice guidelines I’d like to propose for onboarding users on these devices:

1. Don’t show all the information at startup

When you first start up the magazine app Pulse, you get this screen:

It’s certainly different - fun and quirky. But it’s also overwhelming and too much, too soon. I haven’t started using the app yet. In fact, when I installed it I wasn’t even sure what it does - is it an RSS reader or a news feed from predetermined sources? Or something completely different? I can’t do a tutorial on something I don’t understand yet.

So, guideline #1: make sure that users have familiarized themselves enough with your app to have the correct mental model before you start teaching them how to use it.

2. Show one (or only a few) tips at a time

Project is another magazine app that’s getting a lot of press at the moment. Project adheres to rule #1 by getting you a few pages into the experience first before showing you the ins and outs of the app itself. But then you get to this page:

That is just way too overwhelming. Ignore, for the moment, the heavy visual design that makes this so hard to read. Even if this was designed in a clearer way, there is still too much information on the page, too many things to try to absorb and commit to memory. Speaking of Nielsen, remember this heuristic:

Recognition rather than recall: Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate

This page increases cognitive load significantly, and requires the user to remember too much. And this brings us to guideline #2: Show users only the information they need to take the immediate next step(s) for using the application. Consider, for example, two screens from the iPhone app Birdhouse:

It follows guideline #1 by telling you what you’re going to use the app for, and it follows guideline #2 by telling you one thing you need to know to use the app, at the exact time you need it. The first screen lets you know what information is needed to use the app. The second screen tells you how the “History” function works, at the moment you might want to start using it (after you’ve published your first tweet).

3. Always keep the app’s context visible

Yet another magazine app, Zinio, does their user onboarding this way:

Even though it could be simplified, this is a pretty good way to get users started. It explains what each of the areas of the app are, and it uses arrows to keep the context of the app visible, so that you know where to find the areas you’re looking for. Guideline #3: Make sure users have a clear link between the information you give them and how to access/use that information in their everyday use of the app.

Another good example of this is the Apple remote app for the iPhone. When you tap the Help icon, the interface stays the same, but some additional information is overlayed across the screen to show you what each of the areas are for:

Summary

In this post I proposed some guidelines for onboarding users on apps for mobile touchscreen devices:

1. Make sure that users have familiarized themselves enough with your app to have the correct mental model before you start teaching them how to use it.
2. Show users only the information they need to take the immediate next step(s) for using the application.
3. Make sure users have a clear link between the information you give them and how to access/use that information in their everyday use of the app.

This is certainly just a start, so I’d love to hear more suggestions — how can we quickly and effectively onboard users on mobile applications?