All posts tagged as "Design Tips"

The other day the team here at Little Springs working on [the other big project] were talking about one of their next phase deliverables, a help system. So I jumped in and intruded with all my ideas. Open plan offices are great for this.

Especially in my time at Sprint, building large scale account management systems, I've run through a lot of serious help systems, that had to meet specific financial and satisfaction goals. So, I've not just designed a lot of help stuff, but had some user research, and metrics on effectiveness. I am therefore pretty confident these methods all work. It should also be mentioned that this is not mobile-specific. That's a subset which I haven't worked out quite as well, but will try to someday. This is more like application and web systems help.

And after I gathered all my best practices to present to them, it occurred to us that these seem to be published nowhere else.

My guiding principles are that most help systems suffer from two distinct problems:

1. That you need help at all.
2. Internal organization and jargon.

Solving these will guide you to the right design.

Problem: That you need help at all

What I mean here is that customers don't want help. They usually don't want to pay bills, or change their settings. In their heart of hearts, they just want everything to work, seamlessly. When it doesn't that's a problem, and help gets called on in these dark times to get them out of it.

To solve for this fundamental problem:

• Design as though you have no help system — I almost never design a help tab or little question-mark icons into my basic system designs. Any user going to help is a failure of the design, so work to avoid that with other design principles. Don't throw errors. Make everything clear. Set expectations, and follow them up.
• Pre-empt help questions — When you come across a problem, very often you can solve it by sticking the "help" content on the page. Whether it's explanatory intro text, hint text below the form fields, or a balloon that pops up when you fill in that field wrong, you can tell the user how to avoid errors, or that something is wrong before it's a serious problem.
• Simplify errors — Though back to system design, this is the sort of thing that often tends to come up only when detailed help documentation is being created. One example serves to illustrate this best: A web-initiated SMS sender I designed once, which attached to a number of different back end systems. Any number of them could fail, in a number of ways. Development had cut down the 80-some errors to 15. But the user can't fix them and they all meant "something is wrong, try again" or "something is very wrong, try again later." So we cut down to two messages, with basically that text. If you have more than a handful of error messages, something is certainly wrong.
• Place help content contextually — "Help" does not have to mean a pre-packaged, self-contained knowledge base. Often, it should not be. I covered this some in the pre-emptive stuff above, but the principles apply more universally. If the user calls for help, it can appear on the page. When browsing help, make sure it's a new window, and you can regain focus on the application (or browser window) so the customer can follow along with your recommendations. Make sure interactive help is at least no worse than a book open on their desk.
• Contextually link to and within help — Launching help should pretty much never just open a help home page. Take the user to the help topic, or section, for their current location in the system. Sure, there will be a search, and other navigational elements to help them move around, but most of the time help is related to the location from which it was launched.

Problem: Internal organization, and jargon

All too often I encounter, or have to build, systems that are communicated in the way the company works, instead of the way the user perceives things.

• No FAQs — We've all seen it: the "Frequently Asked Questions" section of a brand new website. Frequently asked by who? And it's true, that almost all of these are just what some marketing team or other has dreamed up. Users see through this. They are as cynical about FAQs as you can imagine, and disregard them whenever they can find a better solution. Not that the concept is bad. If you can actually talk to the customer service arm of the company, and get the top 100 call reasons, go right ahead and narrow them down to the top 10-20 basic problems. Be sure to highlight them somehow (whether inline or as a topic area on the help landing page). But don't call them FAQs if you want any users to read them.
• Gather and organize information carefully — The best way I have found, on anything like a reasonable budget, to get help topics written is as follows: Get "help topic writing" to be a task on each developer's checklist. Right after successful unit testing, he has to write up the topic. These all get gathered up, and the product manager (or account manager, or development manager, depends on the dev team) reviews them to make sure nothing is totally unexpected. They can also turn impossible jargon into something useful, or reject them as too dense and ask for rewrites. Then the UX team organizes them in a sensible manner (see next bullet) and gives the final result (with reference back to the original topics) to the tech writer to clean up. With more time or money, you bring the writer in earlier and earlier. To the UX meeting, to review, even to interview the developers directly about what they wrote.
• Organize help like the application, site or service — Assuming that you have managed to build your product correctly, do not then fall back on the way the business is run for your help system. In fact, once you have all the help topics in hand, laying the product information architecture on top of them is often a good organizing principle for the topics. Sub-organize and cross-link all you want, but make the topics reflect the product. This also helps when you want to link to the help system from any location; there's a heirarchically-relevant location in the help architecture to send them to.
• Use common terms, not jargon and brand terms — Unless of course, your product is full of jargon and brand terms. And even then, also use the more common terminology along with it "Super FrogConnect, high speed 802.11g WiFi, can be configured..." Be sure to use several levels of terminology, to appeal to experienced and novice users, as well as tying it to the product.
• Teach the users, using good educational practices — I am not an instructional designer, but I know some. All I remember is that I have encountered normal distributions with visual learners on one end, and textual on the other; and on one help system I included diagrams of the new account management structure. Which worked great. And is especially important if something about your system is new, or breaks previously-established expectations. Be sure to hire a good writer, at least, and someone like an instructional designer if you can. They'll tell you more about this.
• Don't make users classify themselves — In theory, knowing the knowledge level, or intended use of the customer is a great thing. You can give them the correct experience, or here the correct sort of help language. In practice, this is a total non-starter. Even when people can classify themselves in useful ways (which is rare) they usually resent it. You don't need more ways to annoy customers, so just present the information and take your best guess as to how to communicate to them.

Be trustworthy

There's a sort of third principle that emerges when you look closely at these, and that's Trust. Sure, it's a common principle of all interactive design, but as I explain in my book on design process it's good to identify which of these principles are most important to the targeted users of your particular product.

Certainly, help systems need to be easy to use, transparent, preserve user data, identify them personally and so on. But trust is the biggest problem. Customers seeking help are (almost always) having a problem. You are already in a hole, and any friction is going to add to the frustration.

Aside from informing the rest of the design, this leads to one last best practice:

• Let your customers call you

This is rejected a lot by folks looking to cut Customer Care costs. Phone calls cost money, so anything to redirect them is good. But it's one of those where the conventional wisdom is wrong.

I'm not saying calls don't cost money. But customers already on the website are (generally) trying self-care anyway. They want to solve the problem themselves. Putting the phone number at the bottom of every screen doesn't drive more calls, it gives customers the confidence that they can try to solve the problem themselves. If they can't figure it out, they know there's someone to help them. Call rates often go down the more you add the number to the website.

This is not a theory. Several times I have seen this borne out by data, and I've heard the same from others, in all sorts of industries.

So, in summary, my best practices for interactive help are:

1. Design as though you have no help system
2. Pre-empt help questions
3. Simplify errors
4. Place help content contextually
5. Contextually link to and within help
6. No FAQs
7. Gather and organize information carefully
8. Organize help like the application, site or service
9. Use common terms, not jargon and brand terms
10. Teach the users, using good educational practices
11. Don't make users classify themselves
12. Let your customers call you

Lots of “speed” tips are focused on content providers. Plenty of information available. Here’s a starting point.

In general, tips for speeding up a web site will help for at least some devices, but there are some extra niceties for mobile optimization.

Start with the giants: check out

• Yahoo: Best Practices for Speeding Up Your Website
• Google: Let’s make the web faster.
• Google: article focusing exclusively on mobile

Some specific tips:

• Each fetch request adds to latency, even more than most desktop users’ requests. Collect images into a single file.
• Design and develop as if all users were using satellite connections.
• Whenever you see a desktop maximum size recommendation, guess that you should multiply the number by 10%.
• Understand “make sure your size is no larger than 25k because that’s what the iPhone can support” type advice is not helpful for anything other than the iPhone. And 25k will take a while to download even on an iPhone.
• HTML 5, while not yet a standard, is becoming available for high-end mobile browsers. Local data cache can really speed things up.
• Design efficiently. Do you really need the JQuery library? It’s nice, but it’s big. Could you get away with a smaller framework?
• Use progressive enhancement. Design a great experience for less capable devices, and enhance it for more capable.
• Don’t get carried away with progressive enhancement: don’t send down code that a device doesn’t need.

Speed and effectiveness

Speed is not just about speed; we have to consider perception of speed. We talked about that quite a bit in part 1 of the series.

Good design is about more than just speed; sometimes slower speed can result in faster perceived speed and higher satisfaction. If a user is having fun or is easily achieving her goals, she will perceive the site (or application) as being faster.

And not all speed is the same. In general, interfaces that mimic physics, such as the buttons, sliders, and scrolling in most touch interfaces, must respond immediately. The illusion of physics must not be broken. But the parts of the experience that do not mimic physics, such as following a link, can have a delay.

So the design team must design well (there are lots of tips over at Design For Mobile), and must help the entire team decide when to break the speed optimization discussed above. For example, delivering larger image sizes than strictly necessary can enhance the experience. Using the occasional gradient can enhance the experience.

It’s a balancing act.

I regularly encounter people, or posts, that refer to all criticism as bad. That it stifles creativity, especially for us sensitive artsy designer types.

I could hardly disagree more. Criticism is a key part of discovering new ideas and working collaboratively. I am not brilliant enough to get by without help from others.

This opinion comes partly from my art school experience of all things. In general, I think art school was the best education I could have gotten. Not for the art per se, but for the criticism parts. After the first few years, getting the basics of the craft down, I had to (regularly, more than once a week) present my work, ask for opinions, accept them and act on it for the next review.

This taught me presentation skills, public speaking and an ability to think critically and rationally (not just emotionally) about my work, others’ work and what others have to say about mine. Yes, rationality, logic and business-like skills from art school.

Design criticism (and especially interaction design criticism) is a bit different, in that there are absolute truths and needs underlying everything. Art (at least the way I practice it) allows for individual interpretations. If your experience means you see something differently than I do, that’s usually fine.

For design, as a general rule, it is important that everyone understand the functions and the intent of the communications in the same manner. Individual interpretations that vary from the designer’s intent are generally a bad thing.

Design criticism is much like the peer review process. While scientifically-backed (theoretically, everything is confirmed by existing best practices or user research) there is additional help in having others… actually, Wikipedia has a great summary of this:

It is difficult for authors and researchers, whether individually or in a team, to spot every mistake or flaw in a complicated piece of work. This is not necessarily a reflection on those concerned, but because with a new and perhaps eclectic subject, an opportunity for improvement may be more obvious to someone with special expertise or who simply looks at it with a fresh eye. Therefore, showing work to others increases the probability that weaknesses will be identified and improved.

Even the simplest system I have worked on in the past decade is so complex I can’t hold the design in my head (and I am pretty good at this). The genius designer only goes so far, which is why my design documentation was created, and why I make myself stick to it.

Another way to think about this is in this posting about reviewing for journals:

In the early years, critique is about identifying holes and mistakes that make ideas less plausible. In the later years, critique is about identifying the germs of ideas worth development despite the current holes and mistakes.

In this sense, the value of critique is not unlike that of the concept reviews and brainstorming your may have done with the designers when they first came onto the project. Your critique (assuming the schedule allows for it) is not just to tweak the design, but to discover whether there is something totally brilliant or totally different hiding somewhere in there.

Design presentations to clients, and the critiques that inevitably follow, are all too often avoided, or are held with everyone defensively braced. Ideally, I have almost no big formal critiques, and share regularly. This doesn’t always happen though (scheduling, remote work, etc.) so the big review is still a part of my life.

I like to plan for them, and specifically ask for input from clients and others. I like to know my limits, and if something cannot or should not be determined by me or my team (e.g. there’s a good creative team at the client) I’ll leave that for them. And I prepare by putting together a good presentation, knowing the topic as well as possible, having answers or options for any decision that might need to be defended and bringing along any other designers who might know certain parts of the system better.

More often than not, clients reviewing design either focus on the wrong thing (the colors!) or seem overwhelmed by the massiveness of the whole project, and just sit back and let it wash over them. As much as it’s easy for me to not have to defend or revise anything, I like feedback, and need it to make sure the best product is going out the door.

As a reviewer, and especially as a client reviewing design you have paid for, here’s my ten tips for participating in a design review.

1. Look at the product. Review it as the designers wish you to. Feel free to take notes, but let the review be completed (whether a self-directed website walk through, or a presentation) before offering any feedback. Whether it’s a complex product, or your needs mean the presentation is out of first-time-user order, or the designer is just not that good as public speaking, you often will need to see the whole thing before you understand it fully.
2. Encourage everyone else to do the same. That is, take notes and wait till the review is over. Short circuiting this in meetings especially means you might not even get to the good parts, and spend the whole time arguing about the terminology of the signon process.
3. Follow up with details. Email is a great way to send more thoughts. Whether something didn’t occur to you at the time, or you are just a junior flunky and didn’t get a chance to speak up in the meeting, written commentary is useful. But do it quickly, before other changes are made or you forget the rest of what you saw.
4. Express your personal opinions on how you might use the product. User research is just lots of personal opinion and observation, codified, so if nothing else your opinion can be slotted into existing knowledge, and explained. The “worst case” is that it’s a brainstorming sort of point, and something else good can still come of it. Don’t, however, believe that your experience is necessarily of key relevance.
5. Relay anecdotes about use or understanding. Don’t spout pithy sayings “my mom couldn’t handle this” but do cite specific cases that seem relevant. Whether it’s the first impression of someone looking over your shoulder, or just what your heard some people say about the competitors product, that you worry this doesn’t do, it’s okay to bring it up if it hasn’t been heard before.
6. Quote solid information. Even if it’s “just” a marketing study or three year old use statistics. Ideally, the designers already know this, but if not it’s definitely time to bring it up. Even if they do, explaining that you have concerns about the design because of specific background information is a useful place to start a serious discussion.
7. Express personal opinions on style, aesthetic, etc. These might be trumped by brand standards, or consistency, or some other design needs. But bring it up. You might have found a hiccup in the standard implementation, or something else that needs to be fixed.
8. Everyone’s opinion is equally valid. Just opinion. If they have data to back it up, that’s different and usually trumps opinion. Even if you are the VP of everyone in the room, and authorize payment to the design agency, your opinion is still opinion. Your employees (and the vendor) were presumably hired because they are good at their jobs, so trust them to say useful things.
9. Allow the designer to counter your input. Don’t feel sad about it, because it’s not personal. If they have solid research, or experience, then think about trusting them on it. My guidance, whether reviewing other designers’ work or talking to clients, is “if you have a good-sounding story, I believe you.” Assuming you trust the guys you hired to do this work, you don’t have to understand what they say, but do make sure they sound like they understand what they are saying. Treat design like anything else you pay good money for, and trust their well-founded argument.
10. Review the changes later. Designers forget stuff, or don’t understand, or might make a new solution once they get back to the office. This is another reason you should write everything down. Don’t nag, but if you thought you understood that something different was going to happen, ask why. And feel free to ask for clarification; “we think” should be able to be followed up by “because of user research that indicates [something specific, with numbers].”

As a general rule, don’t be this sort of client, but do take ownership of the product. Offer the feedback that your position, background and knowledge of your business provides you.

A long-time friend of mine works at a major defense contractor, and is regularly providing me an interesting background in corporate telecoms. Most relevantly, his departent (company?) went wireline replacement some years back, so he’s issued a smartphone. They’ve had well-publicized lost computers full of employee data, so exercise a lot of control over their devices.

Here’s an email I got from him recently:

My Blackberry pisses me off in how it manages meeting notices.

If I don’t use my phone for a while, I might have several meeting reminders waiting for me when I go to use the phone. So when I pick up the phone, the first thing I have to do is unlock it by typing in a fairly complicated password. Then I’m immediately smacked with these meeting / task reminders.

99.9% of the time, I sitting in front of my laptop and I manage meetings/reminders on my desktop and not via the phone. But if even if I dismiss meeting reminders on my desktop, those meetings aren’t dismissed on the phone. Similarly, if I dismiss things on the phone, they’re not dismissed on my desktop.

So I hate the phone reminders. But that’s not even the biggest problem. The bigger usability problem is when I need to pick up and use my phone quickly. One example is when I’m receiving a call. And the other is when I need to make a call quickly.

When I want to recieve a call, I can pick up the phone and just press a button to answer without having to unlock the phone with a password. Typically I take all calls on speakerphone, though, so my desire is to press a button to answer the phone and then press the two button combo to put the phone on speaker. The problem, though, is that as soon as I answer the phone, I am FORCED to disposition each meeting reminder before the keyboard will allow me to switch to speaker phone. I MUST address each notice before I can go to speaker phone. Pisses me off.

And when I want to make a call quickly, the same problem occurs. I pick up the phone, unlock it with the password, and start dialing the number I want to call, only to realize that the phone isn’t even recognizing my typing because it wants me to first disposition the meeting notices. There is no way for me to make a call before I deal with each of the meeting reminders. Which is best exemplified by another common (and irksome scenario). ..

I’m on a conference call from 10:00 a.m. to 11:00 a.m. And I know that at 11:00 a.m. I need to go RIGHT into another call. So at 11:00 I hang up from the call I was on and immediately start dialing the next number I urgently need to get to, only to be again forced to deal with meeting reminders BEFORE I can make the call. I’m simply forbidden to dial until I give my calendar the attention it desires. If I end up being late for my 11:00 meeting, too bad.

Since when is my calendar more important than me being able to use the phone? Why can’t the meeting reminders wait?

I’ve had much the same opinion about some things my mobiles do, but haven’t had time to think much lately, so haven’t typed them up. But there are several lessons here.

First, end users matter. Some of his issues are a result of security software loaded by the corporate entity. Some of the others might even be surmountable by customizing the device. But it’s highly locked to him. He cannot do almost anything to his phone.

I did a fair amount of B2B (and government) work while at Sprint, and saw this a lot. Ignoring end users because they don’t make decisions. Yes, my friend cannot drop his service or change handsets, but his productivity is clearly impacted by poor user experience.

Second, you have to design holistically, or maybe, systematically. The Palm Pre I am using now is good at obscuring keyboard functions (including the mute and speakerphone functions, like my friend’s case).

My friend’s problem seems to be that every alert is modal. For the project I am currently working on, I almost let that happen by accident just by semantics. I called this subtle notification strip “alerts” in the documentation. By default the developers assumed that word meant they were critical and therefore modal. Luckily I (and the rest of the Little Springs team) was around and evaluating what SAs and developers were doing, and noticed this.

I have some detailed strategies aside from “constantly review” to correct this, but no magic bullet. Essentially, I say you need someone with a product-level vision, and I like to say that’s a dedicated designer.

For that product with the notification strip, it was blocked off for each and every screen and state wireframed out. Only a few things can be obscured by it, and those are carefully chosen; it’s okay if they are unavailable for a moment. This is my sort of tactic for holistic design, and so far seems to be working out.

Third, and maybe most importantly, people matter more than devices. I get similar behavior with my calendar reminders. I can get the same reminder:

• In google calendar as a popup
• In gmail
• Sent as an email to the corporate email
• Popping up on the phone

That’s not even considering that I have 2-3 computers I might be on, all with access to the same network of services. I could theoretically dismiss the same reminder TEN TIMES.

Sure, sure. I want it to be able to come up on all these, so I don’t forget about a meeting. I am forgetful, so need the help.

But I have to wonder why it cannot send a message to the network when you dismiss or snooze an alarm. Then dismisses (or snoozes) the alert in ALL your locations.

If I dismiss, that means I saw it, and should not have to be reminded again and again. I. Me. The person. Who cares about the the system?

Over on the very nice UX Exchange, user mattti asked the question, Touch gesture usability in mobile devices – which ones work?.

As we’ve been doing a bit of work in gestures this year, I tossed off this response.

Touch gestures are only one type of gestures for mobile. Technologies such as accelerometers, light sensors, other cameras, pressure sensors, RFID, NFC, Bluetooth, and various location technologies are all possible.

Then there are the “display” mechanisms: vibration, rumble, electrical fields, force feedback, sound, and so forth.

In general, this space is in its infancy.

Phones should always be designed with one-hand use and two-hand use in mind, but it is up to the product team to decide the relative emphasis. Clearly making and receiving calls should be one-handed. Should web? I don’t think that’s as necessary. But usability can be achieved either way.

When designing gestures, you must keep in mind that they lack any innate visual affordance. You must rely on other methods to enable discoverability. There are a few approaches to this. The iPhone’s “flick” (scroll fast) gesture is a very simple extension to an existing behavior; it uses something people already do and just responds more naturally to it.

A second approach is training. The Palm Pre requires users to go through a training video to get the “back” gesture, as you really can’t use the device without it. There is no corresponding button.

Apple has used advertising to teach people about pinch to zoom. It’s less effective: many users complain that they just can’t read the browser text. They’ve not discovered how to zoom in.

Like I said, this space is very much in its infancy. But principles we’ve observed include:

1. Carefully train any gestures critical to the use of the device. Swipe left for back, pinch/spread to zoom out/in, double-tap to zoom to fit.


2. Avoid making many gestures critical to the use of the device. Provide menu or icon alternatives for most gestures. Gestures (and voice control) provide shortcuts, not navigation through menus.


3. Use natural finger or thumb paths rather than requiring strict rectilinear paths. In other words, use good biomechanics and be forgiving of error. Example: The iPhone unlock screen requires too much precision in start and end points to unlock. It is too easy to stop at the wrong place.


4. Test your gestures with real users. Redesign, test again.


5. Consider a device mode in which everything is done through the menu. This is the “share with somebody else” mode. Verbally communicating gestures while driving is frustrating for everybody.


6. Be smart about automatically doing things. Sometimes, for example, a person might want to lay down while reading a web page. Indeed, “in bed” is a common context for use. The iPhone makes this challenging, as it automatically rotates sideways. Some applications have a “lock” mode in which they won’t rotate.


7. Where possible, re-use gestures. Pinch to zoom should be preserved. Flick to scroll should be preserved.


8. Think outside the box. Or off the screen. I want a function that intelligently locks and unlocks my screen based on device position and light input (i.e., it’s upside down in a pocket or purse then the keys are locked; I pull it out and they are unlocked). This is far more important than an extra on-screen gesture.

Also, be sure to read some of Kevin Arthur’s work. I keep coming back to Evaluating Gesture Usability – it includes a method to actually develop and test good gestures.

Are you losing potential mobile users?

A group makes a mobile site or app. When making the desktop site to promote the mobile service, they say something like:

Use your phone and visit: m.google.com/reader

That's a direct quote from the Google site promoting their mobile services. I copied the source code, not just the text.

Usually this emphasized text is also underlined. This is true on the actual Google page with their CSS applied. It looks like a link. That's fine, right? It's a link?

That's the problem. It's not a link.

I thought, "I want to find the mobile version of my favorite service. I will search for that link from the search tool on my mobile." The Google search results were terrific, leading me right to the page where I would find the information I needed. But the link didn't work!

I had to look at the URL, remember it, and then type it in. Bad plan. Most smart phones' browsers will render desktop web pages. And search results will typically return desktop web pages.

Opera also did this last week when they launched Opera Mini 5 beta. I mentioned it on Twitter; they have fixed the problem. Kudos to Opera for monitoring social media. But shame on Opera for not thinking that some people might visit their desktop site from a mobile phone, and make it a link in the first place.

Your simple takeaway: when telling customers how to find your mobile content via a URL, make the URL also a link.

This includes you, Google.