If you’re using this godforsaken tag, I think you’re making a big mistake. I can’t tell you how many times I’ve observed users accidentally clicking the reset button and leu of submitting the form. The two are obviously not interchangeable and I feel the reset button does more harm than good. Quite honestly, I’ve never been through scenario where the user actually had a need to click on the reset button.

Here is an example of what I mean. There are so many problems with the way these buttons look. For one, two buttons that perform completely different actions look exactly the  same. Some users, who may be accustomed to traditional button behavior, like the like you would experience in Windows or Mac OS for example, make a inclination that all progressive buttons appear to the right—like you would experience in a wizard. I’m not getting into an argument about button placement,  but I can at least recommend deemphasizing the reset button or eliminating it altogether.

Here is an example I recommend: As you can see in the figure below the submit button—the button you want them to click on—is clearly highlighted and recognizable, while the reset button looks much less important. I learned this approach from a colleague a few years ago (@cindyblue, follow her, she’s awesome):  there is a button you want them to click on and then there are the other options.  Always put emphasis on the actions you want the user to take, and deemphasize the actions the users are less likely to take.

Here is one important thing you should always remember: any time you are performing an action that is not recoverable, like resetting a form, deleting a file, or performing a cancel operation, you need to prompt the user first that their changes will be lost if they continue with the operation.

Have you ever accidentally hit the “reset”  button by mistake?

One rule I believe to be almost universal is:

Failing to leave a phone number on your website for people to call and allowing them to get in touch with someone right away.

I have no idea why so many websites make this detrimental mistake. After all, it’s one of the most common website scenarios: getting in touch with someone. It’s also one of the most common usability problems. The data is pretty consistent: people want to talk to someone—especially if they’re genuinely interested in investing their time and money with a company.

Even when showing qualitative data to organizations that have a strong UX culture, I almost always get push back in the end. Here are some reasons people get worried about this:

• Cold calls/marketing solicitations
• Sales team isn’t prepared – they want to talk to customers on their terms

It really is all about design after all. So why doesn’t our industry reflect that. It has become abundantly clear, design rules. Design has become the determining factor on whether someone chooses to use a system or not. We all know that that bad design is the number one factor for usability, user acceptance, and overall adoption.

I know this firsthand: users are willing to except slow performance and system architecture issues because much of this they cannot see. While performance can be devastating to the over arching user experience of a website, the data indicates that if other factors are favorable, users are more than willing to wait-especially when there is a gratuitous payoff.

I’m not saying performance is not a usability issue-and I’m certainly not saying it’s not a huge user experience culprit-but system architects and engineers have a tendency to prioritize architectural issues over design issues.

I certainly believe we all have a place in system development. What I will not accept, however, is the omission of a great design feature that greatly improves the user experience, because the feature is not congruent with the established architecture. It’s almost 2012 people, we can do just about anything we put our mind to.

It’s time to begin to prioritize design with equal attention to architecture and engineering. The truth is we all have a place in the design of the system-but I know for a fact, and I know like I know like I know that: design rules nowadays.

Many people may argue that design is already prioritized in most development projects. If this is true, why is it that user experience designers are not the highest paid employees at companies-or at least the highest-paid contractors on development projects? In my experience user experience designers usually make less than six figures. Even worse, why is it the visual designers and web designers often make below $50K a year—when their responsible for an integral part of the customer experience? System architects, DBAs, and high-level system engineers can make significantly more than that. I’ve seen architects that make a quarter of $1 million a year and sometimes more.

Can anyone give me a definitive answer on why designers don’t make as much as engineers? I would really like to know. In the fashion industry, for example, designers are the top paid employees. Just look at the greats like Tom Ford, Ralph Lauren, Tommy Hilfiger, and Versace. What can we do in the software industry to be more design progressive?

While we are all at different reading levels, the fact remains that the majority of American’s can barely read.

This very statement should influence the way that content strategists, copywriters, information architects write and organize content—but time and time again this is proven not to be the case.

There are many reasons why the Flesch Reading Ease Score is so important when writing and evaluating copy. I thought it would be fun to take a minute and go through these reasons together.

• Search engine optimization. Did you know that the search engines use this criteria when evaluating and placing your webpage in their search results? We know this because companies like Google have patented pieces of their algorithm and made it clear to us that readability is an important factor in search engine placement. Search engine companies, like Google, evaluate this criteria for a reason. Studies have shown that copy, written on a higher ease score, performs better from both usability and market conversion perspectives.
• Increased sales. Another reason for improving the ease score is because studies have shown that effective marketing is congruent with effective communication. The World Wide Web is built on the notion that individuals navigate by reading—which suggests that effective copy can lead to improved conversions.
• New friends. Another positive side effect to improving your ease score includes opening up your content to a new audience. A lot of people ignore this perspective but but the time it takes to comprehend advanced copy is just too long for most users.

You’re probably asking yourself how to calculate your Flesch Reading Ease Score?

It’s a relatively simple algorithm, but I don’t want you to get too hung up on the specifics. There are only three scores you need to worry about—well technically only two scores you should worry about. First, let me teach you how to calculate your reading ease score and then you can decide for yourself.

Here is the formula, but do check out many of the well-known software titles out there—like Microsoft Word—that can give you this score automatically.

Score = 206.835 – 1.015 * (total words/total sentences) – 84.6 * (total syllables/total words).

As you can see the number of words and syllables in your website copy have a significant impact in your score. One effective way to improve your score is to avoid words with multiple syllables. Words ending in ES/ED/EY can often be avoided pretty easily.

I realize this may seem very convoluted, but once you know your score, it’s very easy to know if you’re going in the right direction. Website copy that scores between 90 and 100 is easily understandable by an average 11-year-old—that, my friend is a sweet spot. Anything between 60 and 70 is easily understood by a 13 to 15-year-old. Anything below 60 is crossing the line.

If you’ve never heard of it before, perhaps this may spark your interest: The Department of Defense requires all documents and forms read at a score of 45 or higher. Other publications such as Reader’s Digest, have a readability index of 65 or more. Time Magazine has a readability index of about 52 and Harvard Law Review which has a readability score of about 30. One thing that is about all three of these publications is that they have a readability index of above 30–which is what you would expect from a high school student or younger.

I highly suggest you write copy that is easily understandable by a child–that’s a readability score of between 65 and 100. That way your copy is easily understandable by ages 11 and up.

Here are a few helpful hints that you can use while evaluating your content. Simply, find out your score, and the table below will tell you how easy your content is to read.

• 90-100 : Very Easy
• 80-89 : Easy
• 70-79 : Fairly Easy
• 60-69 : Standard
• 50-59 : Fairly Difficult
• 30-49 : Difficult
• 0-29 : Very Confusing

1. Check your ego at the door. Your ego has no place when it comes to writing software. If you’re writing software based on how you feel, you’re making a big mistake. It should be made from data. Nobody likes an egomaniac! You don’t want to have that kind of atmosphere
2. Make it feel like it was their idea. Make it about the person you’re trying to convince. It’s way easier to get people on board this way.
3. Don’t be an asshole. You can’t make a difference if you’re fired. Be the voice of the user, but don’t be the voice that is nagging everyone. “There goes AJ again…”.
4. Position yourself as the expert on the user and do this by conveying a message based off of the facts.
5. Use good excuses (but not an ultimatum): “You can’t hold me accountable for usability if we don’t do usability testing.” or “You can’t hold me accountable for the user experience if you don’t put me in front of users”.
6. Get everyone involved. Don’t think that because you’re a UX designer that everyone else can’t do it to. You should be creating an atmosphere where everyone is thinking about user experience. Be an advocate for the user and an evangelist for user-centered design.
7. Listen more, speak less. I’ve learned to only speak about something when I have a really good reason to. One great side effect is that people tend to genuinely respect my ideas and opinions—that’s because I don’t dilute what I say with useless filler.

• Q: What are scenarios?
• A: Scenarios are essentially tasks—usually associated with an action the user will likely have to encounter to in order to achieve sometime. That something could involve finding information, filling out a form, or answering some sort of question they might have. Most of the time, these “scenarios” are directly correlated with a business goal and organization may have—like getting in touch with someone, buying a product, capturing the user’s information for future contact.
• Q: How many scenarios should you do?
• A: That is a difficult question to answer because it all depends on the complexity of the scenario and the user’s persona. For example, a user who daily uses a computer is more likely to complete certain tasks faster than someone who doesn’t. A disabled user—depending on their impairment—can likely take 3-4 times longer to complete a scenario. I advise people—when doing a study that is one hour long—to identify 9-10 scenarios ordered by priority. Higher priority scenarios will be done with every user and lower priority scenarios can be skipped if the user runs out of time. Many stakeholder will want to do more than than 10 scenarios, but I highly recommend keeping the usability testing short and concise.
• Q: How much time should you spend on each scenario?
• A: You should spend as much time as you need to as long as your user isn’t getting fatigued or frustrated. I’m more concerned that the facilitator doesn’t give up on the participant to soon. Remember, it’s not about PASS or FAIL, it’s about what leads up to that PASS or FAIL conclusion.
• Q: Should you create false scenarios (the ones you can’t find an answer for)?
• A: That’s a great question! I would advise that you think about in the real world scenarios. In the real world, you sometimes don’t find what you’re looking for. I suggest that you do create false scenarios when you’re doing user research—especially if you’re introducing new content. For example, if you’re looking to introduce a new Blender in your line of kitchen products, it might be a good idea to ask the user to identify where that product is located on the website. It’s great content strategy!
• Q: What are some examples of bad scenarios?
• A: The ones that never happen in real life. When stakeholders give me scenarios, I can’t tell you how many times I get something along the lines of “What is the total number products on our website?”—nobody freakin’ cares.

While there are other kinds of usability testing exercises, like eye tracking, card sorting, analytics, heat maps, etc—none of them are as impactful and eye-opening as qualitative research like cognitive walkthroughs.

Here are five reason you can benefit from doing usability testing using the cognitive walkthrough methodology:

1. It’s efficient: Jakob Nielsen (godfather of usability) says that 85% of usability mistakes are caught with just a small panel of 5 users! Oh, and If you test 15 users, almost 100% are caught. If you do iterative design (which I hope you do), testing a sample 5 users at the end of every sprint and keep your application/website almost usability issue-free.
2. It’s affordable: Paying an honorarium for 5 users can be as little as $250 bucks, you can do it anywhere—so you don’t even have to pay to rent a facility, and you can do this yourself.
3. It’s convenient: It can be done in conference room, in the field, at the user’s workplace—anywhere that’s convenient to the user.
4. It’s qualitative: Data is put in context, you’re dealing with people, you’re getting to know what the user is thinking—not getting buried in boring charts and Excel spreadsheets.
5. It’s in context: You learn more than just usability, you learn about your users, their behavior and their frustrations. You learn about their desires, their hopes, their dreams, their passions. Imagine if you could build software that get’s in touch with those qualifications—rather than building an experience based on requirements that don’t make sense or are written by some disgruntled office worker who just wants to get the job done.

“I’m preparing my first usability test. Any recommendations?”—well I’m so glad you asked this question.

I’m going to give you the “low-down” on how to do usability testing that is both effective and eye-opening. By the way, this article is about doing a very small qualitative study, so we’ll save card sorting/eye tracking/etc for another day. Here are your action steps to testing software or a website for usability:

Like this article so far? Click here to tweet about this on Twitter.

1. Assemble Scenarios. Create a list of scenarios and prioritize them. It is very possible that you may not get through all of them. I recommend no more than 8 or 9 for a one hour study. You don’t want to have too many and your user get fatigued.
2. Assemble interview questions. What kind of questions will give your test results perspective? You can ask these questions before, during, or after the study.
3. Assemble a survey. This can be sent to the user via email before or after the study is completed using a service like Survey Monkey.
4. Get “buy-in” from upper management. You need to make it sound like it’s their idea. It’s so important to create an environment where everybody is thinking about the users and this is driven from data—not ego. Use the arguments “you can’t hold me accountable for usability if we don’t do usability testing regularly” and “if we’re not making decisions based on data, we’re just guessing!”.
5. Recruit Participants and make them sign waivers beforehand. Have a list of trigger questions that will disqualify them. You want to eliminate participants that may skew your results. You want to recruit 5-6 users and also try to recruit 1-2 backups in case some of your users don’t show up. By the way, someone almost always bails!
6. Choose testing style. Are you doing lab testing or field testing (ethnographic)? If you’re doing lab testing, make sure the lab has an observation room in case stakeholders want to observe. Regardless of the testing type, make sure that there are no more than 2 people in the room with the user (one person to facilitate and one person to take notes). Often times, management will want to sit in on these things—fight it if you can.
7. Figure out what equipment you’re going to use and keep it consistent for each user. I prefer a simple Windows 7 machine with Internet Explorer or Firefox. I recommend installing Morae to do picture-in-picture video recording. If you’re doing this in a lab, they may have the configuration available for you. Another option, if you’re using a Mac, is to try Silverback (much cheaper than Morae).
8. On the day of the study, make sure that refreshments and snacks are available. If you’re budget is very small, just have bottled water on hand. Your users will appreciate the gesture.
9. When the user arrives, kindly great them and thank them for participating in the study. Inform them what you are doing, that they’re being recorded, and that their contributions are going to be used to improve your product.
10. Begin with a few interview questions to get the user warmed up. Instruct the user to “think out loud” so you know what they’re thinking as they move through each task.
11. Start with a simple scenario, like “Navigate to Acme’s home page” then gradually move on to harder scenarios. Pay very close attention to what they’re looking at, their facial expressions, their complaints, etc. This is where it’s nice to have one person who’s role is strictly to take notes so you can focus on the subtle things.
12. Have your note taker discreetly record the time it takes to do each scenario. It isn’t a good idea to tell the user that you’re recording the time—and it doesn’t have to be too scientific, just glance at your watch.
13. If the user asks you a question, use “the echo effect” and repeat the question back to the user. Example: “How do you search for keywords?” reply with “How, DO YOU THINK you would search for keywords?” if the user doesn’t know, say “How do you think search should work?”. Remember, you’re not there to give the user training, you’re there to uncover usability problems so they don’t need training.
14. Make sure the user tells you when they would have normally given up on a task. It doesn’t mean you have to stop the scenario, but it’s important to indicate the timing in your report. If you strongly feel the task cannot be completed, definitely move on to the next task—but don’t give up too soon. There are often many navigation and search paths, you never know which one your user may discover.
15. When the study is over, pay your user an honorarium or gratuity for their support. Anywhere from $50-$100 for normal users. If the user is a subject matter expert (like a doctor or lawyer), it’s customary to pay them more their contribution.
16. Send a survey out to each of your users. Sometimes, I like to send out a thank you card in the mail as well.
17. Assemble all of your data together and create a report. Annotate the number of times a problem occurred and indicate whether or not a problem is a trend or not.

Usability testing can be a struggle when everybody who has a stake in a project tends to get very personal. For whatever reason, developers involved with the project never view it as a natural part of creating software—this would probably change if we all did usability testing regularly as part of an iterative design methodology. Because of this, stakeholders feel they have to be there during the day you’re doing usability testing. Sometimes they even want to be in the same room as you. While I make many arguments on why this isn’t a good idea, it’s rarely something I can prevent. After all, some usability testing is better than no usability testing. I hate to think of it as a privilege, but it’s so important that I’ll do just about anything to make sure it happens.

So here are some bad things that have happened previously in usability studies that should NEVER be allowed during usability testing:

1. Never tell the user or let them believe they are doing something wrong. This includes silent stares by quiet developers sitting in the room “surprised” by what he is finding. The best approach is to not let anyone else in the room with you—but if you have no choice. Make sure they’re sitting far away and are not adding commentary. This is about the user, not about anyone else in the room.
2. Never introduce yourself (or anyone facilitating the study) as anything other than an objective 3rd party. I’ve seen this ending very badly. Often times, we can’t hire a 3rd party to do usability testing for us, so we do it ourselves. That is completely fine, but make sure your user doesn’t know that you played a role in the design or implementation of what they’re testing. In the past, I’ve had someone in the room introduce themselves as a member of the website development team—the user spent the entire hour pointing to that stakeholder when she had encountered problems. It was a nightmare.
3. Never let the user give up too soon. Observe the user tackle several navigation and search paths. Let them indicate to you when they’ve given up. This is a mistake that I’ve made in the past—moving on to the next scenario when I thought the user had “failed” the scenario. I have to remind myself that user interaction simply doesn’t work that way. They might complete a scenario in the most interesting of ways.

Thanks so much for watching and please share, tweet, and give me feedback!