How Bad UX Happens

And now, a note about imperfect user experiences and how they happen. 

The late-breaking requirement

The UX is perfect, things are going great, and you just finished usability testing. Then the client calls and asks you to add something. It's not a problem, it's just a small tweak. Easy! 

A few weeks later, you're looking at your screens and wondering how things went so wrong.

Daniel Kahneman would blame it on a lazy controller. Basically, your instinctual mind makes a snap decision based on previous experience and your analytical mind blindly follows. Most of the time, this works well. Other times, not so much. Maybe you were rushed, or didn't quite understand the full impact of the change. Either way, once you look at your design change with a fresh mind, you can see what you would've done differently.

The early design that overstays its welcome

The other good time to unwittingly make a mistake is early on. You make a solid choice based on the information that you have at the time. But as you refine the design and learn more about the project, this "solid choice" becomes irrelevant or even totally unnecessary.

You, and probably the larger team, have gotten used to seeing it, and you have a type of "banner blindness" to your own work. And maybe it's so irrelevant that usability testing won't uncover it, because it literally is useless and unremarkable.

Much later, you or someone on your team notices it and you see it for what it is - clutter.

How to fix it

These types of unitentional mistakes get shipped to customers and handed off to clients all the time. Sometimes, you only notice them after your engagement has ended. If you're still working on the project, offer to clean it up as part of a larger group of updates - they can only turn you down. There is rarely a good argument against continuous improvement.

If your project is still underway - just suck it up and admit that a part of your design needs rework! Maybe your team will have a better idea, or maybe they will remember something about the requirements that you've already forgotten. Most people understand that it is hard to self-critique, and I think they'll appreciate you more for your willingness to make a change.

How to keep it from happening

Don't work in a silo! Ask for opinions from other smart people as you're designing, whether they are on your team or not.

For those small late-breaking changes, it's tempting to do something quickly, call it done, and post a file. Instead, make the change and let it rest a few hours. Then you'll be able to review it with a more critical eye.

Optimizing Calls to Action

This morning I was reading a post on the Travel 2.0 Blog that hit home. Troy Thompson wrote:

“Recently, I was asked to critique changes to an advertising campaign from a well-known tourism destination. While the creative was fine…amazingly not touting anything and everything…the call to action seemed, cluttered.

Perhaps that was because it featured not only the traditional website address and phone number, but also icons for Facebook, Twitter, YouTube, a blog (disguised as an RSS icon that few will understand) plus a QR code.”

Seven calls to action in one print piece! Thompson points out that watering down a strong call to action with six “extras” doesn’t provide more choice, it muddies the water for the user and scrambles your metrics.

This lesson isn’t just for print. On websites, there’s a tendency to offer everything to everyone at all times. Take the typical higher education website, for example. There’s usually semi-permanent placement of calls to action for applying, visiting campus and requesting information. There may also be callouts to promote social networks. In some sections (or everywhere), the school wants you to “give now.” The alumni section wants you to update your info or join an online community. And let’s not forget the ubiquitous share buttons, begging you to Like, Tweet or +1 every page you visit.

What action do you want your visitors to take? You can make a case for everything, but like the Travel 2.0 post said, seven calls to action is probably too many. So how do manage your calls to action?

How to Create Focused Calls to Action

It’s simple: let the context and content of the page guide you. Here are three ways to get started.

#1: Target the context for your call to action

In our higher education example, apply, visit and request information callouts should be seen only in prospect sections. Admission tools shouldn’t bubble over into the alumni or current student-focused content. Likewise, you don’t want a prospective student to be asked to donate to your capital campaign. It’s easy to design permanent calls to action that cascade across every single page of your website, but if your calls to action aren’t targeted, they are visual clutter.

#2: Make the connection between information and action

The second trick to focusing your calls to action is to put them close to the body of your content to indicate a relationship between the copy and the action. If a user is on a page describing first-year housing options, a contextual link to schedule a campus visit or view a virtual tour is more in line with what the he or she might want to do next, while also fulfilling your own conversion goals. A “Visit Campus” button designed into the header of your website won’t have the same contextual relevance as a callout nestled in the copy.

#3 Think “Mobile First”

Finally, think about your mobile site. If you had a limited screen size, what calls to action would you devote space to? Which ones would you cut?

Ready to tackle your calls to action? It’ll be worth it for your visitors—and your conversions.

Originally published as Context and Content Are King: 3 Ways to Focus Your Calls to Action over on the Elliance blog. 

Is Your Website Content Accessible and Universally Usable?

We all start our website projects with the best intentions: most of us plan to adhere to Section 508 and W3C Web Content Accessibility Guidelines. We want to support all website visitors, whether they have a disability, are new to the language, new to the web (born daily!), or are merely aging gracefully. And improving accessibility helps everybody’s usability (and often, your site’s SEO)—so, we implement accessibility guidelines.

But what happens to your accessible website after launch?

While accessibility practices built into the website’s foundational code remain relatively evergreen, the new content that you add to your website may not adhere to accessibility best practices. Perhaps content authors forget, lack proper training or oversight, or don’t realize its importance. Either way, a segment of your visitors may suffer because of an inconsistent—and a downright frustrating—website experience.

Good news: most content-related accessibility issues are easily repaired, and once your content team is aware of them, ongoing implementation will become a habit. Your content team should build it into their workflow, because every copywriter would surely prefer handcrafting the accessibility language for their pages, images and videos, rather than leaving it up to a developer or CMS manager to correct later.

Content Accessibility Best Practices

The following are some tips for writing accessible content that helps all users, derived from Section 508 standards, W3C guidelines and plain old good sense.

Copy & Links

  • Write in clear, simple language.

  • Include descriptive page titles and headings.

  • Link text should be meaningful and provide context—no “click here” or “learn more” link text.

  • Don’t link characters that you would not want to hear spoken.

  • Avoid jargon.

  • Write out an acronym or abbreviation for its first occurrence on the page. Consider using the ABBR and ACYRONYM tags to tell screen readers how to pronounce them (M-o-M-A versus moe-mah).

  • Be aware of common misspellings and zero-result queries in your internal site search logs. What can you do to help poor spellers or people searching for unsupported synonyms?

Images, Video & Audio

  • Provide “alt” and/or “longdesc” attributes to describe the content and purpose of images, graphics, video and audio.

  • Closed-caption videos.

  • Transcribe audio.

Tables

  • Use tables for tabular information, not layout.

  • Remember to use the <th> tag to identify column and row headings for tables.

  • Write meaningful content for the “summary” attribute of your table.

resources

Section 508: Web-based intranet and internet information and applications

W3C Web Content Accessibility Standards

Beyond ALT Text: Making the Web Easy to Use for Users With Disabilities

Accessible Design for Users with Disabilities

It’s Time to Embrace Accessibility SEO

This article was originally published on the Ellilance Blog.

Julie Young
Surveys and Interviews: Getting to Know Your Mobile Visitors

Let’s look at how surveys and interviews can help you glean insights about your mobile presence (or lack of) from your site’s visitors.

Why surveys and interviews?

While site analytics gather quantitative behavioral data, online surveys and interviews can also collect more qualitative data, like opinions and self-reported preferences. Though self-reported anecdotes should always be taken with a grain of salt, survey and interview responses can be very helpful for prioritizing ideas, uncovering new insights, and giving a voice to your site’s visitors.

Surveys

Conducting an online survey is a great way to gain insights about your visitors because you can easily collect data and opinions from a large group of people. Surveys can be structured to gather both qualitative and quantitative data. For example, say that you wondered how many of your site visitors were interested in a mobile-optimized experience. You could do a quick pop-up survey on your site to gauge interest. From that, you could say with certainty that a certain percentage of your audience wanted (or didn’t want) a mobile version.

Other insights surveys can provide include:

  • Ranking and prioritizing of features, content and tasks

  • Rating or commenting on ideas and concepts

  • Suggesting ideas or features not captured by the survey choices

  • Self-reported behaviors like how often they use their mobile device to view your site, and where they are when they do (at home, on the go, etc.)

As with any research method, there are drawbacks to surveys. Survey questions are easy to bias with your own leanings, and self-reported behavior is not always actual behavior. Plus, your survey participant may feel like he or she has to be polite or agreeable, even to a survey on a computer. (No joke: researchers at Stanford wrote a book about people being polite to computers.)

Interviews

It’s always great to talk to your site visitors one-on-one or in a focus group because it enables you to prod more deeply into the “why” and “how.” Plus, interviews and focus groups can be conducted face-to-face or over the phone; the only equipment you need is a pen and paper for your notes.

When conducting an interview, you’ll be able to look for detail. Consider asking:

  • When was the last time you visited X site on your mobile device? What were you looking for? Did you find it? How easy or difficult was it?

  • Can you think of any other times you used X site on your smartphone or tablet? Ask questions about the experience.

  • What apps do you use the most? Ask the interviewee to look at her device and list her most used apps. Ask what she likes about them.

  • Start a discussion about how she would like to use X website on her mobile device. If she doesn’t want to use your site on her mobile device, why?

You’ll collect great information and perspectives that can only help you understand who your mobile visitor is, and what their motivations are.

Naturally, there are drawbacks to interviews. The politeness problem crops up again, and so does error-prone self-reported behaviors. You also cannot draw make generalizations about your visitors based on a few interviews because of the low number of participants—interviews are purely qualitative. Aside from these drawbacks, interviews are valuable because they humanize your site visitor. Through conducting a handful of interviews, you’ll be able to draw a picture of your actual visitors in greater detail than by data alone.

If you take the time to learn a little bit more about your mobile visitors, you’ll be able to better understand your customer. With the knowledge gained from easy research techniques like surveys and interviews, you’ll have the basis for a great mobile experience that your visitors actually want to use.

This article was originally published on the Elliance Blog.

Julie Young
Review: Mindfire by Scott Berkun

If you know me (in person), I've probably emailed you some of Scott Berkun's blog posts. He recently published a collection of "best of" essays in book form, Mindfire, which is an outstanding read. 

In one of my all-time favorite essays, "The Cult of Busy," Berkun calls out the "busy" people. First, there are the people who only "look" like they are busy. In the past, I had a coworker like this. Someone who was so stressed at work and couldn't take on a single extra thing---who couldn't even help a peer out of a jam---yet, she aquired an amazing amount of Farmville garden implements from 9 to 5 every day. 

These "fake busy" folks aside, Berkun makes a rather insightful point about the other "busy" people: the people who are overbooked or who are not using their time wisely.

The phrase “I don’t have time for” should never be said. We all get the same amount of time every day. If you can’t do something, it’s not about the quantity of time. It’s really about how important the task is to you.

How true this is! Yes, you may be too busy to help because this matter doesn't require your attention, or because you can't say "yes" to every party invite (you popular gal, you). But Berkun points out that if you are honest with yourself, you are busy because you are either over-involved, or you are failing at effectively doing whatever it is you do.

I suspect this really means that you are so busy being busy (or pretending to be busy) that you end up being the person who isn't asked for help because you aren't that helpful, who isn't as valuable because you don't share, and who can't see the forest for the trees. So, you miss out on great opportunities and quality working relationships...all because you have a priority problem. An effectiveness issue. You also miss out on free time, because you are busy being busy. You work too much. You become sad. But heck, you can prove you worked a lot of hours! But what is that really worth? 

This essay in particular really got me to think about how I respond to other's people requests for my time, and frankly, how I use my time. Do I prove my worth by hours worked, rather than projects accomplished? Maybe. Do I become a martyr for time? How can I fix myself so that I use my time more wisely? All of this out of one short easy-to-read essay! 

So, this is why you should read the whole book, and the whole essay (lucky for you, it's included in the preview!). Don't take my word for it. ;) 

Julie Young
Your first idea is not your best idea

The following scenario happens to me on repeat:

When starting a project, I make a quick sketch, see a “perfect” example, or jot down some idea that I think is just the tops.

I misplace it.

Then I become convinced that it was the key to my genius, and I cannot move forward solidly without it.

Then I find it, and it is complete crap. I’m finally free to move forward toward something smarter.

Does this happen to you?

Obviously a lot of good thinking happens between that first moment of conceptualization and the process of planning a feasible, delightful idea. And not all first ideas are bad ideas. Sometimes they are just raw and require cooking.

But in a way, that bad first idea is good. It’s good because it exposes that there is a problem begging for a solution. It’s a note that there is something there to work with, something to improve.

First ideas can also be very, very dangerous. What happens when bad “first ideas” become idealized rather than rejected? Instead, repeated as mantras? What happens when your internal criticism fails you, or you don’t have someone to help you workshop your ideas? Are these the projects you aren’t proud of? 

content strategyJulie Young
How to design a highly usable form with the help of a good book

One of the most useful books I’ve read in the past few years is Web Form Design by Luke Wroblewski. The reason I like this book so much is simple: when I’m working on a big form project or reviewing someone else’s work, it’s very easy to grab the book and flip through the best practices at the end of each chapter, using it as a rubric, as well as a source of much-needed inspiration. 

Over time, though, I realized that rather than dig out my ebook, I could just create a checklist that I could use to prompt me on some pivotal issues. The actual explanation of what you should do and why, of course, is in Luke W’s book. Which you should buy it. Right now. I’m not kidding. Anyway, his book has examples of high-quality patterns and the research to back to it up so you don’t look foolish when you are questioned about why you are recommending a certain label alignment over another, or why you chose those smart defaults. So, to the checklist…

High-Level Form Organization

Does the form need a start page?

  • The form needs room to explain need, purpose, and incentive, if any.

  • The form requires specific information that should be compiled or found before starting. (Example, tax returns and bank statements)

  • The form requires an investment of time. Warn the user. (Example, long surveys)

Should the form be broken into multiple pages?

  • Does the form contain a lengthy amount of question groups that are relatively independent of each other?

  • Can you ask optional questions after a form is completed?

  • Is the form a good candidate for progress indicators?

Have you considered gradual engagement for sign up and registration?

Questions & Form Inputs

  • Have you grouped questions/fields by types (contact, billing info, etc.)?

  • Have you eliminated unnecessary questions/form fields?

  • Have you clearly identified optional or required fields, using a label for whichever is in the minority?

  • Are labels in natural/plain language and consistently formatted?

  • Can you top align labels? If not, can you right align? If mobile, have you top-aligned labels?

  • Do the field lengths provide meaningful affordances? (Example, a ZIP code field for the U.S. should be 5 characters long, not 27.)

  • Have you set smart defaults?

  • Are there any areas of the form that could be enhanced by hiding irrelevant form controls/using progressive disclosure?

Buttons

  • Are your primary actions, such as save or register buttons, aligned with input fields?

  • Can you remove secondary actions like clear and reset?

  • If you use secondary actions, are they visually distinct from the primary action?

  • Can users undo secondary actions if accidentally clicked?

Help Text, Error Messages, and Success Pages

  • Do you need that help text? Is it clear and concise? Any input limits or restrictions? (Example, password must contain XYZ.)

  • Are error messages clearly communicated by both a top-level message and a contextual message near the affected field?

  • Have you considered in-line validation for questions/fields with high error rates or specific formatting requirements?

  • Have you clearly communicated the successful completion of the form? And it's not a dead end, right? 

Voting usability: my personal experience

Over the years, I've seen news reports about user difficulty with eletronic voting kiosks and read the occasional article about ballot usability. I did not really expect to be the person with the voting problem, but suprisingly, this tech-savvy gal was.

I headed to vote in a hotly contested local primary election. In Allegheny County, we use the ES&S iVotronic (view a big photo here), a rather boxy touchscreen electronic voting machine. (Full disclosure: the past two years, I was traveling over election day and used an absentee ballot. The last time I voted via machine was 2008.)

Here's what happened: 

  1. The voting helper showed me the machine and asked if I used the machine before. I had.
  2. I read the instructions on the screen. 
  3. I started to vote, and easily picked my candidates via the touchscreen. 
  4. I reviewed my choices; it said I could press the vote button.
  5. I couldn't find the vote button. An embarassing red light was going off, totally flashing in my face. 
  6. I looked some more for the button, cycling through screens. I was feeling rather sheepish.
  7. I examined the help sheet taped to the booth, panicked. It indicated a cartoonish big red button. 
  8. I looked for the big red vote button on the screen. Mortification set in. 
  9. I realized that the vote button was a physical button, not a touchscreen button. It was also the very thing that had been obnoxiously blinking all the while. 
  10. I pressed the button and walked away feeling really, really dumb. 

I felt stupid, but it was the UI's fault.

I've seen it plenty of times in user testing: a participant doesn't find what they were looking for or otherwise fails at a task and they say to me rather sheepishly, "oh, I just didn't see it" or "I guess I didn't understand how it works." But, it's not their fault. Most of the time, usability test particpants aren't the dumb ones; rather, they have good reasons for thinking something should work a certain way. When the site/product/device doesn't meet their expectations, rather than recognize the idiocy of the "thing," users self-blame or feel embarassed.     

I am a novice user of electronic voting booths.

At best, most people vote once or twice a year, but many go years between votes, showing up only for presidential elections. Essentially, you have to re-learn how to vote every time. To solve this problem, the voting booth gives a brief on-screen instruction page and the voting attendant asks if you need an overview. The actual process of voting is made to be easy---similar to a wizard interface. To top it off, my voting booth had a sheet of printed instructions, kind of like a post-it note with a password scribbled on it stuck to the monitor of a computer. Every safegaurd was taken, and the machine had help copy out the wazoo. Perhaps they should've done more user testing. 

The touchscreen/button interface is a mixed metaphor. 

My last beef: why on earth would a touchscreen have a physical button? It breaks the convention of the user interface. I went through my entire voting process touching only the screen, checking off names and then clicking the "next" and "review" buttons at the bottom of the screen. When the time came to actually cast my vote, I was not expecting to use a physical button AT THE TOP of the machine---even as it flashed in my face (weirdly, the flashing light made it nearly impossible to read the word "Vote" printed on the button). Maybe the thought was that people would feel more secure casting their vote with a non-digital action, but I suspect the button's top placement and physical nature felt odd to quite a few people in addition to me. 

The good news? At least I (successfully) voted! 

What are wireframes, and why does your website need them?

One of the most misunderstood UX deliverables are website wireframes. Maybe it's because they are lo-fi, or maybe it's because they are sometimes filled with scary decisions, or maybe it's just because some clients want to get to the fun "marketing" part: creative design. I'm not really sure. But, here's how I usually explain wireframes to clients when they encounter them for the first time. 

What are wireframes?

Wireframes are a visual guide to elements on a page. They represent function, content elements and features, and express navigation and wayfinding.

Though wireframes underpin the visual design, they are not one-to-one layouts of the future creative design composition; rather, they serve to influence and guide the design process.

In development and coding, wireframes transition into a functional specification for the build. 

Why does your website project need wireframes?

The short answer: because someone has to plan for what the site is going to do and how it is going to do it, captured in a language that designers and tech folk understand. Wireframes are these blueprints. 

If you've ever envisioned a new website before (or even a part of one), you know that you have a goal or a strategy in mind. Wireframes are the bridge between these strategies and the technology required to implement them successfully for users. 

What do you need to know before you start wireframing?

Basically, it boils down to these things: 

  • Awareness of client's wishes, strategy, objectives or goals. 

  • A content outline, beginnings of a content strategy, audiences identified, analytics, calls to action, success measures, etc. 

  • Understand the PROBLEM. There is always a problem; take it on.

When it's time to start, look at the content outline or sitemap and decide what should be illustrated. Ask yourself:

  • What content templates or page types will the site need?  
  • Are there processes that should be paper-prototyped? Paper prototypes are essentially wireframes that express a workflow. For example, a registration process or shopping cart.  
  • Is there a content management system (CMS)? If so, do you know the CMS's capabilities? If you do, great! Try to work within these capabilities. If not, talk to tech people as you go and prepare to adapt. 

Once you've produced the wireframes, expect tweaks throughout the rest of the project. Though "approved," or even endlessly vetted with coders, developers, designers and the client, nothing is ever final on the web.

An observation on categorizing

There's a bagger at my local market who frequently packs my groceries. He's very organized.

Here's a breakdown of today's purchases to illuminate his orderliness:

3 Fettuccine Alfredo Lean Cuisines
3 Macaroni and Cheese Lean Cuisines
2 pints ice cream (don't judge)

Here's how he packed the items:

1 plastic bag: 3 Fettuccine Alfredo Lean Cuisines
1 plastic bag: 3 Macaroni and Cheese Lean Cuisines
1 plastic bag: 2 pints ice cream

Then he packed the three bags into a brown paper bag, and then the paper bag went into another plastic bag for a grand total of five bags for 8 items, but only one bag to carry.

Now, I suspect that the bagger in question has a compulsion or something else going on. But, that's beside the point. The lesson in this story is for information architects, and that lesson is twofold.

1: How you categorize or group items may not match how the user would group items. If I were packing my bags, I'd put it all in one or two plastic bags, jumbled together.

2. You could be going overboard, categorizing and consolidating for the sake of imposing order, rather than usefulness, resulting in an unnatural effect for the user. 5 bags! 8 items! Enough said!

Now, back to that ice cream...

How to write a web content outline in 6 steps

Since January, I've been on a content outline streak. Two large higher ed sites and a smaller policy site are in the can, and now I'm moving on to another higher ed site. So, I thought I'd share a little bit about this deliverable.


 

What is a content outline?

Where I work, content outlines are the primary information architecture deliverable for the new or redesigned site. It's in outline format (0.0 Home, 1.0, 1.1, 1.1.1, 2.0, 2.1, etc.), and it becomes the supporting structure for the sitemap (the familiar boxes-and-lines rendering of an outline). Here, the information architect or copywriter combs through the existing source material, and working from the site's new strategy and goals, forms the written outline of pages.  


 

Why do you need a content outline for your website? 

The content outline is basically the Bible for the new, revised and old content on your site. Copywriters or editors will use the outline for guidance when revising and writing the new website. Generally, the content outline will capture at least the first three or four levels of the website's navigation, so that the project team can see where and how the majority of the site's content fits into the new structure. The goal is to have an intuitive home for all the content that has to be on the site.   


 

Where does it fit in the process? 

To put the website content outline in context, here's when it happens. 

  • Goals and strategy for the site have been identified, and any primary user research needed to inform the content architecture has taken place. 

  • An inventory of all the existing website content has been done. (To be honest, I think this step is wholly skippable.)

  • Content outline time! 

  • Sitemap

  • Wireframes 

  • Design, development, coding, testing, qa, etc.

Really, though, a content outline should be done any time you want to rework your site's content (or even a small section of content), independent of design or coding. It's a content thing. 


 

How do you write a content outline? 

So, you know whatever it is that you need to know about the strategy or goals of the site. Maybe you're just working on fixing a section of a site, and you know that you just need to repair the awful mess. That's a valuable goal. Or maybe you need to especially target an audience, or seek conversions, etc. Whatever it is, you're aware of it, and thus, you can begin. 

 

Step 1: Immerse yourself in source material. 

For sites with hundreds of pages, it's okay to spend a couple of days reading the site, particularly if you are unfamiliar with the project or the client. I find that coming into some sites is totally disorienting, like a bomb has gone off. As you click through the website, you'll notice wacky navigation schemes, hidden pockets of pages, wildly outdated pages and utterly confusing or contradictory text. This is totally overwhelming. 

After hours of reading and poking around, you'll strangely begin to know where everything is and what exactly it is that you are working with.

At this point, any print materials you can get your hands on can be helpful. People seem to invest more time and money organizing and writing quality published material than they do for their web copy.

 

Step 2: Draft the top level navigation. 

Once you've grown to understand the beast that is your project, jot down the main navigation labels--the big buckets. I'll use higher ed--let's say generic undergrad liberal arts college--as an example, since that's been on my brain lately. 

0.0 Home

1.0 Admissions

2.0 Academics

3.0 Campus Life 

4.0 Paying for College

5.0 Athletics

6.0 Alumni

7.0 Parents & Families 

8.0 Giving

9.0 Intranet

(various footer links) 

Group them into sets if need be. Move things around. Give them new labels. Sketch out the homepage. Once you feel comfortable starting with what you have, move on. 

 

Step 3: Fill it in with the ideal. 

What I like to do next is fill out the next level from memory. So, I might say for 1.0 Admissions, I want a page for a checklist, a page for requirements, class profile, request information form, dates and deadlines, open houses/tours, etc. I do this rough sketch for every section, thinking more about the goals than the content that exists right now. 

 

Step 4: Add in the reality. 

Next, I start to pick through the source material and fill in the blanks. I make notes in the outline for combined pages, new copy, or stuff that is pretty good as-is. I write in ideas for the wireframes, if I have any, like "consider adding an event feed from the calendar." I note when I see a form, or when a new form is needed. I write basic descriptions for the page and suggestions for callouts.

By now, I've touched every page on the site several times, and I've officially become some kind of expert. 

 

Step 5: Add some notes about your vision.

Corny as it seems, it helps to write an introduction to the outline where you clearly state what your guiding idea or plan was and highlight the major technique(s) you used to accomplish it.  This is not about teaching best practices for writing for the web, but should be your rationale or approach. Include any major issues that you've identified and hope to address. 

 

Step 6: Make a sitemap (if you need one), test it if you can, then relax.

You are now a subject matter expert! 


 

In a nutshell

A quality content outline expresses the vision for the new website. It sets expectations for how many pages and how much work is ahead. It's also the fundamental building block of a site...you've set the navigation and the IA, now writers can begin working on the content. You'll also have the exact navigation items needed for the design. From here, projects big or small, are off to a solid start. 

Information scent and my search for spices

Here's a true story that serves as a metaphor for why your website needs good navigation and information scent. 

This weekend I conducted a search for chaat masala. I had a Mark Bittman recipe variation for dal, and figured I could just get it at my local super-sized grocery store. This store is, in fact, the largest grocery store in southwest PA, and I had gotten garam masala at smaller stores before. I checked all the obvious places: International, spices, where they keep boxed dinners, to no avail. 

Since I live in an area with a significant Indian population (for Pittsburgh), I am rather close to two Indian groceries, and I knew they would carry my spice. 

Grocery K

I walk in, and it's dark. The store is crowded with products, and things are everywhere. To me, it seemed like the organizational principle of the place was "put the product wherever there is room."    

Grocery M

I walk in, and it's brightly lit. The store makes sense instantly. Dry staples like beans, dal and rice are along one wall. Across from the rice and beans, rows upon rows of spices, herbs, tamarind, sesame seeds... Another aisle has boxed dinners, another for frozens, prepared foods, and even mark-down section. Candy is in front of the register. 

Why I chose Grocery M

Grocery M is familiar. Sure, the other shoppers were speaking in another language, and my knowledge of what I was looking for was slim (spice blend?). But, it was organized. A glance at the store's shelves told me what was in each section, and I found the spices in seconds. Once I found the spices, it took a little while to find my specific spice, but after I briefly browsed the shelves, there it was. 

Organize your content like store M, not store K.  

  • Make sure your store is clean and brightly lit. Can someone glance at your website and get the gist of its contents? Or is it cluttered with distractions?  

  • Are your aisles organized? Your content organization and navigation structure should make sense and feel natural. 

  • Can a new shopper transfer knowledge? I had keywords, nothing more. But based on my experiences at other stores, I had a general idea where to look. I had a mental model. 

  • Did the customer convert? Ultimately, I found what I was looking for at store M. Store K? Honestly, I bailed. I knew there were other stores in town, and I didn't want to waste my time. Ask your users and check your stats: are users fleeing your content because they can't find what they are looking for, or did they successfully complete their task? 

Interviewing: One Question at a Time

In my working life, I've attended tons of discovery sessions, conducted informational interviews and usability tests, listened to vendor demos and been in too many meetings to count. The thing that gets me the most are the questions. 

You have questions! This is good. What is not good is asking more than one at a time. You know the type. Those massive questions that stretch on and on, asking for 3 or 4 things, that include various other points as you go along. By the time the questioner has stopped talking, the answerer: 

  1. Doesn't remember any of what was asked.
  2. Only remembers the last question, or the first, or whichever one they managed to cull from the oratory.
  3. Only chooses to answer the easiest question.
  4. Ends up answering none satisfactory. 

 I remember being in journalism classes back in the day, when the rule was "if you want an answer, ask one direct question at a time." And to make it more fun, the question couldn't be answered with "yes" or "no." 

When you're conducting user research, or even trying to get to the bottom of an issue in a meeting, just ask one question at a time! And just ask the question: don't add fluffery, don't hedge and don't include your reasons for asking. You have a right to the answer to your question, so make your question easier to answer.

By the way, after you ask your question don't jump in to fill the uncomfortable silence (if any). The person is probably thinking. Thinking can cause answers.