On UI Walkthroughs

UX Walkthrough

The UX kerfuffle du jour surrounds the alleged evil of UX walkthroughs…you know, those screens that come up when you first launch an app, showing you where to poke, pull, pinch, and tap. The gist of the complaints, summarized pretty well here, is that the very need for a UX walkthrough implies the interface itself has failed to provide enough clues and cues about its utility. Put another way, UX walkthroughs are kind of like helping someone get around a darkened room after you’ve intentionally turned off the lights.

I’ve seen examples of UX walkthroughs that were either gratuitous and unnecessary, or were implemented because the UI lacked adequate affordance. That said, I’ve seen UX Walkthroughs that are very helpful. Case in point: the Feedly app recently introduced a new way to mark an article as read by swiping from right to left (previously, it was a downward swipe). It’s a great trick, but one I would not have learned easily had there not been a walkthrough tip when I launched the app after an update . Likewise, the insanely cool Rise app provides a simple UX walkthrough that expedites one’s ability to get going. In both cases, the walkthrough simply sped up my ability to be productive and engaged.

The argument that all UX walkthroughs are evil is silly. Some tools tell you how they are to be used just by their very form…a hammer, for example. Others, like a carpenter’s plane, perform a more sophisticated function and therefore have a more sophisticated form factor. Wouldn’t it be nice if they explained themselves before use? Think of it this way: if you’ve designed a hammer that requires instruction, you’ve probably failed. A plane? Not so much.

As I’ve said before, and will likely to continue to say, in UX there simply are very few hard and fast rules. Whatever works, works.

//

Let me know what you think on Twitter: @mmcwatters

Sudoku Snapshot

User Testing on the Subway

On the subway this morning, I spied a passenger playing a sudoku app on his iPhone. At the risk of disturbing him (and winding up with a broken nose), I said, “Pardon me, but I see you’re playing a sudoku app. Would you mind looking at one I’m developing for the iPad?”

“Sure!” he said. I fired up Think-Sudoku, and handed him my iPad. I showed him that, unlike other sudoku apps, mine had a unique way of entering numbers. I also explained that, unlike most other apps, mine would have an unlimited number of games.

He was excited, and asked when he could buy it. I’ll take that as a good sign. I asked how much he would pay. “I don’t know…two or three dollars?” This confirms the price point I had in my head.

There’s nothing like a little user testing. Even on the subway.

overeasy

Easy and Hard

Recently I was asked why I suggested a Cancel button be moved to the right of a Delete button in a dialogue box. The confusion was understandable: in this particular UX, the paradigm had been established that termination actions were on the left, whereas continuation actions were on the right. My response was that, since this was the last chance the user would have before losing their data, they should have to look just a little harder before selecting Delete.

This reminded me of a good UX maxim: make it as easy as possible for people to do that which they want to do, and harder for them to do that which they might not want to do.

Make it Easy

If users want to enroll, subscribe, purchase, read, save, whatever…make it as easy as possible. Remove all roadblocks. Get out of their way!

Make it Hard

If a user might do something they don’t really want to do, make it hard. (Or, make it less than easy.) For example, while one warning might suffice when deleting a file, perhaps two warnings need to appear before wiping a hard drive.

As UX professionals, we trumpet the art of making things easy, but we also need to remember that sometimes, in some cases, it’s better to make things just a little bit more difficult.

System Messages Matter

Today I was the first person at work, and upon entering the office I heard the warning beep of our burglar alarm. I panicked for a moment, and then mentally scrambled to remember the code to disarm the system.

Not ready to arm

When I entered what I believed to be the correct code, the system presented me with the message “Not ready to arm.” My nerves were on edge, as I knew that if I’d entered the code incorrectly the alarm would go quiet (as it had) and the police would be arriving at any moment.

Unfortuantely, the alarm system offered little solace. “Not ready to arm.” What does this mean? If I’d entered the correct deactivation code, shouldn’t it say “Alarm deactivated”? At the very least, wouldn’t the proper message be “Ready to arm,” reflecting the state of an alarm that was not presently armed?

I’m sure in the alarm system’s functional requirements, the phrase “Not ready to arm” makes sense to someone somewhere. But to me, the groggy morning user, it made absolutely no sense. I decided not to fuss with it any longer; if the police showed up, I’d plead ignorance.

But I was reminded, yet again, how important it is to write alerts, messages, warnings, tips and cues that are concise, telegraphic, and accurate. Most importantly, they should be contextual and attempt to anticipate and answer the most pressing user question at that particular point in whatever process is taking place.

Vagueness and ambiguity — great when you’re writing the screenplay for an indie film — don’t help the user in the least.

PS Apparently “Not ready to arm” does in fact mean that the code I entered was correct. I will remain out of jail for another day. Go figure.

Follow the User

Users choose their own path

Are you trying to dictate the path your users will take through your experiences? If so, you might be making the same mistake as the urban planner who designed the right-angle-only pathway in the photo above.

As the image shows, people have decided — quite correctly — that they can get from A to B much more quickly by cutting across the grass and, in doing so, creating quite a dirty mess.

While it’s easy to label these grass tramplers as scofflaws, the truth is they are just normal human beings doing what human beings have always done: finding the quickest, easiest way through any given situation.

So, if you’re going to try to dictate a path for your users, you better be absolutely certain (with a lot of user testing) that it’s a path that makes sense for them. If you can’t do testing, then you better offer options and escape routes.

If you don’t, expect your grass to get trampled.

dining.png

A Better Restaurant Website

If you own a restaurant, chances are your website is frustrating the customers who visit it. Restaurant websites on the whole are so bad that it’s actually become a bit of a joke in the user experience community (you know, those of us who design and build websites for a living). In fact, Matthew Inman over at The Oatmeal has done a pretty bang-up job describing what he (and most people) really want (and don’t want) from a restaurant website.

Sure, it’s easy to point out the flaws, but I think it’s important to figure out why these sites are failing, and what we can do to fix them. Aside: I think the notes below apply to almost any industry, but I’ve isolated restaurant websites because they tend to be so bad.

Hire professionals

Restaurants have limited budgets, so they’re more likely to try to get their sites on the cheap. This isn’t to say that an inexpensive website is going to be a bad website, but it does increase the odds that you’re dealing with novice user experience professionals.

Your website shouldn’t be an afterthought. It’s a critical part of the experience you’re providing your customers and, because it’s often the first point of contact, it better be good. If you can, think of your website just like any other fixture in your business, and try not to skimp.

One thing you can do is find restaurants in your area that have good websites (based on the concepts I outline below) and ask the owners who did their site; sometimes the sites even have links to the web design agency. Alternatively, you can look up good but small local user experience and design firms; often they’ll take on a smaller project if it interests them, and restaurant websites can be great portfolio pieces.

Skip the ambiance

Restaurant owners (and their designers) often hope to re-create the dining experience on the website. They use Flash which requires a third-party plugin, isn’t great for mobile devices, reduces search engine optimization, and makes it harder for users to print out key information like directions or menus. They add music or other distractions that slow the website down and create a fussy, intrusive experience. They provide menus in PDF format, which takes longer to load and isn’t as easy to review in a Web browser. In short, they put form ahead of function, decoration ahead of useful information.

Believe it or not, your customers aren’t as interested in ambiance as you might think they are. They want basic information like location, hours of operation, contact information, and menus. Sure, your site should be attractive and match your brand; it should support the final experience you want your diners to have. But it’s important to remember that when people visit your website, they’re not actually in your establishment. They’re at work, at home, or on the go. Your website needs to work in those venues, not the other way around.

Preview the experience

Okay, so this might sound a little contradictory to the point I was making above, but bear with me: people visiting your website do want to know what your restaurant is like. They want to get a feel for the place, they want to know if it’s what they imagine for their date, or if it will work for their kids. In other words, they want to get a sense of the place.

One of the best ways to do this is through photography. But instead of creating giant Flash slideshows that clog the browser and slow the experience, provide a gallery that’s easy to find, with useful captions and a logical structure. And, hire a professional photographer (see my point above about hiring professionals). You might think you’re pretty handy with your iPhone camera, but a professional photographer is light years ahead of you; they will know how to shoot your space so the images are meaningful and inspiring to your customers.

Go mobile

People often make dining decisions on the fly, so it’s not surprising they’re going to be visiting your site on a mobile device. Nonethelss, very few restaurant websites are designed to work well on mobile devices. Instead of getting a simple site that loads quickly and gets them the information they need, users are presented with scrunched up websites broken up over several pages or, worse, a broken Flash plugin symbol.

But you have options: you can provide a website that degrades gracefully from its full glory on a desktop PC to a much simpler, more streamlined version on a mobile device, or you can simply provide two websites — one for desktop users and one for mobile visitors — and rely on technology that serves the appopriate website to your customers depending on what kind of device they’re using.

In either case, it’s important to remember that mobile users probably want information prioritized differently than desktop users. Whereas a desktop user might expect a more traditional experience with a home page and sub pages, mobile users might appreciate a one-page design that presents location and contact information first.

Taste before serving

Every decent chef knows you don’t send food out to your diners without doing a taste test first, and that you modify your recipes over time to suit the changing tastes of your customers. The same is true of your website: launch your site and get feedback from customers about what works and what doesn’t, then make adjustments. Over time, plan on updating, improving, and possibly redoing the site entirely. If you want your restaurant to stay fresh and current, your website needs to come along for the ride.

Check, please!

Restauranteurs are often entrepreneurs taking big risks; adding a website into the business plan can result in unwanted stress and anxiety. Nonetheless just as the best recipes are often the simplest recipes, made from basic wholesome ingredients, I believe the same is true of websites. If you’re worried about doing it right, just keep it simple: focus on the information that matters most, present it in a way that’s easy to understand, and don’t get hung up on adding seasoning that will just muddy the taste.

step

The Extra Step

Remove that extra step. Look for it…find the thing that isn’t necessary…and kill it. If you find more than one, kill ‘em all.

Maybe it’s an extra click. Maybe it’s a bit of copy that needs to be read because a UI element isn’t self-explanatory. Maybe you’re loading a new page when you could have used dynamic elements. Or maybe you’re just missing a quicker way to get your user from A to B.

Whatever the case, people want to move. They long to be free, and you’re their shepherd. Look at your UX and ask yourself, “Is there an extra step I can remove?” I’ll bet there is. Now go kill it.

Screenshots of the weather app Shine.

Dummy Data: Don’t Do It

On the left is the dummy data Shine shows you until the actual data (middle) loads. On the right is a proposed solution.[/caption]

I recently argued that, at times, it’s acceptable to use properly crafted dummy text (aka greek copy, or lorem ipsum) in your designs. However, it’s almost never a good idea to use dummy copy in your actual working site or app.

Take the excellent iPhone weather app Shine for example: upon launch, it takes a few moments for the actual weather data to load. Instead of showing a loading screen, however, Shine shows you dummy data. Many times I’ve launched Shine and thought, “72 and sunny? Sweet!” only to be disappointed when I discovered it was 92 and raining, or 58 and cloudy. Apple’s own iPhone weather app actually shows dashes instead of faux data.

In apps or websites where data is truly critical, it’s even more essential that you not employ dummy data. Imagine if your banking website showed phony balance numbers instead of your actual statement info, or if a thermometer showed you a 98.6 reading for several seconds until the actual temperature was available.

Note: I don’t mean to pick on Shine. It’s one of my most-used apps, so its use of dummy data frequently throws me for a loop.

Fix The Product!

I’m working on yet another project where the hope is that UX and UI will make a suite of incredibly abstruse products comprehensible for the user. I have no doubt we’ll end up improving comprehension of the product lineup through a better, more intuitive user experience. And yet I’m also certain that the client, like many others, should simply fix their product lineup so it’s not so confounding.

Free Wireframe Sketch Template

It all begins with a sketch.

If you’re like me, you usually start your prototypes or wireframes on paper. However, it can be hassle to sketch out all the browser elements and grid anew for every page in a project. That’s why I created the 970 pixel wireframe sketch template that you can download (PDF) and use for your own work.

The grid is set to mimic 970 pixels, with 12 columns of 68 pixels width each, with a 14 pixel gutter between them. There are also 14 pixel gutters on the left and right sides, so the true width of the page would be 998 pixels if you wanted that padding.

As I’ve recently discovered, the 970 pixel grid is, in many ways, more accommodating than the popular 960 pixel grid.

In case you missed it, here is the template again: download.

970 Grid PSD

The 970 pixel grid.

I’ve been using the 970 pixel grid for a little while now, and I agree with those who argue it has many advantages over the traditional 960 pixel grid. For more information, read this article. To download a layered Photoshop file with grid and measurements that I developed, click here.

A great 404 page should give you options.

404 Greatness

A 404 Error page shouldn’t just let you know something’s gone wrong; it should let you know what your options are as well. This one, from Konigi.com, is quite good.

I'm lost, but not irreparably so.

fireworks

Fireframes

Over the years, I’ve used many apps for wireframing, from Mockflow to Mockingbird, Dreamweaver to Flairbuilder, Protoshare to Balsamiq, Omnigraffle to Indesign and Illustrator. And, of course, everything still begins (and sometimes ends) on paper. But I’ve yet to give Fireworks a whirl, despite the fact that some UX people rave about its strengths as a wireframing and prototyping tool.

So last night I began developing some wires using Fireworks, and thus far I’m pretty impressed. I can export the wireframes as clickable PDFs or as PNGs with HTML hot spots, or as sliced HTML files with rich interactivity, making them easy to share with clients and colleagues.

A wireframe done in Fireworks.

Supposedly I will be able to bring them directly into Photoshop for UI design when they’re complete. All wireframe pages are stored in one Fireworks file (Fireworks uses a flavor of PNG that permits multiple layers and states, as well as vector shapes, symbols, and interactivity). I can use standard Adobe keyboard shortcuts. And, I can work the way I’m used to working: like a designer, not a programmer.

The biggest challenge so far hasn’t been learning Fireworks, but forgetting Photoshop: both apps are very similar in terms of form and function, yet they are different in subtle but critical ways. I seem to keep trying to do things the Photoshop way, and it doesn’t always work. Nonetheless, it’s a familiar environment, and that’s pretty helpful.

Some of my friends have said they don’t understand why I try to so many apps when there’s probably one that works better than others (and they each have their own preferences, of course). In my case, however, either I haven’t found the perfect tool or, more likely, in my opinion, each project requires a different tool.

In any event, I’m going to try to slug it out with Fireworks on this project, and I’ll report my progress when I’m done.

Update: Well, that was fast. After one day of use, I can state without equivocation that I won’t be trying to tackle this project using Fireworks. I wrestled for a couple of hours with the States / Layers / Pages confusion. Adobe’s help application was confusing, verbose, and incomplete. I’m sorry to report that Fireworks won’t be at the top of my tools of choice for wireframing, as I believe a great tool should be fairly self-explanatory, especially when it comes to basic tasks like exporting pages and states.

Content Strategy

Here is a simple diagram that should help you get started with your content strategy.

Does this seem overly simplistic? Ask yourself what the alternative would be.

A happy cart is a better cart.

A Better Cart

The e-commerce checkout process can be frustrating and confusing: it’s not always clear where you are in the process, how to go back and make a correction, or how much further you’ve go to go until you’re done.

Fortunately, a relatively new type of checkout is starting to appear around the Web. It takes the form of an accordion, and it presents all of the steps of the checkout process in one layout, not spread across multiple pages.

The accordion shopping cart at lomography.com provides numbers to orient you.

Essentially, all form elements are contained in a single page, with non-active steps collapsed, and active steps open. On some sites that employ the accordion checkout, you can actually go backward or forward though the checkout process by clicking on alternate accordion layers. Other sites even allow you to edit information on non-contiguous form elements. And all of this happens without having to wait for any new pages to load.

The Land of Nod accordion shopping cart.

Having visited a few sites that employ the accordion checkout, I can safely report that the process feels more streamlined and pain-free, even though all of the steps you’d find in any other checkout process are still there.

Presentation, as we know, can be everything.