LarryRoth.net

David Churchville has a nice post that poses the question:

Does the agile software development mantra of "Do the simplest thing that could possibly work" lead to functional, but unremarkable software? ¹

He continues by pointing to an example of when functionality might be chosen over usability.

It's an interesting thought, but I feel the main benefit of agile development is to test early and test often. This testing, if done properly, should help to find usability issues. And then, agile development really helps out by not only finding the issues, but by fixing them before they are released.

Said another way, in traditional software development, it seems all to common that when the deadline slips, one of the items that is often discarded is usability testing. Any early testing—while perhaps not true usability tests—will help out.

Ebrahim Ezzy and Richard MacManus over at Read/Write Web put together a nice summary of Search 2.0 and how it compares to traditional search. They define Search 2.0 as the third generation search technologies and that they are:

...designed to combine the scalability of existing internet search engines with new and improved relevancy models; they bring into the equation user preferences, collaboration, collective intelligence, a rich user experience, and many other specialized capabilities that make information more productive.

¹

In their post—which by the way is part 1 of a 2-part series—they examine 5 different Search 2.0 companies. They point out a key feature of each and also compare it to traditional search (e.g. Google).

What was interesting for me is that when I went to try the search engines they mentioned, 2 of them were down, 2 required a setup process, and several of them were simply returning Google results with their own "value add", such as clustering.

Does having to train a search engine or relying on an unknown communities' rankings really further search? I have always felt that technology should help automate things for us, not require more effort on our part. The lure of Google was—and is in my opinion—the simple page with only one thing to do, enter a search term. And you could be reasonably certain that you would find the information you wanted within the first couple result pages.

I must admit, I did like some of the added functionality in Clusty—although as part owner in a Branding firm, it feels wrong to mention anyone named Clusty.

I noticed a couple of comments to the post with which are worth highlighting:

• ...I think the people that want all this Search 2.0 nonsense are the people having trouble coming up with a comprehensible list of phrases to describe what they're talking about...
• Part of being a good search is... uptime! (and speed).

Check out the post, it's a good read.

When conducting a usability test, it is common practice to follow a procedure similar to this:

• Create user scenarios
• Prepare tasks
• Observe various users while executing these tasks
• Mark successes and failures
• Look for patterns and areas of concerns and provide feedback to the application owner

I have always found one of the toughest tasks to be defining what is a success and what is a failure—it's not always cut and dry. And this is defining success/failure from the test perspective. But I recently began to think it is even more difficult to track what is a success/failure from a user's perspective. Why would that be? Why wouldn't they be the same? Don't we ask users if they feel they have completed a task? Well, when we define a success, it is really limited to a task, but the user may see that task as a larger process. Let's take an example.

I recently booked a room at a national hotel chain using their on-line reservation system. When I arrived at the hotel, I found out that both the rate and the number of guests differed from my confirmation sheet. It turns out that their reservation system faxes the information to the hotel property and that information is then manually keyed in—leaving obvious room for error. In my case, the error was rectified politely and professionally, but it made me think about what makes a usable experience. It made me wonder about a successful task vs. a successful process and what the perception of the user may be.

In the example of a hotel reservation system, if I had been asked to conduct a usability study I would have focused on the reservation form(s) and made sure that users could complete the task of reserving a room for a specific property on a specific day. If they could, I would have thought of it as a success. And that may be fine for the purposes of the usability test. But stepping back and examining the experience from a users perspective, the task may not be a success until they are actually in their room!

I know what your are thinking. First off, there are a lot of "what ifs..." here, and secondly, it certainly isn't the goal of a usability test to identify such broadly scoped successes or failures. I agree with both of those statements, and I am certainly not proposing larger, more involved testing—unless someone wants to fly me around the country trying out reservations at 5 star hotels!

Seriously, my point is that as usability experts, it's our goal to remind the client that we are testing very granular tasks to a sometimes much larger process. While we may help to remove all the barriers a users encounters, the user will be judging the process as a whole, and there may be some hidden barriers that can't easily be tested. Thoughts?

When planning out a project schedule for a new or redesigned Web site, one common question is when do we run usability tests? I don't believe there is an one easy answer to that question.

My preferred answer is: If there is budget for it, test early and often! Setting up a test plan early on will allow you to not only incrementally test and tweak your designs, but if you are engaged in a site redesign you can also use the same repeatable testing procedures to get a baseline from the existing site. Not only will you be able to the new design is solid, but also you can show improvement over the existing site.

Testing could occur as follows:

• Baseline test of the existing site
• Low fidelity test of approved wireframes
• Test of graphic comps
• Test of completed site on staging server

In addition, the same test plan should be used after the site is live, to keep an eye on the site as it progresses.

Of course, the biggest concern is the cost—in time and money—of running so many test. Rather than give the overused response of how testing up front saves more money down the road, I prefer to point out that setting up the test and creating the report is the lion's share of the time required, not recruitment and subsequent execution. It's amazing how efficiently you can write up a report for an existing test the second time around.

Another issue is that clients will often be concerned that poor test results will affect the project schedule. Instead of jumping into a discussion about what is most important, I have found it helpful to let them know that the results of testing are usually minor tweaks that can have major impacts. It is usually the case that they feel poor results mean we will mean starting all over.

Despite the fact that I believe in testing early and often, at BrandLogic we have only every had one client that would allow us to engage in this level of testing. And it's interesting, they were ranked by an independent third party to be number 1 in their vertical market with regards to usability. hmmm.....

An interesting study by researchers at the Carleton University in Ontario provides evidence that Web users form an opinion about a Web site in some cases before they even discern the contents of the page. Researchers flashed pictures of Web sites for as little as 50 milliseconds, and test subjects were still able to form a judgment about what they saw. ¹

From the article:

"...the strong impact of the visual appeal of the site seemed to draw attention away from usability problems. This suggests that aesthetics, or visual appeal, factors may be detected first and that these could influence how users judge subsequent experience.... Hence, even if a website is highly usable and provides very useful information presented in a logical arrangement, this may fail to impress a user whose first impression of the site was negative." - (Lindgaard 2006)

What this study re-enforces is that even though usability is an important aspect of any Web design, you can not overlook the emotional response to good design. Your users are going to make decisions about your site, based on their visual impressions—and this study seems to show that this occurs a lot quicker that one might have imagined.

Make sure you do a usability study, add some useful and cool functionality, and provide top notch content, but just don't forget skimp on the design.

If I were asked what the single most argued point of Web design is at BrandLogic, it would unequivocally be font size and color. This is an argument that occurs both internally between graphics designers and Web strategists, and externally when we present our concepts to clients. Everyone seems to have a thought about what the ideal font size/color is, and it is always the one item about which they are not too shy to comment. Inevitably, reference is made to some unknown study that claims 12pt black type (or some other combination) is ideal. And what is the number one rational for their point of view? Legibility/usability.

Please allow me to clear up one misconception. Legibility and usability do share a relationship, specifically for a user to find a block of text usable it must be legible. However, this relationship does not mean that legibility is usability. Usability—with regard to the Web—emcompasses the Web site as a whole. There are many things to consider. Audience: who are your users? There is also content: Is it appropriate for the audience? is it clear, on brand, on point? There are user interface elements such as labeling, focal points, and action feedback. And of course there is graphic design, which at a minimal encompasses layout, color, graphics, line length, page size, and yes, typography.

Typography itself is an art form that is much more than font size and color. Thanks to CSS we Web designers are finally learning this. I remember an early lesson when I was a seasoned Web developer, but naive to design (and I probably still am). A very brilliant, and thankfully patient designer was rebuking my challenges that his chosen font size and font color made for illegible content. To my astonishment, he did not disagree with me, but simply pointed out that we had only applied two attribute of this typography specs. He gave us a quick lesson on typography, probably one-one thousandth of what he knew on the subject, and asked us to adjust some other attributes, specifically leading and kerning (letter-spacing and line-height). To my astonishment, those simple changes drastically affected not only the legibility, but also the feel of the page as a whole. The page felt lighter, my eyes could track the text much easier, it was a more enjoyable experience.

Still, even with more granular, and properly applied control over fonts, concerns about size and color still come up. Why is font size such a contentious issue? First off, it's an easy target because size and color preference are just that—preferences, and that makes them by nature very subjective. I contend that the major problem is there are no hard and fast rules for what color or size a font should be. It is very audience and design dependant. To some degree, the design will drive the decision of font size and color, but in my humble opinion, a good designer will let the needs of the intended audience drive the design.

Industry experts have weighed in and given us their opinions. Leading Web usability expert Jacob Nielsen once wrote: "Tiny text tyrannizes users by dramatically reducing task throughput." ¹ A bold statement, and not without truth! And in the same article, he goes on to make his recommendations—both to browser makers and Web designers. But the rules are not concrete, or at least I do not view them that way.

It boils down to this: font size and color alone can affect usability, but you must examine the Web site as a whole. Conduct a usability test on the site, and consider these guidelines with regard to font size and color:

• Ask the users to read a page.
• Refrain from asking them subjective questions like, what do you think of the font size?
• Instead, ask them questions about the content and while you are noting their comprehension, see if they offer opinions about the legibility.
• At the end of the test, ask what they think of the design of the page as a whole.
• At the end of the test, if they haven't already offered the information, ask what they thought about the legibility.

Don't let a good design be altered by a subjective opinion, but also, don't ignore the empirical evidence if it shows your users are having trouble reading your site. If your time or budget doesn't allow for a usability test, then point to other sites you have done that use a similar size font and were also tested. Also, look for popular, well-respected Web sites in the same industry that cater to the same audience. Perhaps they use a similar size and/or color font. This of course goes against my statement that design must be treated as a whole, and these arguments are not concrete, but maybe can provide some supporting evidence that your font choices are OK. Your client wants reassurance that they are not making a mistake.

Too often I have seen the comments of a few "squeaky wheels" push a client into decision that has a much larger, negative impact. Remember, you need to help educate your client about design and usability, just like someone most likely helped to educate you.