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! 

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.

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

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. 

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? 

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. 

Update on 2011-01-19 02:49 by JMY

UX Matters just published a quality article about developing your interviewing skills. Great refresher!