Did you ever have a problem that you thought you could solve, just to find out your solution simply added to the problem?
We at AgencyND did recently, and it was only through testing that we found out the proposed solution wasn’t the right one. The question then became, are we trying to solve the wrong problem?
Here’s the scenario:
We had a site where visitors were consistently having trouble finding certain information. One suggestion was that we needed to “open the navigation” or put a site map above the navigation in order to show visitors all the pages all the time.
First thing in our minds, other than “not a good idea,” was: Is the problem in the navigation or in the architecture of the site? In this situation, we weren’t going to be able to review or change the architecture, so we went to the drawing board to find out how we could show that there was depth to the navigation.
Aha! We hit upon a great idea! What if we showed there were subpages by somehow marking the parent pages differently from those without subpages?
Excitedly, we drew up several paper prototypes to see what symbols might be used to indicate subpages. We then showed these prototypes to users to find out what each thought the symbols meant.
We tried arrows (to the left or the right), + signs, ellipses—all kinds of ways we could think of to indicate there was more (including “more”).
Our test participants disliked all except an arrow to the left of the navigation item. They felt that arrows to the left meant there would be subpages.
We had it! We would put arrows on the navigation to indicate there were subpages!
So, we took the original navigation and added arrows. And then we looked at it and collectively said, “Uh oh. Houston, we have a problem.”
You see, we’re mostly Mac users here. To us, we’re used to arrows in our finder menus that face right when closed and down when open. Not a problem; our developers said.
But then, we asked, “What will happen when we click on one of these down arrows? Will we expect the page to close and to go back to the original page?” And will others expect the same? What about PC users? Will they think the way we do?
So we tested.
We had our developers create a prototype page and we asked our testers what theythought would happen.
Then we watched their reactions when they actually used the navigation.
We were right . We had a problem. Our testers:
were confused about the number of subpages, sometimes missing the ones without the arrows.
quickly adjusted their count of subpages, but still missed one that appeared to be a continuation of the line above.
assumed a subnav menu would appear, but that they would be staying on the page they were currently on.
got confused as to where they actually were.
weren’t sure how to navigate back to a prior page.
In other words, while they understood that the arrows indicated subpages, they expected behavior that our CMS simply can’t provide—they expected the navigation to function as a system of folders with files rather than pages with subpages.
Now let me add another piece of information here. We build our sites using Conductor, a proprietary content management system. If we wanted the arrows in the navigation to act like a Mac finder window, we’d have to hard-code the functionality into the site. It’s simply not practical to do that, or to change the CMS to accommodate that for this one site.
Could we solve the issue by changing the navigation menu?
We could add lines between the items in the subnav to solve the problem of “losing” the page that appeared to be a continuation of another.
We could more dramatically change the look of the active page in the navigation to help visitors orient themselves.
But we still couldn’t get past the problem of visitors expecting folder vs. page behavior. The addition of the arrows as clues, in other words, created more problems than it solved.
Our tests showed that indications of subpages in this manner simply doesn’t work well. In fact, we would recommend a thorough review of a site’s architecture to make sure we’re actually solving the right problem. This, especially since we haven’t been able to find another site that has “solved this problem” in this manner. We feel we were, in effect, barking up the wrong tree.
But we had to try. And we had to test. Because by testing, we learned more about user expectations, user behavior, and that not all problems are what they seem.
and others that I can’t even remember at the moment. I’ve been doing a lot of testing lately, and I’m loving it! Why? Because I’m learning so much from our volunteer participants than I could even imagine learning from studying the sites myself.
Unexpected Testing Insights
Sometimes the most important insights aren’t even about the site being tested (although I definitely get lots of those from the participants). But in my in-person testing, I make sure to ask each and every participant to pass along any thoughts she might have about any website on campus–what they like and what they hate. I tell them that anything they want to pass along to me will either
be passed along to our designers or developers to make our sites better, or if the site isn’t one we developed,
be noted and possibly used in a future site.
In other words, I truly value the input from our test participants!
Users are Not Predictable
Sometimes the participants are students, who are typically excited to be involved in the University’s website program because they want to be heard. They often have ideas about changes they want to see that this old woman would never have dreamed about (but neither did the 30-something clients, designers, or developers). They feel free and open to share that they
never use Twitter
use Facebook and IMs to communicate everything
want and expect to find quality information instantly on University websites and will find alternate ways to do things if they don’t like the interaction we force on them
use mobile devices for Internet browsing nearly as much as their laptops
want to be involved in planning University sites
In other words, they are not the passive users we sometimes assume they are. And they don’t think the way we think they think. In fact, I have to admit that even the staff and faculty who help us test (most of whom are women), rarely go without surprising me with one insight or another. Even the ones I think I’ve gotten figured out. There’s always that one comment, spoken under her breath or added as an afterthought, that really makes a difference in the test results or that should be brought to someone’s attention in one way or another.
Gold in the Nuggets
So the next time you think your site is just about perfect; that everyone will have a reaction to it that you want (or assume), think again. As the old miners used to say, “Thar’s gold in them thar hills!” You might have to dig a bit to find it, but it’s there, and it’s valuable.
I was recently asked to provide some information for a client as to why they should test their website, which underwent a major overhaul a year or so ago. My number one reason: Every site was built and maintained by humans.
“The average [user interface] has some 40 flaws. Correcting the easiest 20 of these yields an average improvement in usability of 50%.” (Landauer, 1995)
But, they say, our site isn’t that old . . . To which, I say
Site creep occurs whether we like it or not
No one can accurately anticipate individual visitor interaction
Visitors and their needs/expectations change over time
Why is testing important?
In order to get the best answers in the shortest time for this client, I looked to the “experts” for answers that would help this client understand why testing is so important. From Jakob Nielsen,
A site that has many user-experience annoyances:
appears sloppy and unprofessional
demands more user time to complete tasks than competing sites that are less annoying, and
feels somewhat jarring and unpleasant to use, because each annoyance disrupts the user’s flow.
Testing points out weaknesses; weaknesses can be corrected.
So now that I have some experts explaining the why, I thought it was time to bring out the how and show the client how we had dealt with issues we found through testing.
The first one was a classic—the old supporting.nd.edu website—which was functional, but not as effective as it could be.
It seems that donations to the University didn’t come in through this site at quite the rate we thought they should. So when it was time to review the site with the beginning of a new fundraising campaign, AgencyND looked again at the donation button and decided it was time to make it bigger and more noticeable.
The new website increased donations by providing an easy avenue for users, something missing in the old site.
Testing asks users what they want.
While I couldn’t promise the return of one e-commerce site that increased sales by $300 million just by allowing visitors to purchase without logging in (a direct result of testing), I could show how visitor input (from testing) helped us to make valid decisions on some of our sites.
For instance, we are in the process of creating a new Holy Cross website, so we had volunteers help us test the sitemap (information architecture) as proposed. Through testing, we found visitors don’t use same vocabulary as religious; even lifelong Catholics didn’t know, in some cases, what Treasury Enrollments and Holy Cross Association referred to. By testing early, we were able to advise the client to consider alternate terms to help increase findability/usability for visitors.
Testing gives REAL results.
Sometimes, in spite of all the experts and all the knowledge we have regarding our visitors, we have to rely on actual testing to get data to support changes no one expected. This is where I pulled out a site that is still being developed to show that visitors weren’t “getting it” the way everyone thought they would.
In this site, we designed a large “Submit News” button. According to design factors, we felt this would clearly be where visitors would click to submit articles. We were, at the time, trying out a new heatmap generator and attention prediction tool by AttentionWizard, so we had it create the following heatmap, which indicated users should have seen SUBMIT NEWS immediately.
In our test, though, 3 out of 4 did not!
(We also found we needed to add Contact Info to each page and change some label names to help visitors know where to go.)
Other examples of REAL results include:
Here I showed examples of how usability testing helped a branch of the US government increase the value of its website. Through testing and revision of their site, FEMA nearly doubled the success rate for visitors in finding what they needed; nearly halved the time to complete their tasks; and increased satisfaction with the site from 49% to 71%.
Then I gave the example provided by Constance J. Petersen in “Seven Steps to Easier Web Navigation” where she showed an old garden.com site that used a wheelbarrow as a stand-in for a shopping cart. While clever, switch from a known term such as shopping card caused this e-commerce site to suffer the lost of at least one sale to Constance because she had no idea that the way to make a purchase was to click on “wheelbarrow.”
If this had been tested, I’m fairly certain the company would have discovered that the term “wheelbarrow” was going to cause confusion in the very least, and cost them sales in all likelihood. As Constance pointed out in her article, the site has since been tweaked and the wheelbarrow replaced (we hope in response to what visitors expect in a site such as this). (As of this writing, however, the site is down for maintenance.)
How to begin?
Well, now I think I’ve given the client enough reason to know that testing is important to a site’s health and usability. She now wants to know, now what?
This is when I suggest that the client figure out what appears to be working or not working on their site. I suggested she talk to visitors to find out how people are using their website. What do they want to do but can’t? By talking with visitors to their facility who use the website, the client can get a jumpstart on testing. She can find out known vs. suspected issues and hear comments from actual users.
Once the client has an idea of what’s possibly a little (or a lot) off, we can then create a test for that site, including the known or suspected issues, and also covering other parts of the site. After all, just because visitors don’t tell you about a hard-to-use page doesn’t mean it doesn’t exist!
We can create tasks based on the above—tasks that will test representative interactions (in this case, scheduling or registration). These tests will show us what kinds of “errors” visitors make when trying to complete the tasks. We’ll find out if these are similar errors or particular to one audience segment. We’ll listen to the testers to find out their overall feeling regarding the site, and any particular portion of it, and we’ll listen to what they need or want that they may not have expressed before. Often, we find that comments made during testing reveal a “hidden” side of our users we hadn’t uncovered before—their wish list of features or desired information.
In this case, I was able to tell the client comments I’d already heard about their site. You see, after a test is complete, I give testers my business card and ask them to let me know of anything they like or dislike about any University site—I’ll be the conduit of comments to the developers, designers, or decision makers. It’s amazing how often I’ll then hear comments about other sites that I do pass along. (One thing I’ve found in testing is that, given an ear, test participants love to talk about their needs and wants for University sites; they just need to know that they are being heard.)
In fact, regarding this site, just the week before I heard comments about schedule pages not having all the same information, thus making it difficult to register for a class without clicking back and forth several times.
So what can we expect as a result?
Ah, the old “What am I going to get out it?” question. And rightfully asked since we have to charge our clients for our work. I assured the client they could look forward to
Reduced “cost” perception. In other words, visitors find what they want more easily; thus, they don’t consider time on the site wasteful
Increased “value” perception. Because they find what they want, the time on site is more pleasurable, more valuable
Reduced lost sales. This client “sells” classes and programs to students and faculty and staff. With fewer dead ends, visitors will be more likely to register for more. As a side benefit, staff will not have to answer questiosn in person or deal with unhappy visitors who couldn’t find what they wanted.
Longer site life. While, unfortunately, bad sites don’t just fade away, by investing time and money to test the website on a regular basis, the client will actually be extending this site’s life. In other words, they won’t have to rework the entire site every two or three years, completely redesigning and rethinking the site. They can, instead, tweak the site with minor changes to reflect the testing results. And visitors to the site may notice improvements but not feel completely lost the next time they return. They will be returning to an old friend, one who has the information they need and one they can easily navigate to accomplish whatever tasks they had in mind.
All in all, not a bad investment of time and money.
No, seriously. Besides the fact that we work at a premier university, if we’re wanting to make sure our websites have a fighting chance in the bit world of the Internet, just having the “nd.edu” brand adds to the value of any Web address we can think of for our various departments and programs.
But that aside, how do we pick out the best URLs for our new sites?
Well, the answer I give today is different from what others would have said two, five, or 10 years ago, and will be different from what I might say in another year or two. Search engines are adapting to the “new world” of SEO and how Webbies try to get their sites noticed, and the rules will change as the Web evolves.
But right now, here is what the experts are saying we should consider when picking a URL:
Keep it short. Longer is more SEO friendly and more descriptive, but harder to type without errors and harder to remember. Also, current (2008) research showed that long URLs tend to be ignored, with users clicking on shorter URLs more than twice as often.
Keep it simple. Easy to remember is a key.
Make it descriptive. If the URL doesn’t describe or somehow obviously relate to your site, chances are that your users will not remember it very long. (Will users remember that ace stands for Alliance for Catholic Education? Or tas stands for Teachers as Scholars? Maybe so. Know your audience and how they think.)
Make it memorable. It’s easier to remember impact than Economic Impact Report (impact.nd.edu).
Make it easy to spell (versus easy to misspell). Otherwise, reserve likely misspellings of the URL for redirects. (When deciding on a URL for Advanced Diagnostics and Therapeutics, we “argued” about whether users would misread or misspell the one chosen: advanceddiagnostics.nd.edu. Two d’s or one?
Make sure it’s not ambiguous. (Gee, do I spell out department-of-french? Or was it dept-of-french? Or was it just French?)
Make sure there are no “words within words.” Beware of accidentally running together words that could be taken apart in different combinations—For instance, Peterson’s Experts would not want to use petersonsexperts.com.
Use keywords when possible. Would your users be looking for you under department or French?
If you must use hyphens or underscores, which some argue helps search engines find the keywords easier, use hyphens. Although underscores are gaining in acceptance, hyphens still rule. Better yet, though, would be to leave out the hyphens since users tend to forget them and thus make errors when trying to type in your URL.
Use lowercase. For most of us, the use of capital letters in URLs will not make much different; most servers these days use Microsoft operating systems that don’t care whether you use upper- or lower-case lettering. Also, search bots “learn” to tell the difference and route traffic to the site in spite of any capitalization issues. However, some experts feel that with the growth of open source software, the problems with different cases will increase. Thus, at Notre Dame, we avoid the case issues by defaulting (through Conductor) to all lower-cased urls, including subpage names.
Consider the following URLs in use by Notre Dame. A lot of thought and discussion went into choosing these URLs, and the final choice was often a compromise. Choosing the correct URLS is not always as easy as one would think.
What would you have chosen as a URL, based solely on the criteria above?
Alternative SEO-Friendly URL (much longer)
Advanced Diagnostics and Therapeutics
Alliance for Catholic Education
Department of Applied and Computational Mathematics and Statistics
Applied Investment Management
Notre Dame Magazine
Strategic Research Investment
What’s your least favorite URL? Most memorable? Have you experienced choosing the wrong one? If so, how did you work around that? Let us know!
I recently studied a number of blogs and sites talking about placement and design of search boxes and buttons. While there is very little data on why decisions were good or bad, there are plenty of opinions as to what makes a good button/box and placement good or bad.
Search Box Location
The one point all the authors agreed on was that the search function should be at the top middle or right of the page and easily distinguished from other items on the page. (You will note that Harvard failed in this in that it includes search as part of a menu line. If you click on “search,” you are directed to another search page.)
Wikipedia moved its search box from the left sidebar to the top right corner based on common user expectations (most search boxes are in the top right corner), research about the search box size and how that would affect the Wikipedia layout, and actual Wikipedia research lab results.
Reasons cited for having the search box in the top-right corner include:
Expectations of users
Better use of site real estate
Immediate access to the browser scrollbar
Easier to maintain fixed standard width from page to page
Icon vs. Words in Search Boxes
While no one gave any reason why the magnifying glass icon should not be used, of the 11 major sites I checked, only four used it, and three used it in conjunction with the word “search.” Bing was the sole site that used only the input box and icon, with no accompanying text.
Only one site (NPR) used the word “go,” and again, that was in conjunction with the word “search.”
One site (AltaVista) used the word “find” instead of “search.”
Two sites (Boston Univ. and Wikipedia) used language within the input box, with Boston clarifying that the search included by the Web and directory.
Wikipedia’s technical blog still retains the “search” and “go” language; however, in the English version of Wikipedia, the search box contains the word “search” and the magnifying glass icon. For them, the “go” function was meant to find articles with the same title as entered in the search term. On my quick review of these sites, however, that wasn’t always the case; NPR.org’s “go” function gave me the same results as the “search” function.
Search Box Width
Usability expert Jakob Nielsen recommends 27 characters as the ideal width. He indicated that his tests showed this width would accommodate 90 percent of queries. If the box is shorter, only part of the query would be visible, making editing and review difficult for the user.
Experian Hitwise published a breakdown by percentage of clicks in early September that shows that search queries are getting longer. What effect Google Instant will have on that is up in the air, but it would behoove us to watch for trends and, as a safety measure, make sure our search boxes are wide enough for those longer queries.
Based on this survey and your own experiences, what are your thoughts? Is there anything that says one way is right or wrong?
If anyone has tested theories on placement, size, and language/icons, let me know. I’d love to hear from you!
In the meantime, I’m charged with figuring out a way to test these for AgencyND.
I preach content made for the audience: context is vital. It bears repeating.
The Beloit College Mindset List came out this week. Typically, this just makes me feel old. But then, I felt old when I was 18 and mentioned Albert Schweitzer in a college speech class and was told that I should have explained who he was because not everyone knew had heard of him (and that was MANY years ago; I can’t imagine trying that today!).
With this year’s report, however, it’s different. Today, I feel a call to action. I need to use this mindset as a reminder to our Web clients (and me) that not everyone knows that Nirvana was a band; that Beethoven wasn’t always a dog; and that children used to never even consider divorcing their parents! Today, students (according to the poll) don’t even know how to write in cursive (it’s an optional subject in school these days).
In other words, it’s a different world out there. Messages and calls to action that might work for my generation probably won’t do a thing for the college crowd. To make a reference to Black Monday in a financial sense won’t bring our students’ minds to Wall Street (well, except for a few finance majors), but instead, to the punk rock band.
We speak in the same language in different tongues.
The lesson I need to drive home (in my own mind as well as those of our clients) is that we need to ALWAYS keep in mind the experiences and knowledge of our readers–in other words, the CONTEXT in which the CONTENT will be read.
Aha! Finally, the big guys agree with me. Yahoo! just published The Yahoo! Style Guide, billed as the “ultimate sourcebook for writing, editing, and creating content.”
A few posts back, I ranted about creating a style guide for your website to (among other things) help ensure consistency across the site. (See Website Style Guides.)
Even before writing this post, I purchased the Yahoo! Style Guide for my Kindle, knowing that it will make a great resource for explaining thorny issues to clients.
Just read the top-level items in the table of contents:
Write for an Online Audience
Speak to Your Entire Audience
Write UI (user-interface) Text, Email, and Mobile-Friendly Content
Manage the Mechanics
Clean Up Your Copy
As a former editor, I realize there’s no one right way to write content (punctuation, capitalization, etc.), but this guide provides lots of guidance and would be a great resource for someone wanting to have “one source” for content guidelines for their site. The writing is clear and simple; and there are exercises to help you learn how to use the knowledge you’ve gained from reading.
My favorite chapter of the Yahoo! Style Guide (so far) is “Chapter 19, Keep a Word List.” And yes, I admit it. It’s because I’m always preaching about keeping a written style guide that includes how you prefer to spell or capitalize certain words.
In fact, the authors have the same reasoning for their word list that I do for my “home-made” style guide (66 kb pdf): It will “make your work easier, maintain editorial stands, and give your site a consistent voice.”
How much thought do you give to your About page of your website? Until recently, I hadn’t thought much about them either. Yes, I know, we need to cover the basics—who, what, where, when, and how—on these pages, but really, can it be that hard?
According to John Hyde, who wrote “About Pages: Good, Bad, and Missing,” it can be. Hyde says that, although users seldom choose to form a relationship with businesses (or, in our case, a school) because of an About page, they often come to these pages to get a feeling of who we are, “who lives behind the websites” to find out whether the like what we are and what we value. According to Hyde, “About pages help users put our heretofore anonymous organization into perspective.”
In the competitive atmosphere of higher education, drawing students, staff, and faculty to our university can be a challenge. By providing good About pages, we are helping our various schools and departments fulfill their missions to bring the best to campus.
After reading Hyde’s article, I decided to quickly review some of Notre Dame’s sites to see how they measured up to Hyde’s 5 Ws of About pages (who, what, when, where, how) as well as an added one (call to action). (Hyde also has other good criteria, but I’ll touch on those later.) While the call to action might be an arguable requirement, I would argue that even having an added “Contact Us” button or link (even if in the header of every page of the site) would help make users feel more “at home” and comfortable, knowing we are inviting their contact.
Here’s how a few of our sites stacked up. (Note that the last site is not ours; it is Hyde’s. I wanted to make sure the doctor took his own prescription!)
The University of Notre Dame, founded in 1842 by Rev. Edward F. Sorin, C.S.C., of the Congregation of Holy Cross, is an independent, national Catholic university located in Notre Dame, Ind., adjacent to the city of South Bend and approximately 90 miles east of Chicago
I’m John Hyde. I’ve been improving websites since 2006. I’m based in York, England.
With a new client I look for the easy wins. This makes everyone feel good.
Did you notice that the University home page covered who, what, where, and when all in one sentence?
Some of these were “stretching” to cover all five Ws. Some were better written than others. But just reading these, I’ve a new appreciation for a good About page.
What are your thoughts? Does it matter, for instance, that some sites don’t have an About page? Or that some don’t have a call to action?
Now that I’ve completed this little exercise in reviewing some of our sites and making notes for future edits, I think I should take some of that medicine Hyde offered and drank. I need to fix my About on this blog. And then offer some suggestions to those who maintain the AgencyND site. Thanks, Mr. Hyde!
I would highly recommend taking a few minutes to check out Change This. There are some really good thoughts about life.
Anyhow, the passion the author calls for seems as if it would work well with just about any line of work, so I thought we could apply his P-R-A-C-T-I-C-E formula to Web work. Let’s try it out:
Ha! This one’s easy to figure out, hard to practice. It takes a lot of patience to work with the disparate group of people involved in bringing a website to fruition! Take the hard-to-get-along-with client who demands more than you think she should. Or the developer who insists on having enough time to do his work correctly. Or the designer who doesn’t want to be a pixel pusher. Patience. Yup, that’s a necessity.
But what about patience with yourself? I know I hate it when I lose track of projects or forget to contact a client. I want to take responsibility for the whole project, even though I’m only a small part of a larger team. Patience with oneself is probably the hardest part of the job for some of us, but without it, how can we expect to be patient with others?
How often do we tell our team members how much we admire their work? Or their ability to see things we can’t? And how often do we keep silent about who actually thought of an idea that the boss really likes when that idea was not originally ours? For me, it’s darn difficult to praise clients when they raise a good point that I should have already raised. Or to congratulate a developer on providing a great solution to a picky client. But what does it really cost me? Not much in comparison to the reward it provides to the team (and to myself).
Same thing as recognition. Little cost; great reward. So how come I find it hard to thank someone for making me work hard to grow? The client who insists on good service, a superior product, and intelligent answers is often the one who is maligned in our meetings. We should be thanking that person (at least in our minds) for he is the one who demands that we grow. In fact, I want to thank Gabe, who pointed out that my links didn’t work on my last post. I was totally embarrassed and had to admit I didn’t check them after publishing. It was not easy to hear that I did something so mindless, but I’m thankful to Gabe for pointing this out to me so I could fix it. (Now! That didn’t hurt a bit!)
While giving advice might be easy, are we truly counseling our clients or team members? Or are we simply showing them how much we know? True counseling can come in the form of suggestions that help someone come to the “right” conclusion, allowing them to save face and grow at the same time. When we counsel someone properly, we share wisdom as well as knowledge, and we share our true selves, which is a gift even the most strapped of us can offer.
Yeah, I know. We charge for every minute. We have to. We’re a business. But are we truly giving our clients or team members all of our time? Or are we listening with half an ear while texting or checking our email? Try taking notes on a pad of paper next time. Look at your team member when he’s talking, and try to be truly engaged. You might be amazed at how much he knows!
I’m going to turn this one around. How well do I take instruction? I recently met someone in my field who really turned me off by telling me how to do my job within 30 seconds of meeting me. When it came time to try to learn something from that person, I had a difficult time. I kept that resentment alive and blocked everything offered to me. So who suffered? That’s pretty obvious; I did! Will I do better next time? It’s a wait-and-see game, but I would hope that I’m mature enough to take instruction from a more knowledgeable person.
Complaints are common. I, for one, get sick of hearing them, especially when they tend to be habitual or running heavily some weeks. But I need to listen to them, truly listen. It is by listening to my clients, team members, and others, that I’ll learn. And by empathizing with others, I can show them the compassion and respect they deserve and that I will one day want.
Times are rather rough right now where I work. Morale is suffering a bit. Nothing drastic; just your everyday stuff. Every time I want to scream and call it quits, I look to a core group of coworkers who help me put the issues into perspective. They help me come to terms with my skills as well as my limitations—and see how I can contribute to the solution rather than the problem. In other words, they encourage me to do my best when everything around me seems to want to break me down. Giving that kind of encouragement to others helps not only the recipient, but also all those around him, including yourself.
So that’s my moralizing for today. I give full credit for the idea that made me stop and think to Mark Sanborn, author of the ebook referenced above.
I love my work! It’s my passion and my calling. Now I just need to practice showing that love!
Every website should be tested for usability. Web visitors (users) will turn away from or devalue websites with errors such as:
Text that is too dense or too long to scan (Web users scan rather than read)
Information that is “hidden” from users by being too deep in the site or on a part of the page users tend to overlook
Even though it’s known that testing will help solve usability issues, many people counter that website testing involves a usability lab, outside consultants, and/or expenditure of a great deal of money. Having to pay for design, hosting, and maintenance of the website already stretches departmental budgets.
The idea that usability testing is expensive may have been true in the past; but inexpensive tools and methods are now available that can provide valid feedback on a site’s usability and, therefore, its ability to help meet the goals of having the site in the first place.
Why Do Websites Need to be Tested?
One of the first questions to ask when planning a new site or rework of an existing site is “Why?” What is the goal of your site? If there is no stated goal, or if the site is not designed to meet the goal, then the department is simply wasting time and money.
Stories about how simple changes to websites transformed the sites into moneymakers abound. One that stands out is the one usability expert Jared Spool, CEO and founder of User Interface Engineering, tells about a simple change that was made to a major e-commerce site’s checkout process:
By testing the form users had to fill out in order to make a purchase, they discovered that users resisted the process of having to register before making a purchase. The form, which had been designed to make it easier for repeat customers to make quick purchases, actually turned off new customers! Spool’s team removed the registration step and allowed purchasing without registration. As a result, new, purchasing customers rose by 45 percent, and those new purchases brought in an additional $15 million in the first month, a total of $300,000,000 over that first year.
But We Don’t Sell Anything . . .
While departmental sites typically don’t count success in monetary terms, it’s easy to see how simple changes, the result of testing for effectiveness, can bring about better success for departmental sites, as well. While your site may not be a retail site, users are often prospective students, faculty, or even donors. Making a good impression and providing users what they came for will go a long way in building relationships.
For instance, AgencyND was asked to rework the home page for the Notre Dame Law School. Below is a screenshot of the current home page:
The general consensus was that few people were clicking on the buttons on the right side of the page, and that this valuable piece of Web real estate could be put to better use. A simple heat map test quickly showed, however, that users did click on these buttons! As a result, the cost of reworking the home page was drastically reduced by making minor changes versus an entire redesign.
Testing Prior to Launch
Now the question arises: When do we test our site?
The answer: Always!
If a Web agency is working with you to rework an existing site, they will suggest testing the site as it currently stands.
They will want to find out:
Where are users having difficulties?
What pages are doing well and should be left alone?
How does the site compare to other Notre Dame sites or the sites of other peer schools?
Does a rework need to be done? Or will minor, inexpensive changes be sufficient?
They will be setting a baseline for your site for comparison with any rework. (In other words, there’s no sense in throwing out the baby with the bath water.)
Testing After Launch
If you are reworking your current site, your agency will also suggest testing after any rework. This post-rework test will be designed to find out:
Are old problems solved?
Were new ones introduced?
Is there improvement?
What can make it better?
If the site is new, they will most likely suggest testing a few months after launch to find out:
Is the structure sound and logical?
Do users have difficulty navigating the site?
Is the nomenclature working?
What does Website Testing Involve?
Website testing can involve any number of things, but some of the more common tests are as follows:
Heuristics evaluation. The most popular form of testing for usability, heuristics evaluation is simply learning by discovering. By using a website, you will find areas that need improvement. Jakob Nielsen provides a list of usability heuristics at useit.com/papers/heuristic/heuristic_list.html.
Time to accomplish goal. This will measure how long it takes users to accomplish certain tasks relevant to the goal of the site. In other words, if a user wants to sign up for a newsletter, does it take so long that he loses interest or gives up in frustration?
Success rate. Each portion of your site should have some sort of call to action—a place for users to sign up for newsletters, provide their email address, or download documents. Without a call to action, users have no reason to engage with your site, which is what the Web is really all about. The success rate will measure how many users tried to accomplish a task and actually finished it.
Satisfaction with site. This is a measure of the feelings users have about your site. Although your agency and you may feel the site is the most beautiful website ever, if users don’t find it inviting, factual, and worth returning to, the site will have failed in its mission and you will need to review it to find out where to make changes to satisfy user needs and make them wish to return.
The saying goes, “If a user can’t make it work, it’s broken; and if a user can’t find something, it’s not there.”
How Can We Test Our Site Without Breaking the Bank?
There are a number of ways to test your site without paying a vendor. Although you probably won’t get the depth of results you would if you hired professionals to test your site, you can, by self-testing, find a good number of areas that need improvement. You will also find that the more you are familiar with how users interact with your site, the more knowledgeable you’ll become about what you want your site to do and how to accomplish that in the future.
Walkthrough. This simple test is done before launch; however, it would be advisable to return and repeat this test every quarter or so after launch. It involves going through each page of your site “in the shoes of the user” in order to find usability problems.
Survey. You can provide a quick, four-question survey for your users to find out directly from your users whether they are satisfied with your site.
Heat Mapping. For little or no money, you can have heat mapping software added to your site to show where users click in order to find out whether your navigation is easy to follow.
Analytics. Install Google Analytics or some other form of analytics on your site and learn how to “read” it.
In-Person Testing. You can conduct in-person tests asking users to complete certain tasks. While this is a good way to get information, there are some nuances to consider in moderating and setting up such tasks. It would be wise to do some research on conducting these tests before attempting to do so.
So, in Conclusion . . .
As you can see from the examples given, usability testing can be done quite inexpensively, often without the need for paying for help for the simple, quick-and-dirty tests. You can follow this process to gain much insight, and then contact your agency when you want more information or want to discuss ways to improve your site.
You can test in any of these ways:
Walkthrough—no cost except time—Open your website and make note of problems you encounter as you:
Click on any links to verify they are accurate and working
Review for errors (faculty no longer here, misspellings, factual errors)
Review for consistency in style and formatting
Repeat the above for each page of your site, including those not included in the navigation
Follow their simple instructions to modify the survey to fit your situation
Activate the survey
Compile the results and choose modifications to your site as needed
Analytics—Install (or get your vendor to install for you) an analytics tool such as Google Analytics and spend some time learning how to read the results and interpret what they mean. You’ll be surprised at some of your findings!
Heat Mapping—cost of Crazy Egg or similar vendor product and installation (typically $100 or less for one month of testing)
If an agency hosts your site, notify your account representative that you want to use Crazy Egg or another heat mapping tool
Have your agency developers will add the code to your site
Decide how long you will have the test active
Activate the heat mapping and compile the results for future modifications as needed
In-Person Testing—You can, of course, also conduct your own in-person testing with think-aloud protocol. However, you may find that you get better results at a lower cost if you use an outside vendor or your agency to develop and moderate the tests and then provide an analysis of the results.
If you decide to conduct in-person testing yourself, you will want to:
Determine exactly what you are testing for
Prepare a list of questions you want to ask (scenarios describing the task you want the testers to accomplish)
Find five users who fit the model of your “typical” user, if possible
Set up a computer with some sort of monitoring device (Silverback is a good recording software for tracking user movements)
Prepare a moderator’s script for use in testing
Conduct the tests
Compile the results for future modifications as needed
Can We Do This?
You can get a very good idea of major areas of your site that should be reviewed and/or reworked.
Self-testing of your site is far better than no testing at all. However, there will always be aspects of your site that you might overlook because of lack of experience or exposure to the “hazards” and implications of testing. Hiring professionals can help make a difference if your budget allows, simply because they already have trained personnel, testing protocol, and additional tools in place.