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?

In this post I make the argument that companies should hire designers that have a strong foundation in psychology and design theory. I further make the case that when Product Managers and other UX practitioners give feedback on designs, they should move away from their personal visual preferences and instead focus on feedback that relates to the user and business goals they are trying to meet.

I recently had a discussion with an Interaction Designer friend of mine about the perils of Design by Committee.  His take on it was, in essence, as follows (paraphrased a little bit):

The problem is that everyone thinks they’re a designer. Not everyone can code, so they don’t go to developers telling them their markup needs to be more semantic or more valid. But everyone has a gut feel about design - they like certain colors or certain styles, and some people just really hate yellow. So since everyone has an emotional response to a design, and “it’s just like art,” they think they know enough about design to turn those personal preferences into feedback.

It is a real shame that we have come to this point where design just means “making things pretty” for some. Even among people who do understand it’s about more than that, there is sometimes this misconception that there is so much personal taste involved that “your guess is as good as mine.” And to add insult to injury, they way that feedback is given to the designer is often more destructive than helpful. Look, I’m not against design feedback at all - it’s an essential part of the process. But if you’re going to give feedback, do it right. More on that a little later.

The truth is that design is science. Yes, of course it’s a creative discipline, and every designer has a style they like, and strong ideas on aesthetics.  But it is important to understand that aesthetics is the last mile of design. Before that (if you do it right) comes hours and hours of analysis and thinking, resulting in solutions that are built on very real psychological principles, easily proven using the user experience validation stack.

The major problem with focusing too much on aesthetics (and our personal views of it) in design is this: it makes the site harder to use.  Jeffrey Zeldman’s excellent 1999 piece Style versus design places some of this blame on designers themselves, but it sums the problem up perfectly:

When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name ”” at least, in some circles.  Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

So let’s be clear. Design is not about what feels good to you. Design is about meeting business goals. It’s about solving user needs so that your business can make more money. In Mike Monteiro’s recent post on Giving Better Design Feedback he builds on this idea and gets to the crux of it:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

This madness has to stop. I’m not arguing that we should create ugly web sites. In fact, as long as the focus is first and foremost on meeting user needs and business goals, beautiful sites can make the experience simply wonderful. But I am arguing that those of us in the Product Management and User Experience field need to fight for three things:

• A design culture that is routed in theory, analysis, and critical thinking.
• A company culture that hires designers with strong roots in theory and analysis
• A managerial culture that trusts their designers to do their jobs.

So how do we as Product Managers and UX practitioners help affect this change?  We need to gain a much better understanding of what goes on under the hood of design. We need to do this so that we can give better design feedback, but also for the sake of the business in general, so that we are able to make a strong argument for what’s right when it comes to design culture. And lucky for us, there are plenty of great resources online to help us learn how to objectively look at design, and understand the science behind it. Here is my initial suggested reading list:

• The psychologist’s view of UX design is an incredibly detailed look at user behavior on websites, with additional outgoing links to more great content. I go back to this post often.
• Designing for the Mind explains how the brain interprets visual information, and how that translates to web design that works (and is also aesthetically pleasing).
• Gestalt Principles Applied in Design goes further down the path of using established psychological principles to create better designs.

But just how important is it that we solve this problem? In a scary, almost prophetic way, Zeldman ends his post on style vs. design with the following words of caution:

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web ”” which is what most of them do when they’re online.

I fear that now, more than 10 years after he wrote those words, we’re still in the same boat. Let’s change that. The next time you need to give feedback on a design, don’t go with your gut. Go with science, and keep your user/business goals in mind. Ask your designers goal-oriented questions, and if they can defend the decisions they made, trust them. If they can’t, you just gave constructive feedback. As you should.

I recently read two book excerpts, both about art and the creative process, that I think are extremely relevant to web design, so I wanted to share it here. The first is from the book Art & Fear: Observations on the Perils (and Rewards) of Artmaking, and it tells the story of a ceramics teacher on his first day of instruction:

A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of the work they produced. All those on the right would be graded solely on their works’ quality.

His procedure was simple: On the final day of class he would bring in his bathroom scales and weigh the work of the quantity group; 50 pound of pots rated an A, 40 pounds a B, and so on. Those being graded on quality, however, needed to produce only one pot — albeit a perfect one — to get an A. At grading time, the works with the highest quality were all produced by the group being graded for quantity.

It seems that while the quantity group was busily churning out piles of work — and learning from their mistakes — the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of clay.

The second is from Absolute Truths, where a character in Susan Howatch’s novel talks about the struggles she encounters as a sculpter:

But no matter how much the mess and distortion make you want to despair, you can’t abandon the work cause you’re chained to the bloody thing, it’s absolutely woven into your soul and you know you can never rest until you’ve brought truth out of all the distortion and beauty out of all the mess - but it’s agony, agony, agony - while simultaneously being the most wonderful and rewarding experience in the world - and that’s the creative process so few people understand.

It involves an indestructible sort of infidelity, an insane sort of hope, an indescribable sort of… well, it’s love isn’t it? There’s no other word for it… and don’t throw Mozart at me… I know he claimed his creative process was no more than a form of automatic writing, but the truth was he sweated and slaved and died young giving birth to all that music. He poured himself out and suffered.

That’s the way it is. That’s creation. You can’t create without waste and mess and sheer undiluted slog. You can’t create without pain. It’s all part of the process, it’s in the nature of things.

So in the end every major disaster, every tiny error, every wrong turning, every fragment of discarded clay, all the blood, sweat, and tears - everything has meaning. I give it meaning. I reuse, reshape, recast all that goes wrong so that in the end nothing is wasted and nothing is without significance and nothing ceases to be precious to me.

These stories are some of the best descriptions of the creative process that I’ve ever read. The next time you’re mid-design and feel like you’re stuck in the “sheer undiluted slog” that is sometimes the reality of what we do, think of this.

You’re not just theorizing about perfection - you’re doing.

Think about how you can reuse, reshape, and recast all the failed efforts.

Give it meaning by letting it lead you to the next, better solution.

Remember Plaxo? I do too, but up to now I remembered them like I remember MySpace: “That site that used to be popular for something-or-other.” But recently a bunch of people I used to work with moved to Plaxo, and they’re colleagues I respect, so I thought I’d check it out again. You know, one day. But to his credit, Preston’s incessant tweeting about how awesome Plaxo is finally got me off my procrastinating butt to sign up for the thing.

And I am impressed.

I only signed up this morning so this isn’t really a review of the service, but I did want to make a couple of points about the sign-up process and some very effective use of microcopy. UX designer Joshua Porter has written extensively about the value of good microcopy, and so have the folks at Polon. To quote from Joshua’s post:

Microcopy is small yet powerful copy. It’s fast, light, and deadly. It’s a short sentence, a phrase, a few words. A single word. It’s the small copy that has the biggest impact. Don’t judge it on its size”¦judge it on its effectiveness.

Below is the first screen in the Plaxo registration flow. I’ve circled the microcopy on the form:

The copy on Date of Birth and Gender are particularly interesting, for two reasons:

1. They’re extraneous fields that you usually don’t see on sign-up forms that are optimized for maximum conversion. More fields usually equal higher drop-off, so this has the potential to be dangerous.
2. In particular, these are fields that people feel a little uneasy about from a privacy perspective. People are especially skeptical about providing Date of Birth.

Plaxo does quite a few things right with this microcopy:

1. Short messages to explain why the fields are required.
2. Plainspoken language that is easy to understand - no legal jargon.
3. The explanation is phrased as a user benefit. They want your date of birth not for some sinister reason, but so that your friends can wish you Happy Birthday. That’s good copy.

I’d love to see some data on the conversion rate of this form with and without the microcopy. Maybe Plaxo can do the user experience community a favor and run an A/B test for us? :)

I also wanted to briefly mention the second screen in the sign-up flow:

We’ve all seen these confirmation screens that tell us we need to confirm our email address. But I haven’t seen an image of what the email looks like on the confirmation screen before. In an age where users are terrified of fraud, this is another small detail that probably has a pretty significant impact on users’ comfort with the Plaxo service. Well done, guys.

But hey, it’s not all good. I spent about 10 minutes trying to set things up and I got pretty overwhelmed with all the information being thrown at me, so I took a break to write this post instead. I hope I’m the only one with that reaction…

As an enthusiastic (but mediocre) runner, I’ve been thinking a lot about the similarities between marathons and product management.  With all this focus on sprints, we sometimes forget that as one sprint runs into the next one, and the next one, and the next one, at some point it doesn’t feel like a sprint at all any more.  And before you know it you’re tired, overworked, and excessively grumpy — basically teetering on the edge of sanity.  There has to be a better way, right?

So when it comes to long runs, I think you can plot the relationship between distance covered and your level of joy as follows:

In general, you start off feeling great.  But as the first mile progresses, you start getting weird thoughts.  “What have I done?” “This is the stupidest decision I’ve ever made!” “I’m going to die!!!” And by the time you finish the first mile, you’re ready to collapse in a crying heap of shame.  But then something strange happens: you start enjoying yourself.  You hit your stride, you look around, you enjoy the scenery and the people… And before you know it you think that you can carry on like this for forever.

But of course, you can’t. At some point, things start going South again, and you feel like you’re never going to be able to finish. A downward spiral of self-doubt ends with a dose of endless self-pity in the dark depths of hell. And you’re ready to give up again. But then you see it: “1 mile to go.” And suddenly everything feels ok again. You pick up speed and race across the finish line like the champion that you know you are. And you say, “That was great! When can we do it again!”

This is a post about what I call First Mile Problems and Last Mile Problems in day-to-day Product Management.  If you replace “Distance” with “Project timeline”, and “Joy” with “Sanity level” in the graph above, I think you’ll have a good overview of what it means to be a PM. And the problems you experience at the beginning of a project are often distinctly different from the problems you experience later on. So I’m hoping that we can help each other here, and hopefully end up with a graph that’s a little more… stable.

First Mile Problems

1. Aligning the team

One of the toughest challenges in Product Management is getting everyone on the project team working in the same direction towards the same vision. Sure, you all like each other and work well together, but how do you take all those differing opinions, stop the brother/sister-like bickering, and get to work? This isn’t something I’ve completely figured out, but I do think some of the answer lies in what Business Week calls I-shaped people.

We’ve all hear about T-shaped people — those who have a deep understanding of one specific topic, and a basic knowledge of a broad range of different topics. But I-shaped people are different:

These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between.

[They are able to] rise above the specifics of a particular problem to think about them in a more abstract, and in some ways, more general way.

I-shaped people are able to build consensus around the team’s direction because they’re able to not only see  where the product is going, but they’re also stuck in the weeds enough to have credibility to make the day-to-day decisions. I look at it this way:

When you set the vision for the product, keep your head in the clouds:

• Communicate the vision clearly to the team, don’t expect they’re just going to implement whatever you tell them to do. Bring everyone along for the ride — it will make the vision better, and keep everyone invested in what you’re doing.
• Show how you plan to get there, so that the team knows it’s more than a pipe dream. Use broad strokes to communicate ordered priorities that will get the team to the vision. Which brings me to my next point…
• Use pictures. It doesn’t matter what kind. Sketches, wireframes, hi-fi mocks, whatever it takes to get the message across and allow everyone to have the same vision in their heads. Not showing at least some framework is a recipe for running into trouble in the last mile.
• Above all, remain flexible. The vision is a plan, and nothing more. Things will change. New ideas will come up. The interface will change. That’s more than ok — it’s a good thing. But you have to start walking in the right direction, otherwise you’ll never get anywhere.

When you get going on the project, keep your feet on the ground:

• Be in the details. Understand every pixel on the page. Know about every single Jira ticket. Show that you care about the journey, not just the destination. Be there for your team to remove every and any roadblock that might come up and prevent them from making progress.
• Communicate clear expectations, then trust your team. If you did your job right, you hired a team of amazing people. So don’t second-guess them. Ask questions, but allow the designer to defend his/her decisions, and trust them as long as the thought process makes sense.
• Most importantly, don’t hover. This is a hard one for me, but don’t stand over the designer’s shoulder. I have a rule — if a designer has Photoshop/Fireworks open, I stay away. They’ll come to me when they’re done. As the excellent article World Wide Mush points out: “If you want to foster creativity and excellence, you have to introduce some boundaries. Teams need some privacy from one another to develop unique approaches to any kind of competition. Making everything open all the time creates what I call a global mush.” Designers need time to design on their own before they share their thoughts with the rest of the team.
• And finally, learn what you don’t know. This one might be a little controversial, but I tend to agree with Six Revisions in their post Should Web Designers Know HTML and CSS: “Web designers should know HTML/CSS ”” even if it’s just limited to the fundamentals ”” for the sake of being able to create web designs and web interfaces that work on the medium.” If you don’t know how to code, learn. You don’t have to be great at it, you just need to understand it. If you came from a technical background and don’t know much about UX design principles, LEARN it. It will garner respect, make you more effective, and above all, result in better products.

I want to end this section with a final word on trust, which is a topic that’s very close to my heart. The site “99%” recently posted a fantastic article called What Motivates Us To Do Great Work. It’s a must-read for all managers of creative teams. The crux is this:

For creative thinkers, [there are] three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). All three are intrinsic motivators.

As creative thinkers, we want to make progress, and we want to move big ideas forward. So, it’s no surprise that the best motivator is being empowered to take action.

When it comes to recommendations for creative leaders, [authors of a recent study] don’t mince words: “Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources.” In short, give your team members what they need to thrive, and then get out of the way.

Like I said: trust, don’t hover…

2. Stakeholder buy-in

Once you have team alignment on the project and the vision, it’s time to turn your attention outward and focus on stakeholder buy-in. This part of the process often makes me feel like I’m on the wrong end of a very angry mob. It’s a stage when Product Managers need to use all the communication skills they can muster. Because when it comes to design, everyone has an opinion.

So this is where we need to talk about the phenomenon of Design by Committee.

If you haven’t seen the Oatmeal comic How A Web Design Goes Straight To Hell, you need to go read that first, and then come back here — it’s a perfect summary of the problem. The ultimate post on this problem has also already been written, so I’m not going to spend too much time on it — just go read every word in Why Design by Committee Must Die in Smashing Magazine. I do want to highlight a couple of areas in that article, and add some of my own comments.

One of the main problems we have in web design today is that everyone thinks they’re a designer. With coding it’s different — not everyone can code. But design is different. Like art, everyone has an opinion on design. You like it or you don’t. And because you have this immediate visceral reaction to a design, it’s tempting to confuse that with knowing what makes a design good. But that’s simply not true.

As posts like Designing for the Mind and  Gestalt Principles Applied to Design have shown, what makes a design “good” has very little to do with taste, and everything to do with the proven psychology of visual perception. “Pretty” is a small part of design compared to applying the principles of solid user experience design to an interface. So please, let’s leave design to the people who are trained in this stuff. Have I mentioned the importance of trust?

The Smashing Magazine article ends with this advice, which I agree with:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

On a practical level, this is how I apply that piece of advice:

• Respond to every piece of feedback. This is tiring, but essential. Regardless of how helpful it is, if someone took the time to give you feedback on a design, you need to respond to it.
• Note what feedback is being incorporated. Be open to good feedback, don’t let pride get in the way of a design improvement, and let the person know what feedback is being incorporated.
• Explain why feedback is not being taken. If a particular piece of feedback is not being taken, don’t just ignore it. Let the person know that you thought about it, and explain the reason(s) for not incorporating that feedback. It’s hard to get upset at you if you explain clearly why you’re taking the direction you’re going with. And if you’re not sure how to defend the decision…
• Use the user experience validation stack to defend decisions. Read the post Winning a User Experience Debate for more detail, but in summary, try to first defend a decision based on user evidence — actual user testing on the product. If that’s not available, go to Google and find user research that backs up the decision. In the absence of that, go back to design theory to explain your direction. I mentioned some sample posts above that should be helpful, and also check out The Psychologist’s View of UX Design.

When it comes down to it, everything once again comes back to trust, and a clear definition of roles and responsibilities. Senior management needs to trust their hiring judgment, trust their Product Managers, and give them the authority to make decisions for the projects they are responsible for. And, of course, hold them accountable if those decisions end up being wrong. It’s all we want: give us the tools we need to get the best possible product out the door, and hold us accountable if we’re not successful.

Last Mile Problems

Ok, so let’s assume you have a team that’s moving along, working away on a project, and all the stakeholders are bought in, so you’re on a roll. But it is almost inevitable that things will get rocky again towards the end of the project. Here are some Last Mile Problems and thoughts on how to deal with them.

1. People issues

I probably don’t even have to describe this one. We all know what happens. People get tired and cranky. They start distrusting each other. A small mistake creeps in and the whole team jumps in to point it out. Whatever the catalyst, the outcome is all too familiar — a team that fights more than they work. So what do you do?

I’m not a fan of self-help books at all. Let me start by saying that. But a previous manager recommended Crucial Conversations — Tools for Talking when Stakes are High to me, and it’s been one of the most helpful books I’ve ever read. You have to read it cover to cover, but in summary, it describes how, when people are put in situations where they feel threatened for one reason or another, they react in one of two ways:

• Silence. When things get rough, some people simply withdraw, either by going quiet, glossing over the issues, or masking what’s really going on by changing the subject and talking about other things.
• Violence. Others resort to attacks (both directly or indirectly through passive aggressive behavior), putting labels on people (“he’s an idiot who writes bad code…”), or trying to control the situation without considering the opinion of others.

Both of these responses are destructive and not conducive to good teamwork.  So the rest of the book focuses on how to deal with those behaviors.  How do you create a safe environment where everyone feels they can voice their opinion without feeling disrespected or unvalued? I’ve found the following process really helpful in situations of team conflict:

• Commit to seek a mutual purpose. Recognize that there is a problem, and get the team to commit to fixing it and not just sweep things under the rug.
• Recognize the purpose behind the strategy. If different people on the team want different things, ask them to explain why they want this done a certain way. Even better if this can be phrased from a user’s perspective. For example, saying “I want this button to be red because I believe it will convert better” shows that the purpose behind the strategy is to increase conversion.
• Invent a mutual purpose. After everyone voiced the purpose behind their strategy, discuss a purpose everyone can agree on, before looking at specific tactics/strategies to get there. For example, if one team is concerned about conversion and the other team about user confusion, can you bring those together, and invent a purpose that encompasses both ideas? Can the purpose be to reduce drop-off while staying within the site’s visual style guide?
• Brainstorm new strategies. Once you know what the purpose is, the team can brainstorm solutions that will fulfill that purpose. Continuing our example, move the discussion away from button color, and find ways to move elements around to reduce user confusion and drop-off, while committing to testing different button colors and adjusting the style guide based on whatever the data says.

I used an imperfect example to explain those points, but the principles work — give it a try!

2. Delivery issues

Stress-levels rise as delivery dates approach, especially if it looks like those dates aren’t going to be met. The first thing we need to clear up is that humans are horrible at estimation (here’s a very interesting post trying to solve that problem). I think the solution to this kind of stress is, as controversial (yet recently very popular) as it is, to do away with detailed estimates.  Tom Fishburne sums it up really well in his post Waterfall Planning:

It’s important to know the business inside and out and have a clear trajectory where w’re headed.  But there is a point where planning becomes overplanning.  All that time spent planning is time spent not doing.

Gantt charts are particularly problematic in this regard, as summed up by another great post called Project Managers, Not Calendar Monkeys:

I’ve been working on a way to balance the benefits of Gantt charts (ability to input dependencies and adjust an entire schedule with the push of a button) with the best way to communicate project schedules to clients. Most people can’t read a Gantt chart, and no client should have to. Gantt charts are more useful for planning next steps than providing an at-a-glance project status anyway.

So what’s the solution? I don’t think we really know yet. I am all for planning and knowing where you’re going, as I pointed out earlier in this post. But I think holding a team to specific deadlines isn’t the right way to increase velocity, and results in more stress than it’s worth. So what’s the alternative? I think you build (and sell to executives) a team driven by different types of goals:

• Build a team driven by priorities, not timelines. Know what are the most important things to work on, work on those first, and move on to the next thing. Have goals (that can include timelines), but realize that things can change. Trust your team that they will work towards those goals, and then knock off the priorities one by one. Of course there will be deadlines driven by external pressures, but keep those at a high level so that the team has a clear goal to focus on. This will ensure better quality (because you’re not cutting corners and rushing to get things done) and higher velocity (because everyone is focused on doing the right things in the right order).
• Build a team driven by action, not meetings. In progress meetings, I prefer to represent my team so that they can go on with their work uninterrupted. If someone wants to attend the meeting and speak for themselves, that’s fantastic, but I don’t think it should be a requirement that everyone on the team be present for strategy and update meetings. Note that this is different from working design meetings, where actual solutions are being produced. A meeting where you walk out with a deliverable (a sketch, a wireframe, a product requirement) is a good meeting. All others should be handled by the Product Manager/Owner so that the team can go about their business uninterrupted.

Speaking of which, allow me to bring in one more voice of reason on meetings, Mike Monteiro. In his excellent post The Chokehold of Calendars he writes:

Meetings may be toxic, but calendars are the superfund sites that allow that toxicity to thrive. All calendars suck. And they all suck in the same way. Calendars are a record of interruptions. And quite often they’re a battlefield over who owns whose time.

Make sure the focus is on working, not telling other people what you’re working on.

So there that is

As I read through this post again, I realize there might be some resistance to some of these ideas. Not that anything I said here is particularly new, but because I know there are several counter-arguments that can be made to these points. That’s exactly how it should be.

I’d love to get some input on this, particularly ideas and tips on how you’ve been able to deal with some of these problems. This is all a work in progress, as I assume it will be until the end of time.

This post is based on a recent talk I gave at the South African Scrum User Group, entitled Roadmap to serenity - How to stay sane as a Product Owner.

Content strategy is starting to get its much-deserved time in the spotlight as part of the user experience design family.  As basic examples of confusing/bizarre content like this one and this one show, getting serious about content is way overdue.  But I’m a little worried that we haven’t seen much talk on how to measure the effectiveness of web content.  It is unfortunate that in some companies it is still a struggle to sell the benefits of UX design, but it is the reality, so we have to deal with it.

Selling content strategy to clients and stakeholders is, of course, not the only reason why measuring its effectiveness is important. It is also essential as part of the whole design process:

• How do we select the best content if we have a variety of different alternatives, each with its own group of supporters who want to get it on the site right away?
• Since the voice of a web site can be such an abstract, arbitrary decision sometimes, how can we apply methodologically robust research methods to help make these decisions?
• How do we know that the content we wrote made a difference on the site?

So that is what this post is about — a proposal for how to measure the effectiveness of web content.

What makes content effective?

First, I would define “effectiveness” in this context as the optimization of the following three concepts:

• Do users understand what you are trying to tell them and what action they should take to be successful in their task?
• Are you invoking the desired emotions with your content?
• Does the proposed content result in higher conversion rates than other alternatives?

It’s so important to combine the user perception data (the first two concepts) with business metrics (the third concept).  From my experience the only way for user experience designers to affect change is if we can show the positive impact these changes have on engagement/revenue metrics.

Measuring content effectiveness

My proposal is to map each of the three concepts to a research methodology that is specifically designed to get the needed information:

Each of the three methodologies can be used to measure the effectiveness of different versions of the same content before it goes live, as well as measure what difference it makes once it is live.  This is also a really nice way to progressively reduce the number of alternatives down to the best solution.

I’ve written about usability testing and A/B testing before so I’m not going to go into more detail on that, but I do want to spend a little time on Desirability testing since it’s a method I really like, and I think it’s not used enough to measure design/content effectiveness.

Desirability testing

In desirability testing, a survey is sent to a large number of users where they are asked to rate one of the proposed design/content alternatives using a semantic differential scale.  The survey is done as a between-subjects experiment, meaning each user sees only one of the proposed designs, so that they are not influenced but the other design alternatives.  The analysis then clearly shows differences in the emotional desirability of the proposed  alternatives.

So, for example, you could show one group a design and ask them how they feel about it:

And then show a different group another image and ask them the same question:

When you then compare the averages of the different groups, you’re able to make an accurate relative comparison between the two designs.

Putting it all together

In summary then, to apply all of this to measuring the effectiveness of content:

• Usability testing. Start with several different version of the content (~10), along with the current version (if it exists).  Ask users in a lab setting what they understand the content to mean, and any other thoughts they have on the way it sounds.  This should help narrow down the alternatives to 4-6 possibilities.
• Desirability testing.  Use the Desirability method in a large sample online survey as a between-subjects experimental design.  In the survey, ask users to rate the content on different brand and design attributes.  This way you can determine what emotional response the content elicits from users.  You’d also be able to ask users which version of the content they’d prefer, and why.  This method has the added benefit of large numbers to give you confidence in the statistical significance of the results.
• A/B testing.  Once you’ve narrowed the alternatives down to two or three, live A/B testing can help you determine which of the alternatives perform better from a revenue or engagement perspective, by looking at differences that can be attributed purely to content changes.  This obviously works easiest when the content is directly related to a revenue-generating task, like the call to action on a checkout page, for example.  But it’s not just about revenue — there are great ways to measure metrics of engagement with the page, which is just as powerful.

Now, I can see a few issues that make this a pretty difficult task, and it’s the reason why the above three methods should not be used in isolation.  In combination, they help tell the whole story.

• It is difficult to know what users really read on a page.  In the first two methods you pretty much have to show people what to read — that doesn’t happen when they visit your site organically with no one looking over their shoulder.  This is why A/B testing is so important as it gives you a sense of how behavior will change based on content.
• It is difficult to isolate the effect of content changes from the other influencing factors on a page.  This is the really difficult part.  How do you know that conversion/engagement improved because of the content and not of some other factor on the page, like visual design changes?  That is why it is important to keep the rest of the page exactly the same, and also why usability and desirability testing is important to bring out the perceptual data from users.
• [Update] This method doesn’t scale well. When you are doing a major redesign or re-write, you can’t do this for every single change (as Eric Reis points out in the comments of this post).  The method is mostly suited for microcopy and incremental improvements once the base content has been written.

And the biggest problem is of course that this is an idealistic approach.  Finding the resources/time/money to do this for every content change is obviously not feasible.  But for high-value landing pages, in-line help, etc. this approach could be well worth the investment.

This is also by no means the only way to measure content effectiveness, but I think it’s a good approach that balances methodological rigor with the dangers of not overdoing it.  I’d be curious if anyone has any thoughts or ideas on how to improve on this proposal.

PS. Last week I discussed this topic at the first Cape Town Content Strategy meetup.  I uploaded the slides here, and you should join the Cape Town group here.