grundyhome.com

The web profession is a client-driven one, even when we don’t technically have clients. We’re always teaching, educating the various stakeholders as to best practices, how to use new technologies, and why they shouldn’t waste their time on the flashy buzzword-du-jour.

If you’ve been doing this long enough, these conversations will all be familiar to you. If you’re new to this business or haven’t been in a client-facing role, you’ll do well to familiarize yourself with them.

1. Strategy Before Tactics

Are you sure you even need a new website? What do you mean you heard you needed a Facebook page? Let’s start from the beginning. Let’s start with your audience. Who are you trying to reach? What do you want them to do? If you can’t answer these basic questions, you might as well just start burning money. We’re not just pixel-pushers and code monkeys – we can help you make smarter decisions about what to do.

2. Measurement and Analytics

What gets measured gets improved. This isn’t 1995 – a hit counter isn’t going to cut it. There’s no excuse not to have at least Google Analytics (or something) tracking and providing information. What to look at? Let’s see – top content, pages with high bounce rates, referring sites, search keywords… the list goes on. Oh, and remember: reporting is not the same as analysis. So let’s figure out what we really need to measure (let’s call them KPIs) and set some goals.

3. Search Engines 101

Search engines are a major source of traffic. You can’t cheat the system. Search engines rank you based on the text on your site, the number of links pointing at your site, and the quality (or trustworthiness) of sites linking to you. It’s a little bit like dieting – there are tons of people selling shortcuts, and none of them are sustainable. You have to earn your ranking honestly, over time. Start by creating quality content that people want to read and the rest will come naturally.

4. Design Isn’t About You

I know you don’t like the [color | typography | photos | white space], but that’s ok – the site isn’t intended for you. You’re not your target audience. The design isn’t just about looking pretty (that’s a given). It’s actually about helping you achieve your goals. You remember your goals, right? We talked about them way back when we agreed on your strategy and decided what you were measuring. This design does that.

5. How to Write for the Web

Hey, great brochure. Really, it’s beautiful. But let’s cut to the chase: it’s not a website. You can’t just copy and paste that text into your website and expect it to work for you. Web visitors expect instant gratification. Don’t bury the lede. Make your copy scannable. And for goodness sakes, don’t ever put “Under Construction” on a page.

6. Web Isn’t the Same as Print

When you print something, you’re creating something permanent. You spend a lot of time editing, tweaking, proofreading, and painstakingly checking before you give the final go to the printer. Once it’s printed, it’s done – there’s no changing it. But the web isn’t a print piece. Every time a visitor hits our website is a new publication – a new chance to make a change, edit our content, and fix a typo. On the web, unlike print, you can’t let perfection get in the way of publication. The difference between 99% and 100% is a lot of investment and not a lot of return.

I’ve written and spoken on website usability testing plenty of times. But recently, our team at Notre Dame has begun to seriously investigate other methods, tools, and concepts to improve every part of our projects.

Special thanks to Kate Russell, our information architect and usability coordinator, who has uncovered a wealth of tools and is helping create an entirely new process around one of the biggest weaknesses for so many websites.

Methods and Tools

Let’s start with the specific testing methods you might employ throughout a project.

Gut Reaction/5 second test

Quick–what’s the purpose of this site? Take five seconds to look at a site and list the things you noticed about it. This is something of a free association exercise, but it’s useful for evaluating the overall impact of a site without getting into a ton of detail. You don’t need a fancy tool to do this, but since there is one (and it’s free and easy to use) you might consider it.

Card Sorting

A card sort asks the test subject to help you organize the site in a way that makes sense to him or her. This is a formative or summative type of test, allowing users to help create the solution rather than simply validate the solution you have provided. A card sort can be performed with index cards (print the name of each page on a card) or with specialized software.

Information Architecture (IA) Testing

This type of test uses the same kinds of tasks, but examines it within the context of an information architecture or sitemap. IA testing can be done using an outline, flowchart, index cards, or specialized tools.

Task Testing

Identify common user actions and ask the test subject to do them. These can be phrased as a story:

You are interested in getting updates from this blog when there are new posts. How might you do this?

Task testing can be applied at many different stages in a project, but is most useful when done on a mockup or a working prototype of the website. Too early (wireframes, grayscale mockups) and it’s hard for users to imagine interacting with it, or too late and it’s tough to fix deep-rooted critical mistakes.

Voyeur Analytics

I call these tools “voyeur” tools because they let you watch actual users interacting with your website. These track the mouse movements and clicks of individual users. I’m not sure what the right name is for this one, but it’s a neat idea. It does bring up some privacy questions, but that will play differently depending on your organization and the tools you use.

Analytics, Measurement, and Surveys

Once a site is live, there are any number of analytics and surveys you can use. This goes beyond the scope of “testing,” per se, but it’s a valuable part of evaluating the site’s success. Look beyond traditional stats packages (Google Analytics, WebTrends, etc.) and consider Heatmaps (CrazyEgg or ClickHeat), A/B testing such as Google Website Optimizer and surveys or site feedback tools such as UserVoice.com.

When to Test

When do you test? Test early, test often. Don’t wait until the end, or it’s too late to test.

Download this graphic (PDF)

Before You Begin

What to Test: Current website, competitor websites.
Methods: Task tests, IA testing
Tools: Silverback, TreeJack, Chalkmark

Creating a Site Organization

What to Test: Proposed sitemap or collection of
Methods: Card sort
Tools: websort.net, OptimalSort

Testing the New Site Organization

What to Test: Proposed sitemap
Methods: IA testing
Tools: TreeJack

Initial Layout – Wireframe/Paper Prototype/Mockup

What to Test: Wireframe/Paper Prototype
Methods: Task testing, gut reaction
Tools: Silverback, Chalkmark, fivesecondtest.com

Full-blown Mockups

What to Test: Flattened files
Methods: Task testing, gut reaction
Tools: Silverback, Chalkmark, fivesecondtest.com

A Working Site (templates and content)

What to Test: The development or pre-production website.
Methods: Task testing
Tools: Silverback

The Website is Live!

What to Test: The live website.
Methods: Analytics, surveys, voyeur analytics
Tools: Web analytics software (Google Analytics, StatCounter, WebTrends, etc.), Userfly

Where to Learn More about Usability Testing

• My Usability Bookmarks
• All Usability Bookmarks
• Usability.gov
• Jakob Nielsen
• Steve Krug

Client: “I need a website in two months!”

It takes our group an average of 5 months to produce a website. Damn… clients get some serious sticker shock when they find that out.

So I share our project schedule document, which was supposed to be internal but shows exactly how we arrive at that timeline. Let’s take a look at why that is:

Notice how our total work time is something like 120 hours? Now count up those client days… that’s right, our average website runs somewhere around 40 days of client hold time. Ignoring weekends, that’s two months of hold time where we’re not working – just waiting for the client to send stuff back.

Even if we’re not doing any other project work at all and both sides hit every deadline, we can assume that the project will take at least three months.

Wait a second… After each one of these stages, we also include some lag time – buffer for missed deadlines, vacations, etc. that might interfere with an otherwise precise schedule. In other words, we wait two days before we start the next stage.

Ideally, we wouldn’t need this. But in reality, every single project uses some chunk of (if not more than) their hidden lag time. With maybe 12 stages containing 2 days of lag time, that’s another 24 days of wait. In other words, a little over a month of work days. This brings our total up to approximately 4 or 4.5 months for the entire project.

Sticker shock begins to wear off. Enter the stage of despair.

Client: “But I need my website in two months!”

Me: “What do you want to give up? Do you want shorter hold times? Should we take out our lag time? Can you promise – on penalty of serious project delay or outright cancellation – that you will hit every deadline?”

Client: “…No, I guess not. I have to get approvals from my [department|boss|committee].”

Me: “Then do you see any way to get this project timeline down to two months?”

Why this Works

Clients don’t get what we do. They might think they do, but they rarely understand the amount of work, the process, and the exact location of the bottlenecks in the project. We have a fairly mature process with content planning, research, wireframes, and iterative design and development. Some vendors can turn projects around much faster – they just skip a bunch of the steps we find critical to the project’s success.

Even without other client work, the project’s greatest inefficiency is slow client response times. But the client doesn’t see this – he simply sees the final launch date and assumes you have slow turnarounds.

By breaking it down, with full transparency, the client can better understand the role he plays in the schedule. It’s 2 + 2 = 4. You might not like it, but 2 + 2 will never equal 3 because of poor planning or sheer force of will.

Still, I like to offer a carrot during these meetings:

Me: If you beat your deadlines, you’ll start saving days. We will probably be able to start work on your next phase ahead of schedule. And we’ll have more time to dedicate to refining the end product. So if you’re speedy with replies and approvals, we should end up launching much earlier. Just remember, it’s all about how long you need to get us the feedback we need to continue working.

One of the frequent debates in web projects is around naming of elements. When our team recommends a label or title we usually do so from an outsider’s perspective. We make a lot of arguments for our position, but sometimes there’s resistance.

So we do some user testing. Usually, it’s clear that one option is far superior to another, and that settles the argument. But for some reason, this isn’t always enough.

So we have to explain why we got that outcome. Let’s don our psychologist hat for a moment.

Cognitive Load is refers to the demands placed on working memory. Your working memory is typically limited to approximately seven elements (hence the seven digit phone number and so on).

I believe that cognitive load is strongly tied to user experience and information architecture. If users have a working memory limit of approximately seven items, how can you justify twelve global navigation options?

How does this explain naming choices? The cognitive load increases when there are more interactions between elements. Imagine a visitor to a department website looking for course descriptions. She quickly skims through each navigation item hoping to find one that matches what she’s looking for.

Option 1: Process of Elimination

Unfortunately, she doesn’t immediately recognize that Program might contain course descriptions. She rules it out, or at best decides it’s on the short list. However, after looking through all the options she’s still not sure where it is. So she eliminates the other choices before deciding it’s probably under Program.

Option 2: Affirmative Selection

A clearly named item encourages visitors to immediately select that item rather than consult all other options. It’s been observed that users take the lazy route and do not like to read every word. If at all possible, reduce the number of navigation items and name them clearly. This is fundamental to information architecture work.

Cognitive Load

If cognitive load is connected to user experience (though there are opinions to the contrary), I believe it is most easily seen in the user’s frustration level. One study of working memory and choice observed that, as working memory is taxed, people begin to rely on emotional decision-making rather than rational thought. In short, someone who is trying to recall seven random digits is more likely to make emotional, often irrational choices. Does your website unintentionally push people to emotional decisions about where they even navigate?

Why aren’t you invited as a keynote speaker at the top design conferences? Why aren’t the biggest design firms falling all over themselves to hire you at exorbitant prices? Why don’t you charge $500/hour for your time? How many interview requests do you get each week?

There’s only one “best in the world” and you’re probably not it. So where do you fall? On a scale from zero to 100:

Zero

No talent, not even an ounce of ability. Couldn’t draw a pixel except by sneezing and a fortunate click of the mouse in MS Paint. Let’s assume that you’re well beyond this level. It takes all of an hour to move out of this level.

Novices

These are the starters. Maybe self-taught, maybe a student or an intern or just lucky to get a job in the field. Chances are, a novice isn’t doing this full time yet. This level can take days, weeks, or years depending on how much effort one puts in before moving up.

Professionals

On a normal curve, most fall in this range. But the range is wide, and the prices are all over the place. You can pay $150/hour for a poor professional, or you can find a good pro for $30/hour. It’s amazing. Within this range, it’s also very difficult to identify a good designer from a bad one. This is a good area to find yourself, but it takes some serious work to move up: find a mentor, start a blog, collaborate on projects, and seek out projects that will let you do them well.

Experts

What makes an expert? Attention to detail. Ability to understand the meaning behind the pretty pictures: marketing, communications, user experience, etc. It takes a lot of work and experience to get to this level. And that commands a price. But be careful about judging skill solely on price – business acumen also helps drive price up, so a talented businessman with professional design skills can look a lot like an expert.

Design Gods

These are the select few that will be remembered by the rest. There are no corners cut. Decisions are backed up not by force of personality but by research, experience, and measurement. But it’s hard to know whether this status comes from celebrity – blogging, public speaking, high profile projects – or talent. I believe that great ability should be judged by achievements, not promotion or branding. We may not know the names of the brilliant designers behind some of the products we use, but we’ll remember their work for many years to come.

Where are you?

Which of these are you? Where do you fall on the scale?

Recently, oAk, Jim Gosz, and I were discussing our weekly usability testing program. Someone made the comment that this is the kind of thing that separates the top designers from the rest. Why is this placed here? What makes this more effective? Do we know or are we just guessing? It’s an important step: are you humble enough to admit that you don’t really know the answer and look for ways to find the best solution?

New to usability testing? Want to get a quick start? Check out my post on how to start a usability testing program over at eduStyle…

What you don’t ask during a usability test is just as important as what you do ask. Tests can take a long time and should be considered carefully – what can you cut from your test script? After watching our first test videos, a few things came up that we could leave out.

“How should this be designed?”

Ask for an opinion and you’ll get one. But you’ll get an opinion from someone who isn’t an expert, who doesn’t know the challenges, and can’t consider the different angles. So their design opinion is inherently superficial – what looks good.

A better way to phrase this question is “how can this be easier to use?”

“Would you use this?”

That’s market research. A usability test is about form and function, not inherent value. If you’ve decided to do the project, asking whether visitors find value is asking them to create an imaginary scenario where they might actually need to use the site and then decide whether they would use it. And people aren’t usually that good at quick thinking. So if they can’t come up with this scenario, they’ll say no. And that’s not useful at this stage.

If you are still unsure whether to pursue the project, go do focus groups or needs analysis research.

“Look at this page for a moment… Where you would go?”

We want to simulate real usage. Avoid asking questions that take people too far away from that use case. If you give people a chance to look over the entire page and review all of their options, you may get a different answer than if they simply hit the page and clicked. In real world usage, users tend to go to the first possible match – ignoring later choices even if they might be better. They certainly don’t look read every option and carefully choose.

Try to approximate a real experience with the site by asking a task-based question before you show the site to the user.

Learning from Experience

The fact that you’re testing at all is a huge victory. So even if you’re asking bad questions, you can still learn a ton. Don’t worry too much at first about refining. Just get started and tweak as you go. Remember: you learn a lot more by testing anybody than you do by testing nobody.

A must-read for designers and anyone who works with designers: The ten commandments of Dieter Rams. Some favorite quotes:

The most important task of design is to optimise the utility of a product.

This which are different in order simply to be different are seldom better, but that which is made to be better is almost always different.

Good design is as little design as possible.

Read the full list…

This post is dedicated to oAk and Jim.

Let’s imagine a white wall in a dimly lit room and a subject standing in front of it (who was recently lying in bed and made it to the photo shoot just in time). Let’s further pretend that this photo will be taken on a cell phone or a point-and-click camera. Of course, the person taking the photo will have absolutely no training in photography, so the white balance will be off, the shot will be poorly framed, and of course it will have a nice flash starburst off some surface. Finally, that person will save the image as a 640×480 JPEG and email it to the designer.

And it’s supposed to be a cover image for a brochure. Or the key image in a website design.

Far and away, the easiest way to make a designer mad is by providing crappy content to work with. Sometimes this is “I’ll just write the copy later” or “here’s the photo you need to use, I hope it will work.” As they say in programming, garbage in, garbage out.

It seems that often design is less about accomplishing your communications objectives and more about pulling off a miracle. It is a testament to the skill of graphic designers who deal with this daily, and still manage to produce top-notch work.

So for all those times I (or any client) provided garbage and expected gold, I’m sorry.