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?

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.