Laptop vs. Desktop:

• Screen sizes of 1280 by 800, 1440 by 900, and 1366 by 768 are indications the end user is most likely using a laptop.
• The 1200 by 800 is very popular among MacBooks, and the Sony laptop I’m on right now is 1366 by 768.

And something you probably haven’t thought of: laptops have outsold desktops for years.

For some sites, the majority of users may be using a laptop.

Forget screen resolutions for laying out the page, think about the indications of device type. Over 34 percent of my blog’s audience is the middle of target laptop screen resolutions. A few other sites I work with have percentages that fall in the 40 to 45 percent range. These percentages alone may be a more important number than browser audience. Seriously, who cares about the box model and CSS issues, when the user can’t figure out how to use the scroll bar?

The Bottom Line
Figure out who your audience is. A website that is aimed at developers (a desktop audience) should be designed differently than a website aimed at sales people (a laptop audience). Consider who they are, and what their environment is. For example consumers are now mostly laptop users and expert users at work use desktops, you want to design for whichever of these two fits your audience.

A lot of laptops are on old technology.

A friend of mine has this laptop that’s four years old.

That might not seem that long, but…

(pause)

(pause)

(pause)

It takes ten minutes to boot-up.

Watching that laptop trying to crank through a Flash movie or a website that’s shipping 800k down the pipe for the homepage is a painful experience. There are millions of laptops and underpowered netbooks out there in the real world, many of them held by consumers that don’t want to migrate their files to a new computer, even if they can afford it.

So they stick with their old, trusty laptop until it dies.

Some of the web analysis reports I’ve seen have shown that 75 percent of the user base is still using Windows XP, which was discontinued two years ago.

That alone shows two points:

• There are a lot of people unwilling to upgrade.
• There are a lot of people on slow computers.

The Bottom Line
Bells and whistles might not be a good thing, when considering your audience. A website that works on a web designer’s souped up MacBook Pro might not be working on an end user’s laptop with 1GB of RAM.

Using a laptop means a different user experience.

That doesn’t mean that they are always using the laptop screen, but what it does mean is they are definately using the laptop as a web surfing device. This dramatically changes their user experience. Instead of sitting up in their chair, they are looking down at their laptop, typing and using a trackpad.

I had a long conversation with a game developer about the iPad, how people use it as a window because they are looking down. Laptops are much the same way. They have to be judged within their environment, whether it is a Starbucks, an airport, or a cubicle when the user is on the run.

Home users might be watching a television show or chatting with friends on Skype, but whatever they are doing, they could be performing multiple actions in an environment that’s not sitting at a desk. Four to seven different application windows may be open, and the browser window will not be expanded.

The margin of 700 pixels becomes 600 pixels. That email you are sending for marketing purposes might only be 300 pixels wide by 600 pixels high.

Another consideration: many popup windows and dialog boxes are designed to be 700 pixels high, which are unusable on netbooks that are 1024 pixels wide by 600 pixels high.

The Bottom Line
Designing for the top left corner of a page is more important than ever before. We might have to rethink always having that branding logo there.

Certain actions are difficult on a laptop.

Get on a laptop. Then try using it without a mouse.

Certain actions are assumed to work, like using the arrow keys to scroll through a web page. This is because browser designers have built their applications to work this way. But, there are other actions that are difficult at best and impossible at worst, most of them require holding a button on a mouse — re-size a window, scroll through an editing text area, and perform a multi-select action. These actions require two hands: using the trackpad to scroll while pressing the left trackpad button. Some laptops are missing things. A lot of laptops don’t have page up, page down keys, so the users have to use two keys to scroll down.

In fact, a study performed in 2002 found that not only was scrolling 23 percent faster using a mouse versus a trackpad, the error rate for hitting the target was three times higher with the trackpad.

Trackpads change user behavior. Many laptop users, like myself, are experts at hotkeys — so much so that when I’m using a laptop, I use the keyboard more than the mouse. Actions, such as tabbing through a web form, have to work well or it’s useless. Like most gestural interfaces, if you are depending on mouseovers to indicate status, laptop users are going to be missing out on a lot of feedback, because they are trying to perform an action as quickly as possible.

The Bottom Line
Ironically, many of the same concepts around Section 508 compliance also work well for designing for laptop users. Design it so it’s closer to a keyboard-driven application versus mouse-driven application.

Consider Fitts’ law when designing for interactions.

The size of the target, when using a trackpad, makes navigation on certain sites and, more importantly, performing precise actions, hard. To drag-and-drop in a precise manner is impossible using a trackpad. Try navigating Photoshop using one. I guarantee you’ll be be tearing your hair out in five minutes.

Scroll twice, and hit a target the size of a postage stamp to sign in for personalization — that’s the challenge on CNN.com.

Targets have to be sizable, and dragging the pointer long distances is worse using a trackpad than a mouse. For example, when using a trackpad to go from one end of my screen to another, I have to scroll two separate times from the top left to bottom right corner of my screen. The same works for any direction on the screen for my laptop.

The Bottom Line
Consider distance to take an action and what that action is (for example, a social sign in, which drives a lot of traffic), when designing the page.

The study found that 30.8 percent of smartphone users accessed social networking sites via their mobile browser in January 2010, up 8.3 points from 22.5 percent one year ago. Access to Facebook via mobile browser grew 112 percent in the past year, while Twitter experienced a 347-percent jump.

“Social networking remains one of the most popular and fastest-growing behaviors on both the PC-based Internet and the mobile Web,” said Mark Donovan, comScore senior vice president of mobile. “Social media is a natural sweet spot for mobile since mobile devices are at the center of how people communicate with their circle of friends, whether by phone, text, email, or, increasingly, accessing social networking sites via a mobile browser.”

All channels, all devices, baby.

• 30% of smartphone users accessed social networks via mobile browsers — this was up from 22.5% in 2009.
• Total social networking access via mobile browsers on all mobile phones rose to 11.1% — this was up from 6.5% in 2009. Most of this growth was in the uptick in smartphone usage.

How does MySpace survive if their mobile-centric audience uses their mobile site less?

On top of everything else happening in the social space (Google Buzz, everyone leaving MySpace, Facebook changes), this happens: Facebook Patents The Newsfeed. You can read the full copy of the patent here.

Now before we all have a “What the hell moment,” here are a few things to remember:

Some patents are virtually unenforceable.

Various companies have patented the shopping cart, the GIF image, the one-click purchase and the affiliate program. The one-click purchase made Jeff Bezos look like a fool for a while, especially after they went after Barnes and Noble.

If you haven’t noticed, none of the above are really enforced except for the GIF image patent, which there’s “sometimes” a $5,000 licensing fee. Unisys at one point threatened to go after every website that had a GIF image somewhere on the site.

That was popular.

A few patents, like the one-click purchase and the affiliate program, have given rise to protests and eventual defeat of a lot of the claims Amazon had over the business process. Most of those patents are violated every second of the day because they are ubiquitous and so mainstream there’s no way to enforce them.

Some patents are more for defense against large competitors.

While it doesn’t make sense for Facebook to sue everyone, I’m sure they’re thinking about what they can bring up against Google, MySpace and a few other large properties with a newsfeed.

Other places are probably thinking about how to re-architect their solutions now to avoid any patent infringement. That said, if you’re running a site that isn’t one of the top 1,000, I don’t think Facebook is going to be sending a lawyer your way anytime soon.

Some patents are for getting money out of people and for increasing market value.

One of the few points people forget about Google is that the concept of AdWords wasn’t invented by them. It was patented by GoTo.com. I’ll admit that Google does it much better than GoTo/Overture ever did, but it was enough of a threat that Google eventually settled with Yahoo!, who had purchased Overture.

The lawsuit against Google related to its AdWords service. In February 2002, Google introduced a service called AdWords Select that allowed marketers to bid for higher placement in marked sections – a tactic that had some similarities to Overture’s search-listing auctions.

Following Yahoo!’s acquisition of Overture, the lawsuit was settled with Google agreeing to issue 2.7 million shares of common stock to Yahoo! in exchange for a perpetual license.

That patent was probably one of the reasons why Yahoo purchased Overture. There are holding companies whose purpose is to hold patents. However, they are selective about who they sue because lawyers are expensive. It’s an ROI equation, and there’s no point going after someone without money, right?

GigaOM says:

Friendster, which was recently bought by a Malaysian company, made much of the fact that had obtained five U.S. social networking patents, at times using the patents to scare off the competition, at least in the press.

Scary.

Some patents are declared invalid.

The U.S. Patent Office grants a lot of patents. It doesn’t necessarily mean they will stand up in court. Gibson Guitars has been on a rampage, suing anyone that produces music simulation software like Guitar Hero. Read more here.

They have yet to win.

What would happen if Facebook went after MySpace in court, and the patent was declared invalid?

What if a single social network invented before Facebook had the same implementation, and Facebook was in violation of the intellectual property of that website? Would that company win $500 million like when Microsoft was sued over the browser plug-in?

GigaOM points out:

The patent is particularly valuable because news-feed style communication has become pervasive since it was launched on Facebook. However, it’s not clear that there aren’t precedents for the technology; for instance, the social network Multiply.com had a similar interface for keeping track of friends’ actions before Facebook launched its own.

Mutliply.com suing Facebook? That would be fun.

What next?

As big as a deal as this may seem, it isn’t until they do something with it. For now, it’s just another asset they have in the universe of Social Media.

But should they?

That’s a hard question to answer, especially with the ever changing landscape of the industry.

The answer: it really depends on where you live and what you are looking to do. Many employers are looking for jack of all trades, while others are looking for specialists. Some are willing to give up deep skill sets in one area versus knowledge in all areas, or are looking for people of unique skill sets to build teams around.

A UX Designer in San Francisco is going to have a much different working experience than one in Columbus, Ohio because they will be much different companies.

I’m lucky to have worked in both generalist and specialist environments, and to be honest, I like getting my hands dirty sometimes. That includes building prototypes, doing my own guerrilla usability testing, and even throwing in some design to make it high fidelity. Other user experience designers like to focus on specific areas, like user research. It just depends.

If you know something about code, you’re less likely to design something that can’t be built.

The plus — there’s nothing worse than designing a solution that you think makes it really easy for the user, and then the programmers come back to you and say, “Well, that’s nice, but it’s going to take two months and we have only a month.” It’s like designing a car: if you design an engine that’s too big for the frame, the engine design has to be reworked.

The minus — that said, if you get too heads down in the code, you are going to be less effective as a user experience designer. Or, worse, you could limit your imagination and design a solution that would be more effective if you knew less about what was under the hood.

Specialists get paid more, but have fewer opportunities.

The plus — Everyone loves a big paycheck, and specialists are always going to have deeper knowledge of a particular topic. If you’re good, being a specialist means that you’re sought after. I have a lot of experience in e-commerce systems, for example, and somehow manage to improve those user experiences that lead to improved revenue. That’s a skill worth having that will make you valuable just about anytime of the day.

The minus — If they think you are too much of a specialist, it becomes really hard to get a job (“I didn’t know you could do that”), and in a bad economy, the last thing you want to do is fence yourself in. Those that were working in the field during the early 2000′s remember the day when being a project manager or a psuedo-programmer was a good thing. There’s nothing worse than being “just” a user researcher when they are looking for an Interaction Designer with research experience.

Sometimes it’s just about setting expectations.

Pros — Even if you don’t call yourself a specialist, putting a wider net out there for jobs is better because there may be a position that requires several different skills (Knowledge of JQuery, CSS, XHTML and some light design on top of doing the usual User Experience tasks like wireframes). This could translate into where you build functioning prototypes that the developers can use to build the finished product, but during the interview process. That said, I just recently started learning SketchFlow, a wonderful product that’s part of the Microsoft Expression Suite. There’s no way I could have picked it up as fast as I did without some knowledge of other prototyping tools like Flash, Axure and Visio.

Cons — Some skills required for the roles are so divergent that what they are looking for is a unicorn i.e. that one person that knows all of the above, plus ActionScript 3.0, plus .NET. The people that know all of those technologies either are a) getting paid much more than just being a User Experience Designers, b) do all of them poorly or c) are full of shit. You can only be good at so much.

The real answer? Look at the market and act accordingly.

Do what you have to do, and where you want to drive your career to, to succeed. Talk to other designers in the area to get an idea what they are doing. And remember, it’s a changing landscape — that requires some flexibility.

Make it Easy to Scan

People don’t want to wade through what appears to be a short novel. If the mere site of your written piece overwhelms the reader, you can bet he or she will quickly move on to something else.

• Recommendation: Put your headings and subheads in bold type, use bullet points, left justify your text (don’t center everything) and break things down into short, easy-to-manage paragraphs.

Avoid Giving Readers a Headache

Have you noticed that an increasing number of websites are composed of tiny little white letters set against a black background? Ugh! Instant eyestrain.

• Recommendation: For maximum readability of any written piece (not just websites) stick with dark type on a light background, and don’t use anything smaller than a 10-point font.

Think about Your Font Formats

Sometimes it works to use special formatting to call attention to particular words, but if you’re not careful you’ll end up making those important words difficult to read.

• Recommendation: Go easy on your use of ALL CAPS, italics, underlines, Initial Caps, and other special formats. These all work well on headlines and brief items, but should generally be avoided on longer passages.

Remember, if your letter, website, brochure, or other written piece isn’t formatted for maximum readability, there’s a good chance it won’t get read at all.

…after one of those sessions, I had dinner with friends, and they started talking about was an online shopping experience. The exact feature set the developer wanted to add, my friends basically said it over complicated the process, and made it hard to complete the purchase (I’m going to hide the name to protect the innocent, but it spelled close to Mike, and they sell, uh, shoes).

Note that my friends use technology all the time, but aren’t experts. They are, however, are consumers and are am important part of the new economy. They are typical users that make user experience experts a need. The one site example is cited a lot (well, Amazon does it), but in very few instances does one site make a competitive analysis across sites in the target audience.

So what do users really want?

User experience and development professionals aren’t the ones that should be suggesting all the bells and whistles, so here’s a list I’ve compiled in my head of what I thought users wanted.

Users want the message to be clear

So many websites try to be clever and cute with the tagline, mission statement and other information that they are never clear why the website is up. The best approach is to have a name that is clear and concise, or to create your own brand (Amazon, Google) so you’re name can show up in a dictionary.

For the rest of us struggling to find a website URL that fits our business model, the other approach is to make it clear on the home page what the website is about. Put plenty of hints (like better copy that the outsource website designer can write) so your users have no question about your service or site goals.

Is it an ecommerce site?

Do you provide services?

Are you trying to get people to sign up for something, so you can contact them?

Then state it! Make no bones about what the site is about.

Users want context to see if they fit

Once the user gets to the site and reads the message, they’ll get a better idea if the site or service is for them. Do you patronize a doctor when you have an eye problem? No. So those customers lost are a good thing, because that means that your resources won’t be tied up answering their questions.

How users evaluate a website after making sense of it:

• Is this a service I need?
• Do I see enough value in it (time, money) to use it?

That’s it. If you provide them with enough context to make those two decisions, you’re golden. In the end, users are a pretty simple bunch.

Users want consistency

One of the general rules about user interface design is that a consistently bad interface is better than an inconsistently good interface, because at least users know what to expect. That’s the theory of user interface patterns: use generally accepted methods of navigation (except when you know when to break them), and users will implicly recognize what you’re doing without knowing the science behind it.

That said, users don’t care about user interface patterns. They aren’t going to scream about your use of radio buttons versus tabs, they’re aren’t going to leave the site because you used a checkbox wrong. They will leave the site if the navigation moves around and appears in different places on the page, or get frustrated because they can’t find something.

Users want to be heard without having to shout

The 2 or so million Facebook users that complained about the new user interface were a vocal bunch, but they probably aren’t the most important group. When most people are unhappy about a service, they don’t join groups and send messages like that, because most people have don’t have that much free time. Sometimes the squeaky wheel is the wrong wheel.

They do the obvious thing — they leave the site. (Note MySpace’s leveling off of traffic — that’s the best example I’ve seen in a long time of a site not working for its users).

Happy users return. Sad users leave. Get it?

Users don’t want the shiny (unless it’s in context)

That e-commerce website I was talking about used a heavy amount of Javascript, Flash and other Web 2.0 technologies that translate into a richer experience. However, even on my megafast download of a pipe (I think I’m geting 20 down on a regular, sustained basis), the site is slow. Very slow.

Slow translates into lost sales.

Shiny is great, especially if it’s in context — YouTube and some of the music sites are great examples — but they are also barriers for users. They might not have the right plug in installed. They might be on a slow connection. They might have a computer that belongs in the Smithsonian Institution. More often than not, there’s a reason not to use heavy Javascript, Flash and SilverLight than to use it. The shiny is cool, but only when it makes sense.

Users want to be guided (without being guided)

One of the general rules about website usability tests is that you almost never listen to what users say, it’s always what they do. That said, I can’t tell you how many times I’ve been through a test where the user absolutely felt stupid using the service or product, mainly because the site wasn’t intuitive enough

Help text generally doesn’t work. Big long Flash introductions don’t work. Dancing flash people don’t work.

What does work are sites are are intuitive enough and forward thinking enough to provide a path for the user to go. The elements of user experience should be defined enough so the site acts the way the user thinks it should act i.e. the user shouldn’t have to learn it, especially for consumer facing sites. It’s about predictive user experience.

My first experience with Agile was April 2001, and I’ve run several projects with it since. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).

The result? A profitable company with a profitable product.

Three of the projects I worked on went by the wayside. There’s no accounting for issues with company culture. However, five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.

This first thing I’m going to do is define Agile development so we’re all on the same page.

Agile methodologies, or cultures, generally have the following:

• Short development cycles of two to four weeks and are usually called iterations or sprints depending if you’re using Scrum or Extreme Programming.
• Almost daily communication through short meetings, called standup meetings. They report what you are working on yesterday, today and tomorrow so any issues can be discovered early. The purpose of the meetings is to encourage further communication offline. Therefore, meetings are short. If you’re going over 15 minutes, it’s too long.
• Development progress that is measured through what’s called burndown and the product backlog.
• Clients, or product owners, that are intimately aware of progress and prioritize based on product needs. Everyone has a voice in what the product is.
• A process that is adapted to the team. They own the process so they get to use elements that work for them.
• This is key: people who are upfront about their responsibilities and don’t hide their roadblocks.

It’s also key to note that I used the word “generally,” because the process is defined by the teams that use it. So, some may only use elements of Agile and Scrum.

I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.

But for the web, where everything is changing, it’s great.

Here’s how to convince most User Experience teams that Agile can work:

You get direct access to the developers

One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.

I’ve run a Scrum-like process over the phone (I’m doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.

If there’s an issue of the design not working the way you want it to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.

While you don’t get to do as much research, what you do get is to see your work in action sooner

Waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before developing wireframes, or user stories, and that’s okay. Unless you’re inventing the new iPhone, why would you want to do that?

Usually you develop a lot of areas with stubs (i.e. “We’ll do that later, but just put a page there.”) and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt; and, in some ways, it doesn’t allow you to over think a feature.

From Agile Product Design:

User experience people working on Agile teams become masters of development time travel, nimbly moving back and forth through past, present and future development work.

You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.

Agile doesn’t mean no requirements. It means requirements that work for the team.

Since the team decides how to build the process, that means the requirements can take whatever form the team wants them to take. If you can’t do wireframes or HTML mock-ups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it, beacause how many times do we need to redesign a lost password process?

I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format; talking through a feature instead of looking at it in a PDF is a much more effective way of communication.

To mitigate direction issues, what I did was develop a really high level style guide to make sure we had a holistic view of the system, then did not annotate wireframes. The developers knew just the form or text elements; and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.

Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.

If there was particular communication that we felt wasn’t needed, we would cut it out of the process. Who  reads all the requirements, anyway? Usually just the User Experience folks do, while arguing with the developers. That’s an important distinction. If management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools; it’s about the people using them.

If your initial pass doesn’t work, it’s not stuck in the final product.

While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing. That means you have to bring in or find some test subjects to throw against your ideas. This does not mean you should write formal reports, (there’s not enough time for that) but it does mean you should do enough testing to make sure your product is going in the right direction. You won’t spot every issue, like rocks and sand: you’ll catch the rocks and have to worry about the sand later.

It allows you to fail quicker. If there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.

The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s worth of work or less.

Smart Agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development. Developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on. They spot potential issues even before the developers do.

On a few projects that I’ve been on, we saw a 50 percent drop in defects reported and had fewer reworked features.

That’s huge.

You can see progress almost immediately.

One of the biggest frustrations of working in software development is waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show results, developers can agree upon delivered features after the first iteration.

This creates a sort of washing machine effect to gathering requirements  and software development. You keep moving toward a common goal of building the final product. Instead of seeing huge leaps of functionality with possible huge leaps in missing the target, tasks are built in bite-sized chunks so you have a better idea of meeting your goal. You also get an idea of whether or not your estimates for building the product are on base, and what you have to adjust before.

It’s about making it to the finish line, one inch at a time.

The 80-hour workweeks are gone… sort of.

One of the rules we had at Escrow.com is that no one worked over 45 hours a week; and if they did, I kicked them out of the office. Two similar projects that I worked on had the same approach.

This was very important from a few standpoints:

• Developers and User Experience designers without a life are angry people.
• Tired developers are ineffective.
• Estimates only are effective if there’s a decent control mechanism.

The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? How good was that product, really?

Doing estimates well is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.

At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.

That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.

Your voice is heard, period.

One of the greatest things about Agile development is that everyone has a voice. That means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.

There’s always a user advocate in the process of building the product.

The conculsion

Agile isn’t for everyone; however, when it does work, it works well. It does require a different mindset, and there are flaws to overcome.

Random Thoughts mentions the following downfalls:

• Loss of the holistic view of the system
• No time to prototype everything before development starts
• Lack of extensive requirements
• More development teams working simultaneously, same UX resources
• Fast delivery means less time for testing and iteration
• Loss of time for user research projects and general research and development
• A need to track UX worth and work before a project is completed

I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.

Some other links:

• Scrum Club
  
• Agile UX

Blog posts:

• 10 key principles of Agile Software Development
• Twelve emerging best practices for adding UX work to Agile development
• Jacob Nielsen Speaks (Because he’s selling something)
• The missing piece: how interaction design can add to Agile

The takeaways:

• First, while it may be necessary to scale back on an ambitious UX plan during a recession, there’s no reason not to expand efforts to enhance the personalization of services; this may be the best time to connect with customers.
• Bad customer experiences actually end up costing the organization more because they waste time and require extra work to make up for foul-ups and problems.
• User experiences and the design of them is a low-tech proposition.

Heads up to Putting People First for finding the article.

I think one of the hardest parts of explaining the User Experience process is how it fits within into the complete software development life cycle, especially in a consulting environment.

Clients want to know how to limit costs, developers want to know when they’re going to get in documentation, and your boss wants to know what you can bill for (remember, wireframes are deliverables). Some of the process is very new for developers that have been working in software for a while. Or, as one CTO said to me, “You know, you guys changed the process on me.” And he had worked in an agency environment. And I had just recently worked with a couple of agencies that know they needed to start paying attention to it, but didn’t know where to start.

This is a document I developed at my previous company to explain the User Experience process not only to clients, but internally within the consultancy, and it helped greatly show that we were following some kind of process (Well, I tried to, but you know how that goes on some projects).

I included where sales came in, to further illustrate the point that User Experience extends even into the sales process because a good Information Architect or Creative Director can sell the concept, and a final review with the developers, to fix issues that came up. A lot of consulting engagements lend themselves to a waterfall process because of fixed costs, so that’s what this is modelled around.

What’s the process you follow at your company?

Example: today’s US Air 1549 flight that crashed into the Hudson River. The Miracle on the Hudson, they’re calling it. I don’t think it’s so much a miracle — it’s a job well done.

Airbus and Boeing spend millions of dollars in analysis to make sure the user experience of their airplanes is easy to use, and can be used in just about scenario, including this one: a bird strike causing an engine failure.

The user experience from allowing the pilot to land the plane in water to getting every single passenger off the plane before it sank is meticulously planned and tested, over and over again. It’s not just a miracle that they survived: it’s intense planning and testing that allowed for this to happen, like a movie script.

Most of our jobs don’t have a life or death aspect to it, but sometimes user experience is life or death. Think about this: there hasn’t been a major airline crash in the U.S. in seven years. That’s amazing, if you think about it. Good user experience plans for user mistakes and eliminates risk. This is the perfect example.

Congratulations to the pilots and the engineers at Airbus for a job well done.

Too bad for Boing Boing — bad timing.

They also talk about User Experience about being about the business. They should remind some Information Architects about that part too.

I’ve been receiving inquiries about posting jobs here. Because of this, I’ll be posting new opportunities every Monday. Some of them aren’t pure User Experience, but they do have some kind of User Experience or SharePoint slant to them. If you see anything here, or are looking for a job, send me your resume at jobs@usabilitycounts.com. Recruiters, also send along a note, I’d like to offer the blog as another channel.

Senior Level Front End Developer, Southern California

The opportunity

A stable financial services company is looking for a Senior Level Front End Developer with three years experience to join their web applications development team. The company provides financial advice and tools to their customers, and is well positioned to survive to current downturn in the financial market. They may consider the right candidate if they have experience in a J2EE environment and are looking to expand their skill set.

The position is full time.

Requirements

• Rich Internet Application (RIA) development experience, preferably with AJAX, Flex or Flash
• Experience with Java Server Plages
• Experience with Actionscript 2 and Actionscript 3
• Advanced HTML, CSS and CSS-P skills
• Advanced JavaScript skills

Pluses

Background

• Good communication skills
• Advanced technical leadership and mentoring capabilities
• Well versed at working with User Experience teams and processes
• Experience working in a corporate environment
• Proven track record of delivering innovative solutions

Pay Range

If I’m working with a client who has an idea for a site or application but he/she can’t identify the target audience (i.e. users of the site), I sit the client down and ask, “So who are these people that you want to make money off of?” The client usually doesn’t know. In an effort to define that audience, I do so with personae.

How important are they?

Your target audience affects almost every decision you may make for a website or application.

This includes technology selection, look and feel, interface design patterns to use, and the tone of voice the content may take. Personae are used by the business owners to define their target audience and can be used for understanding the application. It gets everyone up to speed from designers, information architects and developers to business users.

The personae may even affect whether or not you do the project at all. If your web application can’t meet the needs of the personae, is it really worth spending money at all?

Personae are used to enforce the spirit and direction of the application; and more often than not, are the foundation of a website or an application design.

What Is a Persona?

A persona describes a fictional character, or who your target audience is. Usually, personae describe five typical actors that cover 80 percent of the site audience based on demographics that can be ascertained from what the site is or what the competition already has. Sometimes that can be hard, especially if you are starting service that no one’s ever seen before or are defining a new market segment. For other projects, the personae are easy to define.

Take the Apple iPhone versus Google’s Android G1, for example. Who are using these phones? Does open source or cost of applications affect the customers’ buying decisions? Do they need or not need keys on their phone? So they like slick versus ease of use? All of these details would be used to describe the consumers that may, or may not, fit the personae required for your project.

Why You Should Create Personae For Every Project?

The biggest issue I’ve seen with many of the consulting and internal projects that I’ve worked on is that we didn’t have a single document describing the target audience for the website or application, because the client hadn’t done any market research. Usually, the client or the company wanted a website, and we built it regardless of whether or not it fit the target audience.

In absence of studies and other detailed information about target audience, personae are the first attempt to define a target audience and, thereby, any decisions made about features and functionality. In a few cases, the personae further defined the project that we were working on and those definitions radically changed the direction of the application or website. As a result, the feature set changed drastically.

Clients forget their audience shouldn’t be everyone, because an application designed for everyone fits precisely no-one. Think about it. Just how many 90 pound children like wearing an XXL t-shirt? Now, imagine telling your client this approach wasn’t going to work at all. That’s a fun conversation to have.

Personae not only define how the target audience should be approached in human to computer interactions but the complete brand experience. How you speak to a person with limited computer knowledge versus an expert is very important, even in email and customer service communications.

The personae can be written by the client, the web designer or the programmer. Usually, they are constructed by the information architect or business analyst. Most importantly, personae should be created by a key figure who has an intimate knowledge of who the design is targeted toward and can communicate each persona to other team members.

Who Should the Personae Describe?

Once we have five typical users selected, describe them in semi-fictional detail:

• General Information:
  • Age
  • Ethnic Background
  • Occupation
  • Education
  • Home Life
  • Lifestyle
  • Activities
• Web Usage:
  • Web Competency
  • Frustrations with the Web
  • What kind of information is hard to find
  • Frequent sources of information
  • How they find the website
• Why/How Barriers
• Typical Use Cases

It seems like overkill; but typically, we are able to fit this into one page. The amount of information to include should be enough to be intimately familiar with the personae as friends but not too much to overly define them (like, do they drink Coke vs. Pepsi?). For fun, attach pictures. Your co-workers and clients will identify with them as a target audience easier with a visual representation.

I like injecting a bit of humor here, because people inherently have a sense of humor. One project I worked on, we named the personae Jim Coder and Johnny Bedroom. After a few weeks, the personae became so ingrained that the developers used them in conversations. This approach defused a very stressful situation and made the project more fun.

If you can get each persona on one page, post it on the wall — everywhere!

Even the smallest websites benefit from at least sketching out who the typical users are.

Another project I worked on was a shopping cart for niche aftermarket automotive parts. The products covered six years of a specific make and model manufactured by an American automotive company, and the site was targeted as such. This is a potential audience of no more than 100,000 people, but very targeted. The result? The site had a mailing list of 6,000 members, and the owners sold the company for a huge profit.

Where Can You Find Information for the Personae?

One of my clients had the information needed to start detailed personae. The client provided us with reams and reams of reports based on focus groups that the company had done on their audience. Their target audience was a few hundred thousand people. Additionally, there were resources online that further defined who the client was targeting. The research did not extend to psychographics, but it was sufficient enough to affect project approach and design.

The result: detailed personae that the team could use to match just about any user. This included being able to walk into any bar or restaurant in the website’s targeted location and identify if patrons were the target audience and which persona they fit.

For most projects, this is not the case. The best way to go about creating personae is to sit down with the stakeholders and ask them, “So, who’s going to use this application?” After defining a target, use anything you can find such as web reports, similar applications and market research to further categorize personae.

If you are really lucky, meaning the client has money to pay for this, you get to do contextual interviews such as watching in the target market in its native audience. This can be everything from watching for just an hour to diaries full of daily activities. Most imporantly, figure out what the target market is doing, not what it is saying, by watching its tasks.

I usually research websites that are close to the feature set but don’t completely match what they are developing. For internal projects, we model websites after some stakeholders who we met in face-to-face meetings, changing the names and ages of the personae to protect the innocent.

What Happens If Personae Aren’t Defined?

Good question. What happens if you don’t know what the target audience is, and the application built doesn’t meet their needs?

There are studies about the failures of software projects and not all of them are due to inability to meet the target audience; but if ten percent of them are, how much money are we talking about? Millions? Billions?

I’ve been involved with a lot of software projects, and there’s nothing more frustrating than a project that goes off the rails and doesn’t meet the needs of the user. Money is wasted, time is lost, and we’re non-the-better for it, other than surviving another frustrating experience. We do learn from our failures, but we should have more successes.

But here is a better metric to use. A Standish Group survey found that the number one reason IS projects succeed is because of user involvement, stolen from Classic Mistakes Enumerated. That’s an old study, but think about it. If the target audience gets involved, projects succeed.

Number one reason.

End of story.

So, just how important is that target audience again?

Other Resources

• I’ve included a template persona to start from. Download it here.
• Our tax dollars have gone to a really good resource over at Usability.gov.
• George Olsen has a good article on Boxes and Arrows about personae.

No matter what, your site is the first thing your users see, and in effect your brand; a true brand will build loyal customers

I buy way too much photo equipment. Way too much. I got some high end lenses, the prosumer Canon 5D body. It’s fun stuff.

For lighting equipment, I want to buy good quality stuff, but I don’t want to break the bank, so Alienbees come highly recommended. They are a company based in Kentucky, and their customers rave about them.

Most importantly, they know who they are, which is more than I can say about most of the customers I know.

Their website isn’t the most attractive site on the planet; however, it’s really easy to use, and reflects the personal nature they use when dealing with their fanatical customer base. No elaborate graphics, no flash, but there’s a simple shopping cart that’s straightforward.

The site has this clunky, midwest feel to it, but that’s okay, that’s who they are, and they even include links to other vendors for products they don’t have. It’s a true resource for the camera buff.

They are religious about customer relationship management. Keep it simple stupid is their motto.

How religious about their superior customer service?

I had one of their flash packs die on me. I used their website, called their customer service, and was connected directly to their tech person. He explained the issue in English, that it was a bad transistor that’s been showing up in some of their recent products, and that they are making their best efforts of keeping their customers happy.

He said, ship it, we’ll have it out back to you the next day.

I did, they did. I received a phone call, an email notice that it was on it’s way.

How often do you see that?

Don’t Let Business Needs Get In The Way Of User Needs

Yeah, I know, we all have to make money on this thing, but one of the most annoying things about CNN.com is that the search box is set to default to the web, specifically Google.

But what if I want to search CNN.com?

When it comes to the web, I figure I’m smarter than the average bear, but it took me a couple of tries to figure out what it was doing. and that I had to click on CNN News above the search box to change the search. Not only is the indication of status above the search box weak (the links are bolder than the status), but for the millions of users that use CNN, you would think they would be able to make enough money on advertising not to perform this standard web trick.

This is, in essence, like a porn site: let’s hide the link so we can make some more revenue. Additionally (and I’m going to call Google out on this), this dirties the reputation of both CNN and Google because you and I know this was part of the business deal. Some lawyers got together and figured out a way some extra revenue.

I know this isn’t an isolated case. Another conversation I had with someone that works with an even larger site that also has a deal with Google said that the search engine practically monopolizes search, and in essence, it hurts the user experience of the whole site because of the legal terms of the revenue deal.

User needs should not be adversely affected by business needs, and the user experience of what we see here is affected actually that.

If you are making changes to your site to generate a few extra clicks, you’re in the wrong business. Users see through that, and it will affect your business.

For me, this didn’t happen overnight. I stopped obssessing about whiz-bang interfaces and took an active interest in helping clients think about design in terms of return on investment. Because I always spoke my mind and articulate ideas in terms of how they drive the bottom line, clients began to include me in strategic meetings. Below are some of ways I incorporate strategy focused activities into my process.

Propose the Value Proposition

When I first consult with new clients about a project, I let them know that analysis and research are an integral part of my process. It allows me, the UX designer/Business Analyst/IA Minion to understand their business from the inside out. I explain that analysis, interpreting metrics, product roadmapping, etc. can optimize return on investment. By interpreting indicators on usage patterns, we can pinpoint what’s not working and leverage winning features. The result is a cohesive product vision that differentiate the client from their competitors.

Speak About the Project in Business Terms Not Usability Goals

Articulating your design in business terms is a great marketing strategy. Before my first formal meeting with the client, sometimes even before the contract is signed, I always conduct a quick site audit. This gives me a fresh perspective before I know anything about the project and clients love a fresh perspective. I record my impression on branding, business objectives, and how well the design and implementation drive the business objectives. I always think in terms of return on investment. This gives me fodder to speak about the project in business terms as opposed to design terms. Incidentally, if I get the contract, I bid the hours I spent back into the job. If I don’t get the contract, then it’s good PR.

Request for Quantitative and Qualitative Data

Request for reports at the first meeting. Be prepared to explain what trends and patterns you hope to discover or why you want look at data for specific feature sets. If you don’t yet have an idea which reports you need, tell the client that you will email a list of reports that you want pulled. This lets the client know that research is an integral part of your process. It the project is a start-up, conduct topic and keyword research to define search volume. For qualitative analysis, inquire to see whether any surveys or focus group testing have been conducted and what the findings were.  Finally, ask the client how or if the business has responded to the results from analytics and surveys.

Prioritizing Requirements and Use Cases

Don’t be a gatherer of requirements. Be an expert. When conducting interviews with stakeholders, don’t just gather requirements. Work with clients to prioritize requirements and use cases based on business objectives and the research that you’ve conducted. You may propose new requirements to refine and simplify workflows.  Always couch your input based on business objectives and the bottom line.

Use Business Objectives, Usability Goals/Strategies as the Measuring Stick for Your Design

I always preface wireframes with business objectives and usability goals. Clients gets sick of this after subsequent meetings, but they learn quickly to evaluate wireframes based on the real business goals. This is also helpful when your wireframes are circulated to other team members, because the business objectives and usability goals is a reminder of the foundations of the project.

If you have an online store, whatever you are selling represents your brand

So I found myself with a few more hard-earned extra dollars, and schelped my way down to Best Buy. I looked through some home theater systems, and found one that I thought I would like, a Yamaha system. I bought it, stuffed it in my car (it barely fit), and tried unsuccessfully for hours to set up the system.

I’m not an electronics geek (and please don’t assume so, just because I wrote a blog). It’s like being a doctor — you’re at a party, you say something about being into technology, and pretty soon, everyone is walking up to you telling you about about their broken cupholder on their computer. I have the same problems everyone else does, and did so with this system.

Not only were the instructions too long, but it was just a hard to use product, and I imagine there’s some MBA in some office somewhere at Yamaha thinking, “You know, if we make this hard enough, Best Buy can make some extra money off of Geek Squad.” These same MBAs compute all kinds of numbers regarding return rates, and they fully expect a certain amount to be returned because they are just hard to use.

From a product management perspective, I would think it would be cheaper to make a product that would be easy to use because there would be a lower return rate — Apple gets this, and to a certain extent Microsoft does, because their consumer products are not too bad to install — but what do I know? Best Buy doesn’t care, because in reality, returned product is the responsibility of the manufacturer and not the retailer.

Because I bought it at Best Buy, my though process is, “Yo, Best Buy sells lousy products that are hard to use.” I know this isn’t the case, but I decided just to return the system, because I wanted an easier system to use. If I couldn’t install it, how am I going to be able to change it?

Your policies can be your own worst enemy

So I schelped back to Best Buy (a different one, because the first one was closed early on a Sunday), removing the system from my car (did I mention it weighed over 50 pounds?), and got to the return desk. I had a new system picked out, and was so close to buying a new system when their customer support manager came over and said to me, “Yo, you have to take it back, because there isn’t a remote control with the returned system.”

“You mean I have to stuff this thing in the car again and come back to get a refund and/or exchange?”

“Yes, because our policy is that we don’t want anything happening to the system. If it were to happen, we don’t want it to be our responsibility.”

The store policy is I couldn’t leave it there because they didn’t want to be responsible for what could happen in their store.

(Read that again, just so you get the full effect.)

Customers don’t care about policy — they just want to be happy that their dollars are well spent, so if you implement policies regarding returns that make it hard to return merchandise, or your systems make the users jump through a bunch of hoops, they will not become return customers.

I left the Best Buy and drove directly to Target down the street and picked up a Bose Home Theater system that was more expensive, had less features, and took me exactly 10 minutes to set up without a hitch.

Because of their policy, Best Buy lost a customer on a higher margin sale and I was willing to forgive them for the previous misstep of having a product on their floor that was hard to use. This is because not allowing me to return a $5 remote control a day later.

Whatever you do, don’t make your customer feel stupid

So that now I am perfectly content with my new Home Theater System, I returned to Best Buy to get my money back. Hell, it’s nearly $400 with taxes, and I just wanted this box out of my back seat.

I get there, I have everything I need to return it, and the cashier makes the dreaded call to the Home Theater department for a consult.

The sales expert walks over, looks at the system, looks at me, and says, “If we set this up, and if it works, will you take this back with you?”

“No, I just want to return the system, I spent too much time on it already.”

“But if we set this up…”

“You don’t understand, I don’t want the system. It’s too hard. I just want to return it.”

End of conversation.

The point: if a customer is unhappy with a product or a website, you’ve lost them. You can’t get them back with this approach, because it just makes them feel stupid. Customers want to buy a product and me done with it; if it turns into a long, drawn out experience that requires too much support, that’s a product they will never be happy with.

Well, duh.

Not to further point out the obvious, but whenever a company touches a customer, it’s a reflection on the brand, whether it be through a website, a commercial, or the actual product. Phenominal User Experiences with the correct amount of Marketing bring profitability (read: Apple’s record quarter of Mac Sales, Amazon’s success as a retailer, eBay’s branding as the world’s largest garage sale).

Again, it’s not just a technology thing — the company has to live and breathe it.

It’s all a reflection of the brand.

After that explanation, during which her eyes glazed over, the response was, “How about just telling me what books to read.”

Here are five books I like a lot.

Note that none of them (well, one) is written by one of the user experience experts that are most often cited in blogs. There are many authors out there that present equally valid points that should get equal time, and I found these books to be extremely useful and valuable. Most of the books describe the patterns and theory of information architecture and user experience, but a couple of them go into detail about the tools we use to communicate, and how we fit into the software development and web design process.

The last five books I would read if I wanted to learn about information architecture

Why We Buy: The Science Of Shopping

By Paco Underhill, Why We Buy is a great read on the observational study of why people shop, how they shop, and what they buy. Most importantly, it sets the stage for triggers for the motivations of completing an action, which is the basis of all interactive interactions.

This book is not too scientific, but honestly, you can look other places for that; what we’re seeing through the eyes of Paco is the emotions of browsing and shopping in the real world.

Don’t Make Me Think

By Steve Krug, Don’t Make Me Think is the cut-and-dry version of information architecture and the best methods of web navigation. Covered in 216 pages are enough screen shots, design patterns and quick points that just about anyone can get started on building their own websites or improving them dramatically.

What I like most about this book is that Steve doesn’t talk down to the reader like some other specialists, he informs the reader in a very comfortable, friendly tone.

Designing Interfaces

By Jenifer Tidwell, Designing Interfaces most importantly shows exactly what is most important about designing software and web sites: that all applications should follow a very well defined set of a patterns so the user interactions follow exactly what the user expects.

Jenifer’s book goes into excruciating detail of what interface widgets to use when, and why the widget should be used, how to use them, and examples of how the widgets were used in other applications.

Web ReDesign 2.0: Workflow The Works

By Kelly Goto and Emily Cotler, Web ReDesign works through not only examples of wireframes, site maps, and how to quote projects, but looks at the project management process of web development. What I like best is that the book shows exactly how Information Architects, Web Designers, Programmers and the client fit together in an orchestra of what happens before, during and after a site launch.

Kelly and Emily also do a masterful job of including other expert voices and opinions like Christina Wodtke and Lynda Weinman about what it takes to launch a successful and user-friendly website.

Grids for the Internet & Other Digital Media

By Veruschka Götz, Grids is a out-of-print but very valuable publication that goes into amazing detail about the usage of grids for interactive applications (not just the Internet but also for multimedia applications and print design).

The book also covers the lost art of typography, how it should be used in websites, and usage of type on a grid. Even if you aren’t a designer, you’ll appreciate the clear and concise examples displayed in a very modern fashion of this title.

Netflix, the DVD-by-mail service, largely ceased shipping DVDs to its 8.4 million subscribers for three days this week. The company vaguely blames a technology glitch.

Yet, as a result of the mess — which was resolved earlier Friday — customers are now applauding the company’s honesty. Its stock, as of now, is up on the week, not down. Just imagine if McDonald’s stopped serving burgers for three days.

So what are the lessons for other companies, and for people who follow Netflix’s business?

That saying you’re sorry is okay. Read on…

Other sites that agree:

• Electric Venom
• Hacking Netflix

When something really bad happens (say, your site goes down for hours or days like eBay, Amazon, and MySpace have all experienced), there are three simple rules to follow.

Say you’re sorry

The last thing a customer wants to hear is that it isn’t your fault, especially when it is. Google, one of the largest email providers in the world, had issues with Gmail the other day — and said they were sorry. Like it or not, email for many of us is a very personal experience, and the Gmail Product team acknowledged that.

I had an issue with United Airlines (and Expedia) over a mis-booked ticket. United did a really good job making my life easier and rebooking the ticket so there wasn’t an issue.

Say it in public

Some companies are completely open about some of the issues they are having. Dreamhost had a billing issue earlier this year, and they posted about what happened, and how they were going to fix it. Because of their honesty and candor, I personally like them as one of the better companies out there (and so do many of their companies). Their blog is amazing for company news, and that makes me a happy customer.

MySpace does it all the time. We all know it’s not the most stable platform, but it’s gotten much better over the last few years, and even when there are issues, they publish notices notifying users about the issues with the system, and that it will be fixed soon. MySpace is a bit different because of the informal nature of how they speak to their audience, but they do speak to their audience in language their audience understands, and not some obscure error message.

Say how you’re going to fix it

What Google didn’t do very well was explain what the issue was, which is ironic, because many of the Google users are very technically savvy, and know when they’re being given a line, or something else is being used as an excuse.

All end users want is to be told, “this is how we’re going to make your life easier.” They don’t want excuses of how the weather affected their flight, or why their credit card number was being resold to Indonesians and Romanians. They just don’t want to happen again. You might not be able to prevent it again, but you can take steps to lessen the chance.

The recent publication of a new benchmark report by Aberdeen Group, a Harte-Hanks Company Application Performance Management: The Lifecycle Approach Brings IT and Business Together, further signals the increasing need for real end user experience solutions. Aberdeen’s latest findings show that 50 percent of revenue loss is a result of poor Application Performance. In addition, the enterprises surveyed by Aberdeen clearly ranked the ability to identify end user problems as the top priority for any Application Performance Management initiative.

…

“Best-in-Class organizations are taking an additional critical step and are measuring application performance not only from the perspective of their data center components, but also from the end user perspective. These organizations are ensuring that improvements in application availability, response times and usability translate into improved employee satisfaction and productivity, and ultimately, improved customer satisfaction, mitigation of lost revenue opportunities, and avoid damages to brand image,” said Bojan Simic, research analyst at Aberdeen.

This goes under — duh.

Of course poor user experience can result from a website, web application, or software application that’s slow, has incoherent error messages or just plain breaks. Users don’t know the difference between what’s a bug and what’s not, or why the application is performing slowly.

So, repeat after me:

The first rule of user experience is that the application should actually work.

I wonder how much they are charging for that report. I need to start writing white papers.

If this goes through, I will tell everyone I know about the wonderful customer experience I had with United Airlines. Now they are going to work with Air Canada to change this. At least I didn’t spend $5,000 for a ticket like someone else did on Delta.

Companies don’t reach out to customers enough, and it even happens in the line of work that I do — we promise the customer X and the customer receives Y. It’s truly becoming a world where companies are taking the tact of “this is what you are going to get.” Seth Godin has a post on this regarding voice systems titled, “Should you fire the voice mail guy?” I now deal with them all the time when booking travel, and always have issues with them because I have a slight speech impedement.

Customers desperately want a great customer experience, so much so that word of mouth sites are very successful (i.e. Yelp).

Another story I relayed to a client: there have been studies done that when dealing with a website, the last thing people want to do is pick up the phone (or, can you spot a phone number anywhere on eBay or Azamon for customer service). They don’t want to send an email. What they really want to do is find an answer right then.

Additionally, people forget that internal customers are just as important as external customers. Read on over at Signal vs. Noise. When running an intranet, the less people bug you for a document and the more they can find on their own, not only does it make them happier with their job satisfaction, it saves the company or organization money and makes the more productive.

Case in point: When I was a product manager at Escrow.com, we added reams of frequently asked questions, rewrote every single email so it was easy to understand, and guess what? Not only did customer touches drop 33 percent (customer touches defined as an email or phone call into the call center), but walk-up business to the site went up 25 percent per month, to the point where Escrow.com is now a profitable business.

Happy customers mean more customers. More customers mean more happy customers. You know what I mean?

Everything was a great customer experience — I was able to upgrade my seats easily through their customer service department, the flights were great, they were on time, the food was off the charts (okay, it was First Class, but I’ve flown First Class before, and they never had anything like what they served), and best of all…

I forgot I was on a plane. I hate flying not because I don’t think it’s unsafe (I think it’s very safe), but because the experience is such a nightmare. Crowded seats, limited entertainment options, the feeling that I’m just wasting a few hours of my life, none of that was happening here.

On top of it, the media entertainment system is great. I had actually seen it years ago before they launched the airline through a friend, so I had a good idea of what they were doing, but still, it was really easy to use, and provided some great options without me having to reach for a credit card. They got it.

Thank you, Virgin America, and I’m not just saying this because you can follow their twitter feed, either. I will fly you again, and tell all my friends.

What did I do? Did what any self-respecting iPod Touch user would do: bought the music anyways through WiFi. It took me less than two minutes to go through the purchase process, truly an impulse buy that all music vendors aspire to.

Something so simple as buying music through thin air is another reason why Apple is so far ahead of the pack: the iPod experience connected to iTunes are clearly such a superior experience that other vendors are going to have a hard time catching up.

In other words, Apple has figured out how to sell out how to sell the razors and razorblades — clearly how usability and a superior user experience leads to a better bottom line.

“User Experience” encompasses all aspects of the end-user’s interaction with the company, its services, and its products. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features. In order to achieve high-quality user experience in a company’s offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.

…because, well, they get paid a lot of money.

But, I like to keep things simple. This is what User Experience means to me:

For quite a while, I drove a BMW Z4. It’s a nice car, but most amazing is the placement of the cupholders: they’re right underneath the left and right air conditioning and heating vents, and when you pressed on them, they would pop out. Among all the other things that the car had — a lot of power, a stereo that would increase in volume when the car was going faster, seat warmers, and a power top, excellent handling — it was the little things like the cup holders that made it an excellent user experience. In the time I drove that car (for several years), I never spilled a drink.

The Z4 was in the shop for a while, and I rented a Chevy Aveo for almost three months. Among other things about the car (other than the running joke that a friend of mine came up with a different name for it every time he talked about it) I didn’t like, the cup holders were in the middle, between the seats. I spilled drinks in that car five times. The were a lot of things I didn’t like about the car (poor handling, uncomfortable seating, brakes that were similar to what Fred Flinstone had to do), but what stuck out most was the cup holders.

That’s what user experience means to me — you never know what the end users are going to complain about or like about your product, but you do know that everything they see is something that could be criticized as a poor user experience. It could be that the product crashes every five minutes, or that help text was poorly written, or that it takes ten steps to go through something that should take five, it’s the complete experience. It should even be to the level that users don’t know they want a feature, but it works just as they expect it to.

User Experience specialists act as holistic evaluators and product managers that recognize any that could limit the effectiveness of the product. In that sense, User Experience architects act as gatekeepers, working with all teams (Development, Quality Assurance and Marketing) to make sure what goes out the door is an excellent product.