Quality Testing Your Site

By Alan Eggleston

We can probably all agree that the worst thing you can do is create a frustrating experience for your customer. That is certainly true in the online world, and even more so in the world of online ordering. A frustrated customer is a lost customer – very likely forever. So how do you avoid creating one?

In my experience as a web editor, the best way to avoid frustrating a customer is to build a sterling back end ordering system and then test the heck out of it before you let a customer anywhere near it. We did that when we launched a massive membership and ordering site, and it was very successful.

We broke quality testing into two phases:

Phase I was during development, which naturally occurs as designers and programmers are building a site. Programmers test processes as they create them, looking for coding errors and little things that just don’t work right.

Phase II was at the end of development in the month before launch. This was the tweaking-what-works stage, when the whole development server is running and all the systems are working together.

Rigorous Pre-Launch Testing

Here are all the things we tested using SQL Server and a tracking programming to note and update testing progress:

  • Site log-in for various levels of membership
  • Main navigation
  • Secondary navigation
  • Hundreds of pages of product pages and sub-pages with photos and graphics

Before this we needed to separately program and test the building and loading of a content management system for product information and graphics/images.

  • Alt tags on all photos and images
  • Links – both hypertext and hypergraphics on every page
  • All server error pages (these we had to ferret out from each programmer)
  • Entire sign-up process, including resulting e-mail messaging responses
  • Entire ordering process, including resulting e-mail messaging responses
  • Shopping cart process
  • Customer service forms and response messages
  • Business information processing apps and response messages

During testing, which involved a half dozen dedicated testers and a supervisor, the process included not only initial testing but also follow-up results testing (once something was found to be faulty and it was fixed, it had to be retested to make sure it finally worked the right way – a bad fix is not really a fix). Some problems, of course, were easier and faster to correct than others.

We were ready to launch on date as announced. Everything went well, except we didn’t have nearly enough servers to meet demand, which kept crashing from overload.

Of course, not all sites are as complex as this site was (and still is today). Your site should still be quality tested before launch even if it doesn’t have all the bells and whistles I list above.

Navigation still needs to work. Links still need to connect. Photos and graphics still need to load. Error-page messages should still be appropriate, and if you can customize them, all the better. You still need to make sure an order triggers all the appropriate response messages.

Far from trusting the server to do its job, you need to test it to make sure you’re taking care of the customer!

Next Up – Quality Links

What links are most likely to best help you optimize your site to help readers find your site in a search? You might be surprised. Find out in my next article!


Dick Tracy Lives: Wrist Watches Become the New Frontier

Learning to adapt your content to various devices is one of the challenges of being a web editor. Mobile technology has brought new delivery options, and this will continue to expand into new frontiers as time goes forward. No doubt many foresaw the cell phone craze or even the tablet explosion. But wristwatches?
The wristwatch came into being in the mid-19th century, yet didn’t really become popular until after World War I. Chester Gould, the creator of the Dick Tracy comic strip, introduced the two-way wrist radio, and later TV, also creating great excitement in the children (and adults) who read the strip. Even though Gould introduced this item in the mid-1940s, it has not become a popular part of people’s daily lives in the years since its debut in the strip.
However, according to the New York Times, the wristwatch may be the next frontier in electronic devices. In the article, “Disruptions: The Next Wave for the Wristwatch,” this next generation of wristwatches will probably be used more for connecting to email or Twitter or Facebook by syncing with a cell phone or cell phone app.
The New York Times says it’s also possible to use the electronic wristwatch as a data collector – such as how much activity you are performing each day, and having that data transferred back to a larger device (phone, tablet) for data collecting purposes. But who’s to say that websites wouldn’t be the next bit of information to be served up on one of these devices? Possible? Certainly. Practical? Who knows? Perhaps streaming summarizations – the Twitter abstractization – of a web page’s most essential points – might be the way to go. Maybe the smart wristwatch would send the site’s link to one of your other devices for follow up later on a larger device, while giving you the salient points in the meantime.
How would that affect what web editors do? Would developers and designers be able to create a structure that would allow editors to present our content on a wristwatch in a meaningful way? Would the wristwatch be able to give us the satisfaction of full content – not just an abstract or a summary? Or would the miracle of website content on a wristwatch be destined to remain an abridged version of what is possible on a website?
The push-me-pull-you continues as devices continue to determine which direction in size we need to go. Smaller? Larger? Combining the functionality of a phone, TV and computer into the perfect mobile device. Who will win? Stay tuned.

When Content Knowledge Saves the Day

by Alison Lueders

I do apologize to those of you for whom bringing up the topic of “school” before Labor Day is heresy. But here in Florida – you know, the land of steamy temperatures and 17.5 foot long Burmese pythons that can eat your car, with you in it – yesterday was the first day of school. My daughter is off to high school for the first time. Ninth grade. At a really good public school. That she doesn’t want to attend.

As I listen to her dismay over the stepped-up workload, I remind her that, “It pays to know stuff.”

One reason I think that web editors are among the unsung heroes of the world is that they know stuff. Often an amazing breadth and depth of stuff that they bring to bear to make their clients look better than they otherwise would.

Case in point: last week, I edited the transcript of a recorded interview between a well-known business coach and a successful businessman. Along with fixing the “ums” and “ers”, I spotted some content errors that made me appreciate my business background anew.

In one case, the speaker was contrasting the relative price positions of two well-known retail brands. He misspoke at one point in such a way that he contradicted himself. And the transcriber dutifully transcribed exactly what he said.

This is no reflection on the speaker. Any hour-long, one-on-one interview is almost impossible to complete without something like that happening. And the transcriber did his or her job by faithfully recording the words. But for the transcript to make sense to readers and to be factually correct, it was important that the actual intent – not the spoken words – be restored. So with the client’s permission, that’s what I did. Because I understood both the business concept he was discussing and the particulars of his example, this content error was corrected early.

In the same interview, the speaker stressed the importance of gathering quantitative data from your customers about what they think of your offer. According to the transcript, he spoke of asking customers for “55 minutes” of their time to complete a survey. I don’t know whether he misspoke or the transcriber accidentally hit the “5” key twice. But I was pretty sure the speaker meant to say “5 minutes”, not 55. The point is, a web editor with content knowledge – in this case, how customer surveys in business are done – is more likely to recognize content errors. This was another case where, once brought to the client’s attention, the intent was restored.

As a web editor, do you spend more time focusing on the correctness of the content itself, or on cleaning up the content (e.g. typos, spelling, etc.) to make it presentable? Or is it something else entirely?

Happy “end of summer” to all!

Truth, Typefaces, and Thinking

Riddle: When does a hard-to-read font lead to better comprehension?

Truth in Baskerville

Earlier this month, I came across a piece in a New York Times blog about the effects of typeface on the persuasiveness of a message. The piece includes an intriguing bit of anecdata from designer Phil Renaud and a web-based experiment.

Renaud had written 52 essays for university classes, and when he noticed an improvement in his grades, he was skeptical that his essays had gotten better when he was actually spending less time on them. One thing he had done differently was change the font:

  • 11 essays were in Times New Roman
  • 18 in Trebuchet MS
  • 23 in Georgia

When he computed his average grade for essays in each typeface, he found that while essays in Trebuchet came in at B–, those in Georgia averaged out to a solid A.

Because this was anecdotal information, the author of the NYT blog post, Errol Morris, created an experiment to try to determine whether typeface really has an impact on the perception of truth.

If you want to participate in the experiment yourself, stop reading this and go read Are You an Optimist or a Pessimist?

The typefaces he compared were:

  • Baskerville
  • Comic Sans
  • Computer Modern
  • Georgia
  • Helvetica
  • Trebuchet

Baskerville came out ahead; that is, it was found to generate the most agreement and least disagreement with the statement used in the experiment. Comic Sans, not too surprisingly, came in last. The results for Helvetica surprised me most of all. It came in second to last. Read the results found near the end of Hear, All Ye People; Hearken, O Earth (Part One). The message here is that typeface does affect perception and persuasiveness.
Baskerville is believable.

But why are people swayed by the typeface when the content hasn’t changed?

Cognitive Ease

I recently finished reading Daniel Kahneman’s Thinking, Fast and Slow (and I recommend it). In one section he explores the ways we can manipulate the delivery of a message to make it more believable.

A summary of the tactics found to boost truthiness:

  • Increase legibility—a boldface statement is more likely to be believed than a similar statement in normal type.
  • Maximize contrast between text and the background; avoid text colors in the midranges of contrast (against white) such as yellow, green or pale blue.
  • Use short, common words. Pretentious language and long words give readers the impression that the writer is neither intelligent nor credible.
  • Use rhyme to make your message memorable. In one study, rhymed aphorisms were considered more insightful than the same ideas expressed without rhymes.

Advertisers have used these methods for decades, and it can be discouraging to acknowledge that people are so easily misled and manipulated. What all of these tactics have in common is that they make things easy for us: We find things believable when we use our quick-impression mode, and the quick impression is our default mode of decision making. It saves a lot of energy (and works well enough most of the time) if we can skip the work of analyzing an argument for holes, avoid the struggle to keep an idea in the forefront of our minds while we judge its plausibility, and avert any strain in reading or interpreting the message.

Cognitive Strain

Back to that riddle in the opener:
When does a hard-to-read font lead to better comprehension?
Answer: When you want people to stop and think.

Also in Kahneman’s book are explorations of cognitive strain and cognitive ease. He describes results for a Cognitive Reflection Test (CRT). An example of the type of puzzle in the CRT:

If it takes 5 machines 5 minutes to make 5 widgets, how long would it take 100 machines to make 100 widgets?*

100 minutes   OR    5 minutes

Experimenters gave the test in two formats: Half the subjects saw the test in a fuzzy, gray, small typeface—legible, but hard to read. The other half saw the test in a normal font. The number of people who made at least one error in the CRT was 90% in the normal-font test and only 35% in the hard-to-read version.

In other words, performance improved (a lot!) with the bad font.

The strain just to read the questions helped test-takers avoid being misled by the (incorrect) answer that leaps out as intuitively right. The ease of reading something can lull us into going with the first answer that comes to mind. When we strain, physically, to read something, we have also recruited a part of us that is willing to strain to really think—slowly and carefully.


To my mind, there are two ways to look at the results in the Baskerville–Comic Sans typeface experiment by Errol Morris.

One idea is that readers want a font that matches the tone of the message. Comic Sans for conveying scientific results doesn’t work. Baskerville, with its long history and use in academia, has an accessible yet serious feel. For factual statements that persuade, Baskerville makes sense.

The other way to look at the results has to do with cognitive ease and cognitive strain. When we’re faced with a statement presented as fact—particularly when we don’t have expertise in the subject—how do we evaluate the truth of that statement? In general, we go the easy way, the way it seems to us: we allow the presentation of the statement, the word choices, legibility, typeface, colors, and all the other associations we make (mostly) unconsciously to meld into an overall impression.

Comments welcome.

* Answer: 5


Multitasker vs. Distracted – Which are You?

Web editors are born multitaskers. We have to be. Rarely a day goes by that we don’t  have to handle multiple projects and juggle scope creep.

Yet a recent article on Mashable.com claims that only two percent of people are really true multitaskers. They cite OnlineCollege.org, which says that what most people think of as multitasking is really distraction.

“For example, employees who use a computer for work are, on average, distracted every 10.5 minutes,” says the Mashable article. “Students who bring their laptops to class aren’t doing much better, since 62 percent of the web pages that they open during class are completely unrelated to the lecture. And what about the 67 percent of people who check their email or use a mobile web browser while on a date?”

Even more frightening: “Focusing on more than one thing decreases your productivity by 40 percent and lowers your IQ by 10 points, according to Harvard Business Review. And it almost goes without saying how dangerous it is to multitask while driving.”

 Are you a real multitasker in your job, or are you merely being distracted by another project that you’d prefer to be working on or have to work on? Do you feel your basic intelligence drops the more you have to handle?

 In this age of information explosion, it could be that we’ve just learned how to multitask the distractions.

Usability in Redesign

By Alan Eggleston

How do you get a site redesign right? How do you make sure it fits the needs of your users and will be useful when they come to the site? Two words: Usability Testing.

Certainly, a needs assessment is important. You would want to pool the opinions of your various stakeholders to make sure their voices are heard. You would want to take advantage of the experience of your designer and developer, no doubt about it. But when the preliminary input is received and you begin piecing together the site, theory and input fall to the wayside and the practical takes over. That’s when usability testing is invaluable.

There is always the pressure from within to think we know our users. Yet, until we ask them, until we query them with design-in-hand, until we give the user a chance to interact with our handiwork, we never really know whether our site works for the most important person for whom the site is made – the user.

Usability testing occurs at different milestones in the redesign and tests your assumptions about site navigation and function by having actual users play around with it. They may also test other aspects of the redesign, like color, font, the use and location of various elements, but key to the testing is navigation – it asks the user, does the way we’ve laid out the site make sense to you and is it functional for you? You would be surprised how often our assumptions on behalf of users are wrong.

Stage I – Test Your Thumbnail

At an early stage, it is useful to test a thumbnail or wireframe of the redesign with users. Let them see the home page and ask them to look at it where they think they might go to find different things. It might be as rudimentary as pointing to navigation bars or page elements. If you have named your navigation, this is a good time to test whether it works for the user and which named ones don’t. Even if it is just a rough layout, you can also test where their attention is drawn and where they would like to find different kinds of information.

Stage II – Test Your Navigation

At an intermediary stage, it is useful to test out your articulate site map – your hierarchy of links. If you have a technical structure built, let users test out your navigation. If not, create an interactive graphic that lets you expose navigation levels as they try to drill down. Ask them to use navigation terms to tell you where they would go to find information or items buried beneath the top levels. Be sure to ask them to locate links on the home page that are not in the main navigation bar, such as “Contact” or “About,” which might be at top right or in footer navigation. How long it takes them to respond can tell you how easy it is for people to use your home page. It may be inconvenient, but there should never be a time when you can’t rename something or move something to aid the user when it’s apparent its current name or location isn’t working.

Stage III – Test Your Site

Near the end, when you want to tweak the site before launch, you should bring in the users one more time. This is when the site is built, the links work, the pages are mostly finished even if there are a few stragglers still under development. Now ask your user testers to use the site for a set of defined tasks but also to play around. I would ask: What works well and what doesn’t? What excites you and what disappoints you? What’s a positive surprise and what’s a negative surprise? What worked well and what didn’t work (recognizing that a site still in development may not allow some operations to proceed)? When did you get lost and did you ever feel frustrated? Now consider what it would take to fix any of the issues brought forward by those questions. That close to launch, you may have to save them for site updates, but if they are easy fixes or problems that are critical to site success, you might have to hold the launch until fixes are found.

Testing with Science

One more usability test I didn’t mention till the end: A full-bore market research science-based usability test using computers and cameras and metrics to see how users physiologically react to and use a site – either an existing site for future planning or a new one in development. I waited because these can be costly and not everyone can afford one. But if you can, I highly recommend it. What you learn about how your users actually see and read and react to and use your site is invaluable insight. Assume what you will about your site and users, this is the real thing.

Next Up – Inside Testing

Once you’ve redesigned a site and tested it with users for usability, you need to quality test it to catch the bugs before you release it to the world. Let’s talk quality testing in my next Web Editors article.

Content Strategy for Web Editors

By Jennifer Ford

I believe content strategy is something web editors should understand and incorporate into daily practice. But I am no content strategy expert, so I invited a friend and long-time content strategist to answer a few questions. Monica Hays has been a web content strategy professional for 6 years and shares some information here you won’t want to miss.

1. What is content strategy? 

Such a simple question and if you ask 100 people, you’ll probably get 100 different answers. Here’s my stab at it.

Content strategy is the planning, implementation, and maintenance of a successful experience for the end user using words.

Using words? Sounds pretty basic. But at a base level, a successful user experience is comprehension. Did the user accomplish what she wanted from your site? Were you able to get across your business goals to the end user? A content strategist looks to achieve goals for both the end user and the business using words.

2. Who uses it?

We all use it. But before I invoke the ire of content strategists everywhere, let me explain: in planning for a site, app, process, or anything that will be consumed by your user, there are three equally important elements that work together. The content strategy, information architecture, and design. In my organization, we’re fortunate enough to have individuals working in these three roles. In our planning sessions, the information architect will chime in on how she thinks something should be written, the designer will chime in with how the page should be organized, and I will chime in with how I think something should look. But ultimately, we each have our disciplines in which we focus and are responsible. The content strategist (and subsequently the editor) is the decision maker when it comes to how we speak to our end user.

3. How do you use it in your current role?

I work for a relatively large organization where I’m able to focus on the words and their presentation. This entails visioning with the information architect, designer, subject matter experts, business managers, etc. In this planning process, we research what the client wants and how we are uniquely capable of delivering it. Then we devise how we want to present this to the user. My job is to write to this, marrying the clients needs with business objectives.

But it doesn’t end there. I work with the development teams using a content management system. I adhere to style guides and follow brand standards. I govern and maintain this content through elevation and into post-production. In my world, all of these elements run concurrently which leads to additional challenges (cough, agile methodology, cough), but that’s another topic for another day.

I must admit that I’m lucky to have all of these roles in place. So many of my colleagues and respected leaders in the CS community are freelancers, consultants, or they are simply the only person on the team wearing the UX hat. But when it comes to content strategy, the goal is the same: to help the user achieve success using content that is clear and concise. (For more info about what “clear and concise content” actually means, please see question 4.)

4. How can web editors incorporate content strategy into their work with managing website content?

This is a really great question. Editors are integral to a successful content strategy. While I may write the content and figure out the best way to speak to users, I’ve had the benefit of countless hours of research with subject matter experts and planning with IAs and designers. Editors are often brought in near the end of the project cycle and as such will have no effect on changing the organization, look, or feel of the page or flow. The editor is then limited to moving around words on a page or even worse, be relegated to simply proofreading for grammar and misspellings. (Not that this is bad per se, but the editors I know generally enjoy flexing their red pens in a more meaningful manner.)

Join your writer or content strategist often and early in visioning and development. Ask questions. Learn the goals of the project. The biggest challenge I face (and probably to the frustration of my editor) is that I’ll send my copy for review but then I’ll need to disregard suggestions because they just don’t align with the project. Perhaps the changes don’t mesh with how we want to speak to the user. Or even worse, the edits just won’t work in the space given.

These suggestions are definitely perfect world scenarios. Where there are writers, there are even fewer editors. But I think being engaged with the different elements of the project will provide a broader understanding and will only make the edits more meaningful to produce a winning content strategy.

5. Can you recommend resources you find helpful for learning more about content strategy?

Join your local content strategy Meetup group! In Philadelphia, we generally try to meet once a month where we’ll have cool speakers, fun workshops, or just a happy hour for mingling and networking (http://www.meetup.com/Philly-Content-Strategy/).

Read the CS bibles. Killer Web Content by Gerry McGovern (@gerrymcgovern), Content Strategy for the Web by Kristina Halvorson (@halvorson), and The Elements of Content Strategy by Erin Kissane (@kissane).  I’m also really looking forward to Karen McGrane’s (@karenmcgrane) book, Content Strategy for Mobile.

Follow peers in the industry. I love the Brain Traffic blog, and I read a ton of great articles linked from super smarties I follow on Twitter (@abookapart, @GeraldGant, @angelacolter, @ahaval, @hejhejnatalya, @rahelabto name a VERY small few).


Monica Hays is a content strategist for an investment firm, where she plays with words and fights against excessive ellipses. Follow her at @SuprMonica.

I’d love to hear from you if you’re a web editor and a content strategist in one. Share your experiences below!