Lessons from Pavlov’s Pet Treats

I bake and sell dog treats. I’ve been doing it since last spring and even have my own website. While I’m not getting rich at it, I’ve learned a lot about selling dog  treats during that time. And I’ve learned a lot about selling the University at the same time.

You see, I have a crummy little website at pavlovspettreats.com (any free advice would be appreciated). And I can look at my site and see how it pales in comparison to others and especially to those built by the Web Group at Notre Dame.

I know my site stinks; I just need three things to make it right so that it will actually sell treats: time, money, and an outsider’s view.

Requirement No. 1. Time

Between working at the University all week and baking nearly every night, I’ve not been able to find the time to think out a logical plan for my website. But I’m not alone in that.

Too often our clients come to us when they need a website “by the first of the semester” or “ASAP” or “right now, ’cause we’re sending out brochures and need to provide a website for people to go to.” Thus, they have not given themselves (or us) the time to think out what the website can truly do for them. It takes time and effort to determine

• The goals of the site
• The audience(s) of the site
• How the audience wants to interact with the site
• How the site’s success will be measured
• How the site will be maintained

And speaking of maintenance of the site, too often clients leave that to an overworked, disinterested, under-trained employee to “stick this photo on the site” and don’t have a plan for regularly scheduled maintenance. (My dad would be so proud of me for using that term, which he insisted was the only responsible way to keep a car, a house, a furnace, or anything of value.)

Requirement No. 2. Money

My personal financial situation at the moment is not one to envy. My husband retired in spring; we lost a bundle on a business venture we closed; and Pavlov’s Pet Treats is eating away at any spare cash. I simply have no money for marketing and website design and building.

Again, I’m not alone. Although the University of Notre Dame is not as hard-hit as most higher ed institutions, we have a fiscally conservative administration (for which we still-employed staff are grateful). Thus, we have tight budgets. Our clients are often trying to squeeze the last penny out of their budgets, and they come to us with very little in the way of funds to pay for work.

Our Web Group has to bill for everything we do. Even though the money is “funny money” that goes from one pocket into another, if it’s not there, it’s simply not there.

So clients ask for the impossible. How much website can I get for $X?

In our case, we have DIY sites for a few hundred dollars. With the purchase of one of these, our clients can set up a site with varying degrees of functionality, often solving their problem quite reasonably. The Web Group has designed templates based on University brand standards (recently adopted), and these sites work quite well. With a little bit of training, clients can be off and running in no time. Is it the same as a custom design? No. Not by a long shot. But a DIY site can take care of a great number of needs our clients have.

Likewise, a template such as my current Shopify site could probably take care of Pavlov’s business—if I had the other two components.

Requirement No. 3. Outsider’s View

I am no designer. I am also not a developer. I am, however, in the field of information architecture and usability. But can I put together a site (even a templated one) that works as well as it should? Not without outside eyes.

You see, just as an author should never edit her own work, rarely can a site owner depend solely on his own opinion, review, and expertise to make a site as good as it should be. In most cases, the site owner is so closely entwined with the subject matter that he can’t see his site as a user would.

That’s where it helps to have outside eyes and expert review of such things as

• Organization

• How the Site is Organized—Is your site organized along the lines of your org chart for your department or program? If so, that probably makes no sense whatsoever to your audience. Consider, for instance, Notre Dame’s organization. Would you look under Food Services or Admissions for ID cards?  (Faculty and staff get theirs through Human Resources; students get theirs from Food Services.)
• Amount of Information—Is it best to include several pages worth of information on one page? Or should it be divided into several?
• Redundancy—Are there redundant pages? Should there be?
• Design
  • Colors—Are the colors Web-safe? Can those with color blindness properly read all aspects of the site? Do the colors reflect the personality of the program or department? Are the colors consistent with a larger branding effort?
  • Backgrounds—Is the background consistent with the site’s personality? Does it interfere with the readability of the site?
  • Links, Images, and Videos—Are they appropriate in number, size, and location? Or is there a better way to place them so that they are found and more likely to be clicked on or read?
  • Functionality
    • Calls to Action—Are there too many on a page? Do the links all work? After a user clicks on action items, what happens next? Does it make sense?
    • Analytics—Can you track the analytics for your site? Will you be able to set up filters, goals, and other tracking to help you determine your site’s success/failure?
    • Accessibility—Does the site function well for those with disabilities?

• Usability Testing
• User Expectations—Do users read the terms the way you do? Do they use the site in the way  you intended? Or do they get lost because they don’t understand your terminology or come to the site expecting it to behave in a way you hadn’t planned?
• Writing—Is your site too heavy on the long paragraphs and jargon? Do they lose interest because they can’t easily find something in which they’re interested and want to delve deeper?
• Distractions—Are there too many calls to action, and do they confuse or distract your audience? Is the background too busy and does it pull attention away from the text or make the text hard to read? Does the page appear too cluttered? Is everything on each page really necessary? Or can some of it be removed or moved to other pages?
• Navigation—Does the navigation make sense? Is it logical, or is it too complex? Does the navigation scent lead the audience down the right paths?
• Design—Is the page attractive? Is it compelling? Or does it simply drive away your audience (or worse yet, bore them)? Is the design appropriate to the topic?
• Images—Do the images help your audience? Or do they simply pull attention away from the text? On academic sites, it’s tempting to put the standard “students on the grass” image up, but will that really help move the audience to take the intended action? Or will they see the image as yet another students on the grass, just like every other college has. (One has to wonder if students ever study anywhere else!)

Now What? 

Okay, so I know I need those three things in order to fix my site. And now you know some of the challenges our clients face in building or reworking their sites. Time to roll up the sleeves.

While we’re at it, what else would you include in the requirements for good website needs?

 

 

I was asked to help someone at another college review the need for information architecture (what it is, whether they need to hire someone) as the school looks at a possible redesign of its website. At first, even though I do this for a living, the thought of giving someone else advice intimidated me. But then I sat down and looked at what I (and our incredible team of designer and developers) do when someone asks us to redesign their site.

It’s not Rocket Science

It’s not really that complicated on the whole, although the individual parts of it can be quite complex and time-consuming. I realized it’s a matter of simply thinking through the process and asking the whys and hows before making any decisions.

I told my peer at this other college what I would start with (below).

• Who are the decision makers in the redesign process? (Very important to identify them right away)
• Why do you want to redo your website? What’s broken? What’s working? (analytics and testing)
• Who are your audiences?  Which one is your primary?
• What are they looking for, wanting to do? (survey, focus groups)
• What steps do they currently take to accomplish their goals? (testing)
• Is it easy for them to find what they want? (testing)
• What peer websites do you like, and why? What do you want to imitate (or not) and how can you improve upon it on your site?
• What limitations are there to your CMS?
• Who will be updating the site(s)? Who will be writing content?
• Are there pages that can be combined/cut/added?
• Is there a better way to organize the site? (card sorting, testing)
• Is the design to be changed? If so, can the design help inform navigation? (wireframes, testing)
• When content is migrated, especially if written by numerous people, is there a style guide to follow? (capitalization, serial commas, titles, that sort of thing)

I’m sure I oversimplified and/or left out things to consider. Let us know what  you would add or change!

Our designers and developers do incredible work on our websites. They make them lovely to look at and delightful to use, so why don’t our clients like links that are blue? (Sorry, it’s Monday morning as I write this, and I couldn’t resist trying to tie in a rhyming cliché.)

But it’s true. Our sites are beautiful, and some clients insist that links be hidden in the text without any color or underlining that would identify them as links. They feel that the look of the page is diminished by the change in text style.

When my children were small, the Where’s Waldo? books were popular. They loved to try to find Waldo among all the colors and shapes on the pages. But visitors to your website are most likely not looking for Waldo; they’re looking for specific information. So why do we make them search for links in the name of aesthetics?

Which is more important? Looks or findability?

We in Marketing Communications (fka AgencyND) know in our guts that it’s wrong to hide links, but what do others say about it? To find out, I did a little research. And the experts (Nielsen, et al.) say

If you actually want people to click on your links, then you have to make it obvious that they can and should be clicked.

–Baymard Institute, Formatting Links for Usability

We know that visitors to websites don’t read the entire page on first site; they scan the page, looking for information of interest.  We encourage lots of headers and bulleted lists in order to make the page easier to scan. Why wouldn’t we point out relevant information that is linked to by making it stand out?

What do the experts say about link formatting?

Experts don’t always agree on how to make the links stand out.

• Some say the links must be blue, with different shadings indicating status (unclicked, clicked, active).
• Others say color doesn’t matter at all—that underlining is the way to indicate links.
• Some say that either way is okay, as long as the method of showing links is consistent within the site.
• Still others call for a standard among all websites for usability purposes:

Users get confused if link colors are [non-standard]. Result: Users waste their time figuring out where to click, while spending less time reading and interacting with the sites. Even worse: Users may give up finding they content they are looking for.

–Bohmann, Against Non-Standard Link Colors

Thus, the research and general opinion of usability experts seem to recommend we:

• Underscore all links, no matter the color of the text.

…Only 27% of the sites [100 top American eRetail sites] still use the ‘standard’ blue color for unvisited links….We can therefore conclude that blue/purpose ‘standard’ no longer exists…the main way of characterizing a link is not by using a particular color, but by underlining the text itself.

–Carton, Should hypertext links be blue and purple?

• Make links easy to spot and distinguish as links.

Text link wording should also be emphasized to make it easy to read. Formatting can be used to make links bold or underlined and stand out more so they are not hard to find, allowing visitors to easily find web page links. Good wording and formatting of navigation links give websites better usability.

–Factors Affecting Website Usabilty

• Indicate status of links (unvisited vs. visited vs. active) by saturation of color in order to help visitors keep from clicking repeatedly links they’ve already visited.

…Knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again….When visited links don’t change color, users exhibit more navigational disorientation in usability testing and unintentionally revisit the same pages repeatedly.

–Nielsen (usit.com/alertbox/9605.html)

Changing the color of visited links has been part of Web browsing since … 1993, so it’s completely standard; almost all users understand it….Further, empirical observations from user testing have identified several severe usability problems on sites that violate this convention.

–Nielsen (Useit.com/alertbox/20040503.html)

• Blue is (probably) the best color to use for links.

Since the inception of the Internet, the color of the hyperlink had been blue. Because of this, Internet users had been “trained” to think all blue colored words on a webpage as hyperlinks. Because of this, the blue-colored hyperlink has a higher probability of being clicked than other hyperlinks of other color.

–The Best Color of Hyperlink

In other words, make it easy for visitors to quickly scan the page and locate links in which they have an interest and be able to tell which links they visited already so they don’t go in circles. As anyone who has taken training from me will know, one important key to a successful website is

Keep your visitors happy!

So how do you keep your visitors happy with regards to links? Share your ideas and results!

 

I say “probably” because you can find experts who say that red is clicked on more often than blue. There may be some accessibility issues associated with red, though, especially if the link is indicated by color only and not underlined. (But that gets back to the mantra of “never depend on color alone” for the Web since many users have difficulty distinguishing certain colors.)

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 they thought 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.

Website testing comes in many varieties:

• card sorting
• prototype testing
• pre-launch testing
• post-launch testing
• in-person or virtual,

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.

Oh. And to my test volunteers: Thank you!!!!

I just read a great post by Abby The IA about using social media to create products or processes. I’m hoping that she’ll forgive me for borrowing her thoughts, but I can’t help it. She’s got some great ideas here and I’m using some and will use more as I work on training materials for Conductor, our proprietary content management system.

You see, Conductor is a great product. I use it, and I love it. Lots of clients use it, and most love it. But there are some downsides to it. One of those is training.

I recently got back into training on Conductor when a coworker left the University. And so much has changed in the time I was off, that I find myself feeling inadequate to train.

And, on top of that, we’ve recently started sending out surveys to find out how to better train users.

If you ever want to be brought down to size, try asking people what they really think of you, your product, or your service.

And that’s why I am going to follow Abby’s advice.  Among other things, Abby advises:

Use Your Product.

Well, that’s a no-brainer because I use Conductor almost daily. But I need to learn to see it from the eyes of those who don’t have immediate access to our developers. I need to remember my struggles with it as a novice.

Google Your Product.

That’s not really an option for me since the product is used only by ND folks. However, I can continue to read the surveys; I can continue to encourage folks to contact me with issues, complaints, or their wish lists.

Pay Attention to Bias.

Yes, I must admit. I’m biased toward Conductor because my coworkers create and improve it. But there are a lot of users out there who are just as biased toward Contribute or Dreamweaver because they are familiar with that product. I need to listen to why they are biased; what is it about their product that demands that loyalty? How can we make Conductor better in that regard? Or, in my case, how can I teach them to use Conductor in a way that meets those same requirements?

A lot of times it’s not that the product doesn’t do what they want, but merely that I haven’t taught them how to work with Conductor to do what they want.

Play Devil’s Advocate, Not Naysayer.

Sometimes I want to scream when a trainee asks “Why can’t Conductor do such and such? My product does it!” Or “Why don’t you show us everything about our site? Generic training doesn’t work.” My gut reaction is to defend our product/my training and say something like “Deal with it!” or “Can’t be done!”

But who am I kidding? I’d say the same thing given similar circumstances!

So, instead of screaming, I need to stop and ask questions. Just what is it that makes your product better? Or, if it’s about training, I need to ‘fess up and admit that I need to cover more site-specific details and not try to cram everything into a one-hour session.

So now that this has finally been drilled into my feeble brain, I’m trying to address this. I’m working on handouts to be given to trainees showing them how to edit certain portions of their site that may not be obvious or may not work according to the generic plan. I’m creating “maps,” if you will, to their site.

Will it work? It’s too soon to tell, but I’m asking for feedback on this, too, so that instead of saying “I don’t have time/budget to cover all this,” I’m saying “Here are some concrete examples of how to work on your site. And let me know if you need anything else.”

Have No Toes on Which to Step.

This is a hard one. My toes tend to be sensitive when coworkers or others try to tell me how to do my job. But I’m learning to dance with them. I find that sharing the spotlight (and work) with others and giving them credit for their input makes for a better product. And if I’m saying I want a better product, then I’d better be willing to dance with others, including users!

Make Things Bigger and then Smaller.

This is what I had planned on doing when I approached my supervisor with the idea of creating these handouts. I figured, quite frankly, that he’d say that we couldn’t spend the time on this–that it wouldn’t fit into the training budget for the sites.

He fooled me. Seems he’s as committed to doing what’s right for the users, as well!

So, in this case, I started with a big idea, but didn’t have to shrink it down. Win-Win!

Admit When You Have No Skin in the Game.

I should be used to this, right? I mean, I’m an IA and (temporarily, at least) a trainer. But it’s difficult to admit to clients (users) that I can’t make decisions as to increasing the amount of face time; that they need to call support, not me, each time they have a question since we have to bill for our time. But I have to admit this.

And in the long run, users tend to understand there are restrictions (even they know I’m low in the food chain). And that way, no one has expectations that get dashed or feel they have been misled.

Am I doing all this? Heck, no.

Am I working on doing all this? You bet! Whether it’s Conductor training, website best practices, or just learning everything I can about my career, I’m trying my best. And isn’t that what our clients want, after all?

So whether you’re working on training materials, new websites, or some other service or product, I’ll wager you can find a way to use Amy’s points to make your work better. Let me know what you think. Personally, I’m glad hers is one post I got around to reading!

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.

useit.com/alertbox/annoyances.html

Isn’t user feedback enough?

And from Caroline Jarrett (http://www.effortmark.co.uk/), I used

• Visitors who hate the site leave promptly without responding.
• Visitors with minor problems: broken links, typos, etc., often provide feedback, as do those who love the site.
• The majority probably think the site is OK and don’t bother to tell you this.

Therefore, feedback isn’t a reflection of the overall spectrum of user experience, though it can highlight specific problems.

Even if no single annoyance stops users in their tracks or makes them leave the site, the combined negative impact of the annoyances will make users feel less satisfied.

(Jakob Nielsen, useit.com/alertbox/annoyances.html)

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.

Boy, we’re lucky to be at Notre Dame!

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[1] 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.
• Make sure it’s not spammy. If you think your URL might be considered spammy, check it out at http://www.seomoz.org/labs_tools/spam-detection/ before requesting it.

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?

Department/Program	Current URL	Alternative SEO-Friendly URL (much longer)
Advanced Diagnostics and Therapeutics	advanceddiagnostics.nd.edu	advanceddiagnosticsandthereapeutics.nd.edu
Alliance for Catholic Education	ace.nd.edu	allianceforcatholiceducation.nd.edu
Department of Applied and   Computational Mathematics and Statistics	acms.nd.edu	appliedandcomputationalmath.nd.edu
Applied Investment Management	aim.nd.edu	appliedinvestmentmanagment.nd.edu
Notre Dame Magazine	magazine.nd.edu	notredamemagazine.nd.edu
Robinson Center	rclc.nd.edu	robinsoncommunitylearningcenter.nd.edu
Strategic Research Investment	sri.nd.edu	strategicresearchinvestment.nd.edu

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!

---

[1] 2008 MarketingSherpa eyetracking heatmaps show short URLs are clicked 2.5x more often than long URLS (http://searchengineland.com/supercharge-your-urls-for-maximum-seo-impact-14006)

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.