Seen & Learned

User experience for software and service updates

2011-10-20T06:45:00.000-07:00

Changes to the things we use every day affect us and how we feel about the organizations that push change on us. Every time we decide to allow an update or buy a new release, we are taking a leap of faith. Sometimes those leaps are rewarded, and sometimes they are not.

Regardless, our time is required to relearn, and this investment is not acknowledged or appreciated. I've read that brand loyalty is at an all-time low. People are happy to try new restaurants and services with a coupon from Groupon, but vendors report that coupon use is not translating into repeat business. I don't know statistics about mobile and computing software specifically, but based on my extremely limited and unscientific example of myself I can only imagine that maintaining a positive customer experience after purchase is valuable.

Four tips for better software update experiences:

Show me what I can expect. Let me preview what will change visually, not in a readme file after the fact. Google is doing this well with its beta interfaces.

Let me choose. Give me a choice to retain an old interface. Twitter, Yahoo!, and Google have all allowed users the choice between new beta interfaces and the familiar old ones, even if eventually these choices were taken away.

The UI should always be a high priority. I've seen more beautiful launches than I can count that degrade with the second release. It's great that the UI/UX were stunning at first, but if feature fixes and additions compromise the UI in subsequent rounds, the initial effort truly was for naught.

Assume people will hate it. Your organization may think that the update is great and fixes all kinds of issues, but chances are users aren't aware of the problems; they're only aware of the change. If you keep in mind that people will hate the update, it's more likely that changes will be made in a way that has less negative impact on consumers – and communications will be less about what the organization thinks is better, and more about what people can expect.

Where's this coming from?
Recently, I downloaded an update for my Android mobile phone. I didn't think about it much before doing it. I saw the prompt, figured I had enough connection strength and time for the update, pushed the button and put the phone back in my bag.

image source: http://gadgetian.com/5770/verizon-moto-
droid-pro-software-update/

Taking a glance later, it was immediately clear that the interface had changed. One of my favorite things about the phone was the lovely graphic that reflects the time of day. Now, instead of late afternoon sunlight, I saw a generic blue screen and the time. Sigh. A few taps and I saw that the entire black-background, high-contrast interface had been brightened, buttons outlined with white hairlines, more prompts added. Clearly someone was trying to improve something, but even though I am usually on the designer's side in this situation, I was just annoyed that things had changed, that the changes appeared to be for the worse, and that I hadn't been warned. The thought crossed my mind that I could change to another carrier with another phone with a more appealing interface. If I have to adapt, I might as well adapt to something else.

No one likes change, even when it's for the best; it takes time and reflection to realize and appreciate change. A few years ago, I facilitated a working session for an organization to help them decide what values were important to convey as part of a new visual identity. In the session, there was a lot of excitement about the future for the group and its ability to be thought of as cutting-edge. When it came time to review logos that had been designed to reflect the key adjectives the organization wanted to portray, the same group overwhelmingly favored the identity that was least changed and most conservative. Asked to explain their choice, they cited the history of the organization and the need to appear consistent – the opposite of what they previously wanted to convey.

Consumer products and services are user experience-crazy right now, with everyone across all levels of organizations getting that experience matters. (Thanks, Steve!) Despite the desire to create products and services that people love, the software world manages product changes extremely poorly. The phone is one recent example; Netflix's proposed service changes are another. I know graphic designers who are running an operating system and software from 2005 because they are so afraid of the interface changes and the time needed to remaster the software with each release.

Helping customers manage software update changes is a seemingly small way organizations can go beyond saying customers matter and show customers that they matter.

Improving the usability of Google Flights' Limits tool

2011-09-21T13:59:00.000-07:00

Recently, Google launched its new Flights service. It's got a nice, clean UI that falls in line with Google's new design approach for all its applications: crisper typography and bolder colors that guide the eye and enhance readability, and layouts that work smoothly across multiple web and mobile platforms.

For the most part, I like the interface. The map interactions are obvious, and there's a refreshing simplicity to the few controls on the page. But there's one part that's still suffering from Google's classically engineer-driven approach: the Levels widget meant to help you optimize flight time vs. price.

Problem #1: A name like "Limits" is no incentive to click. I clicked only because I was looking around the interface for the first time and had professional curiosity about what Google was up to here. At minimum, the tooltip should use a verb to encourage clicking: "Set flight limits." Better: "Limit flight times and prices."

Problem #2: What the heck is it? Okay, the little icon implies I'm going to get a chart of some kind, and sure enough, it's a scatter plot. But I spent longer staring at this chart trying to figure out how to use it than I should have, and I believe most people will have this same huge "stop and think" moment. Highly informal polling of my Twitter followers, most of whom are in the 25-45 age range and comfortable enough with computers to be regular Twitter, Facebook, and Google application users, confirmed that my most nontechnical followers had "no idea" (a direct quote) what they were looking at. Only the two friends who were heavy Google tool users figured out the widget and its interactions immediately.

In fairness, this tool may have been designed for a more technically minded audience. But a few simple fixes could open it up to a wider audience and help make it indispensable.

Problem #3: How do I use it? Where do I start? The slider handles that don't even look like clickable, draggable slider handles until you roll over them? The dots that only give you information on rollover if they're inactive? The badly written, almost invisible help text that implies you're filtering to find the longest, most expensive flights? My two Google-veteran followers knew what to do, but everyone else was stymied at least for a little while.

Possible fixes:

Rewriting the help text. For example, "Drag Duration and Price bars to filter your results below."
Make the Duration and Price bars feel inviting and clickable. Change the color to the Google blue and/or add a little dimensionality to them; both design choices look valid under Google's new design scheme.
While you're at it, make the blue bars draggable, too.
Add rollovers for the active dots – even just the airline name, flight duration, and price would be enough to reinforce the dots' relationship to the results below.

Flights is a very young Google product. I'm sure Google plans to keep updating it, and hopefully future versions of the Limit tool will be revised to improve its ease of use. I know I'll be keeping an eye on it.

Quickie "Valued Features" Prototype Test

2011-07-13T09:17:00.000-07:00

We were recently part of a team redesigning a student services department website for MIT. A lot of ideas for home page features were discussed at the kickoff meeting. The question quickly became, which of these features, if any, would students value?

Since it was the end of the semester, we had limited access to students. The client team suggested that a lot of students would be at an upcoming event, so we designed a test that they could take in a few minutes at a table near the event entrance.

We created a very simple prototype using OmniGraffle that included a simple black and white mockup of a bare home page frame, and several cutouts of proposed paper features and content elements.

For the test, students selected the paper elements that interested them most and placed them on the paper home page frame while telling us why they'd chosen those elements. We photographed each student's selections as documentation and asked two direct questions from our test plan. With two test facilitators each conducting one-on-one tests, we had 15 responses in less than 20 minutes!

The students got the idea of the paper prototype right away and had no problems understanding the test or the interactivity suggested by the paper features. We heard stories of how they imagined using the new site and the proposed features. The test provided simple data for the "what" and the "why," which helped the group make decisions.

One test gem was that about half of the participants interpreted one of the features differently than intended – they saw a pair of small photos as staff member photos rather than student photos. Since they commented about how nice it would be to see a staff member and click on their contact information, we learned they valued a feature that we hadn't anticipated.

After the test, we tallied which features were selected most, reviewed the reasons students gave us for their choices, and created OmniGraffle wireframes showing proposed content and features based on what we learned.

This test could be adapted to be run remotely via screen-sharing software, such as GoToMeeting. Hand over the keyboard and mouse, and participants can place content and feature elements on an onscreen frame. Either way, it was a quick and effective method to determine what users value.

Adding NOT selections to checkbox interfaces

2011-07-01T12:06:00.000-07:00

We've recently come across questions online and in our own work about how to deal with negative selections in a checkbox UI. Usually, a checkbox's on/off status in something like faceted nav is enough to convey that you're not interested in seeing results from the unselected items. But what if you specifically want to select items to exclude?

Grafting NOT functionality into a checkbox UI can make the UI feel overly complicated and unintuitive. But a couple days ago, quite by chance, I found a site that's doing it well.

I was searching for a knitting pattern on Ravelry, an online community for people interested in fiber arts. Ravelry's search uses a standard faceted UI to help narrow results:

Since I don't crochet, I clicked on "knitting" in the Craft box to limit the number of patterns. That's when this additional dropdown appeared:

I pulled it down to explore further:

Ravelry's use of simple Venn diagrams to convey what can be confusing search concepts to nontechnical users is a great idea, and using soft colors and a light gradient to help the dropdown feel friendly and accessible is also a smart choice. But I was especially pleased to see them take things one step further once you actually select an item in a NOT search:

Putting the "do not" icon in the checkbox reinforces the choice the user made from the dropdown, and makes it crystal-clear how search results will be affected.

For most Ravelry searches, you won't need this additional UI feature. But it's there if you do, and it's the best solution I've seen for this complicated problem.

Slides and Summary of Web Application Visual Design Session for Boston CHI

2011-05-03T10:10:00.000-07:00

Layout, type, color, imagery and identity are key to communicating in any medium. Because web apps are interactive and often need to help people get things done, these five elements have a big effect on usability – if they are present, they automatically communicate a message. They are the "tools" that the designer has to establish the UX goals of consistency, hierarchy and personality.

Our session at the Boston CHI Professional Development Day was designed to contextualize these core visual design principles for web applications. While there are tons of articles on the web and in print about web design and user experience, a lot of application interfaces are designed without visual expertise, and there are few resources that get into the nitty-gritty of applying these principles to complex web application design.

The session, like some of our blog posts, attempted to provide guidelines to help developers and non-designers avoid common mistakes, make informed decisions, and ideally, elevate the ordinary. When creating the session, I thought 5.5 hours of instructional time was a lot. In practice, I found it wasn't nearly enough to provide the kind of framework I'd hoped to. There's too much to talk about, and most of it takes practice to master the basics. In hindsight, I wish I'd kept the focus to common mistakes and ways to avoid them.

Web Application Visual Design for Non-Designers

View more presentations from Nimble Partners

In the session exercises, participants started off with a simple dot exercise similar to what's shown in our post on Visual Hierarchy and Why It Matters, and moved to analyzing a sample scenario to tease out interface elements. Participants listed and prioritized the implied interface elements based on their reading of the scenario, and then sketched designs, applying the principles of proximity, alignment, grouping and nesting.

Mastering positioning and layout (not to mention color, type and imagery) takes a lot of trial and error. We could have used the whole session just creating simple prototyped layouts, testing them with each other and changing the layout (position of buttons, position and juxtaposition of features, etc.) to experience how seemingly small changes can affect perception and use.

Join us at Boston CHI for a day of visual design for web apps

2011-03-06T12:52:00.000-08:00

On March 25, we're delivering a seminar for Boston CHI's Professional Development Day on using visual design to create more effective web applications. There's still time to register – we'll be covering many of our tips for web developers in person, along with tips on page organization, use of color, and layout guidelines.

Click here for more details and registration.

Visual Design Tips for Web Apps:  #4 – Visual hierarchy and why it matters

2011-01-06T06:45:00.000-08:00

This post is the fourth in an occasional series of tips for developers and other non-designers who don't have a designer to work with when needed, who want to improve the aesthetics (and usability) of their apps or who want insight into the designer's approach.

The single biggest issue we see in web application UI design is a lack of visual hierarchy – the arrangement and treatment of elements that represents their relative importance.

Developing a strong visual hierarchy is important because the presentation of elements will communicate to users whether you “design” those elements or not. Considering placement, treatment and use is essential to creating applications that make sense.

Left: lack of hierarchy – no clear direction is implied.
Right: variation in relative size, placement and treatment start to indicate a hierarchy.

When presented with a screen for the first time, users need to quickly grasp what they can do on the screen, how they can do it and why they might want to (i.e., what effect their actions will have). Establishing a visual system that outlines each element or group of elements’ relative importance will direct the eye, affecting the order of when elements are seen as well as user behavior – if form fields are filled out, if submit buttons are clicked, if links are found, and so on.

There are several factors that can be manipulated to establish visual hierarchy, with the main ones being placement on the screen, use of color, size of elements, font selection and treatment. We’ve already covered using type to establish a hierarchy, but now we’re going to review things at the higher level; future posts will address other factors individually and provide practical tips.

Super-brief introduction to the principles of visual hierarchy
Placing an element like a dot in a frame like a screen or a box creates a relationship between the element and the frame. The location of the element in the frame affects perception (Hofmann).

Left: Stable, static placement.
Right: Unstable, active placement. Movement is implied. Which dot looks more important? Which combination keeps the attention of the eye?

Placing more than one element in a frame creates relationships between the elements and between the elements and the frame. If shape, color and size are the same, relationships are based on proximity – how close the elements are to one another and the frame – which gives each object a perceived visual weight. Perceived visual weight is a key component of visual hierarchy – more weight equals more important.

Left: Which carries more visual weight? The single dot off-center or the four dots in the center?
Right: What about here? Less proximity (spacing) and upper placement create more visual weight than greater spacing and lower placement. This arrangement starts to suggest a hierarchy – that the group of dots in the upper left are more important yet somewhat related to the group in lower area.

The principles of perception hinted at in these dot/frame illustrations apply to web application elements as well.

Visual hierarchy on the web
In order to have a hierarchy, things need to be presented so that the more important things have more visual weight or prominence than less important things. Following are some ways to establish hierarchy.

In the Western world we read from left to right and top to bottom. This affects how we “read” screens as well. We know from eye tracking studies (Nielsen) that quadrant “1” is viewed more than the others. The “Inverted Pyramid” principle supports this as well (Lidwell, Holden and Butler).

Based on the principles of proximity and size, we know that small elements tucked very close to larger elements such as a border or edge – so that they appear as being inside the larger thing - are seen as less important than elements with more space all around them.

Elements with a lot of white space around them are viewed as important (take another look at the single dot in the center of a box).

Elements that are shown similarly to one another are seen as related. If one thing is more or less important than another thing, it should be treated differently – highlighted in some way.

A single element treated differently (highlighted) from similar elements nearby has greater visual weight and may be perceived as more important.

Large elements are seen as more important in comparison to smaller elements. Obvious, but only Apple seems to have mastered this consistently.

Defining a hierarchy
The main thing to consider when making decisions about where to place elements on a screen and how to treat them visually is to identify what most people need to do (or what an organization might want them to do) on the screen; and if that's more than one thing, the priority of the desired interactions. (For example, “we want everyone to sign up or log in, but if they don’t want to we at least want them to complete the checkout process.”) Ideally this effort is informed by 3-4 key user scenarios that have been defined with input from stakeholders or direct knowledge of user behavior.

An explicit way to define a hierarchy is to list the elements you need to have on your screen and number them from most to least important. An element is a unit of content or functionality. Your list may be something like this:

• search box
• submit/cancel buttons
• footer
• automatic update widget (for blog and twitter)
• latest 5 items
• featured content text
• promotional headline
• cart widget
• global navigation
• local navigation
• login area
• logout
• content areas

There can be more than one element with the same number – they will need to be treated in a way that suggests equal importance. The prioritized list serves as a blueprint for defining visual hierarchy, and can be used when making decisions about placement, size, color and treatment.

Next: Screen layout basics

References
1. Don’t Make Me Think by Steve Krug
2. "Communicating with Visual Hierarchy" by Luke Wroblewski
3. Graphic Design Manual by Armin Hofmann
4. Eyetracking research - findings from Nielsen Norman Group's usability studies using eye tracking technology
5. Universal Principles of Design by Lidwell, Holden & Butler

Visual Design Tips for Web App Developers: #3 - Use type to help establish and reinforce visual hierarchy

2010-11-11T06:21:00.000-08:00

Like a newspaper, web apps may have multiple text elements at similar levels of importance throughout the layout. Unlike a newspaper, web apps might not have editors and designers to direct and define the information hierarchy on a daily basis.

Defining rules for type styles and applying them consistently provide the cues people need to quickly process and make decisions about where to read or what to do in a web app. Aside from aiding usability, typography can be what transforms your design from good to great. We don't expect you to be type geeks, but we do think that with a few tips and examples, you'll be able to create and use simple and effective type hierarchies and avoid common mistakes.

Choosing a font
This blog post covers choosing fonts for an application's content and features, not for its logo (visual identity). Selecting fonts for identities requires different criteria, and for that reason, we assume that a professional designer will be responsible for creating a memorable identity.

In a web application, typically one font family is enough as long as it has three weights: for example, roman, bold and italic; or roman, semibold and bold. You can get away with a font with two weights if you add the use of caps to the hierarchy, but this needs to be done with restraint. (See examples later in this post.)

A serif font will make your application feel more traditional and print-like, while a sans serif is more workman-like. Serifs create more visual activity and sans serifs typically create less, but this varies from font to font. Many aspects of a font contribute to (or detract from) its readability online. This, combined with the fact that you may need to complement an existing style or establish a visual style for brand purposes, means that you may have to try a few different options before you find one that feels right for your application and its audience.

Typetester is a great tool for selecting and comparing fonts.

Choosing a size and weight
Size and weight differences are one way to establish visual hierarchy with type. For example, larger, bolder text emphasizes more important headers, and small, italic text is better for captions or in-context help, places where you are providing supporting, not lead content.

Use boldface and italics sparingly. They're cues to highlight information, and when applied too often, make your text less readable. Reserve them for headers as much as possible, and never use underlines unless you're indicating hyperlinked text.

In general, you won't want to use type any smaller than 8 pixels high onscreen, and even at that size, some browsers may begin to render the type with jagged edges. Check your type across multiple browsers and platforms to ensure it's legible everywhere, and consider sizing your type with the more accessibility-friendly em units.

Sample type hierarchies
To illustrate some of what we've been talking about, here are some sample type hierarchies. The goal of these hierarchies is to create a set of type styles that show a visual progression from strongest to weakest in relation to one another.

Tahoma hierarchy:

Georgia hierarchy:

Myriad hierarchy:

Choosing a link style
As the web has evolved, people have learned that underlines aren't the only way to identify a hyperlink – but the problem is that there is no one convention to take its place. Color change and highlighting are two other conventions.

Links on the MIT Media Lab's website display a light blue background tint on rollover.

Blue headlines are underlined on rollover on The New York Times' website.

Color change is an appealing cue, but it's prone to contrast problems, and rollover effects can't help users who never figure out where to roll over in the first place. The New York Times can get away with using non-underlined discoverable links because the online newspaper format is a convention its readers understand. If you have an application that does not follow known patterns and/or people need to learn it quickly to get things done, underlining is the clearest way to convey "clickability."

Type hierarchies in practice
The hierarchies shown progress in visual importance from most to least. However, in practice, hierarchies are often not linear progressions. For example, Level 1 heads often need to be less visually prominent so as not to upstage more important content – a case of being more important from a semantic markup perspective, but less important from a visual one.

The illustration below shows one way a hierarchy might map to levels of heads in a web app. (Click image to enlarge.)

Getting your font online
There's been an explosion of tools available to move type on the web beyond common system fonts such as Arial, Verdana and Georgia (although these are fine choices for web app fonts). CSS and JavaScript-based options – the @font-face attribute, Typekit, Google Font Previewer, Cufón, etc. – offer simple and often free methods of incorporating other fonts into your web apps as HTML, not Flash or graphics. Our preference so far is Typekit, for its inexpensive access to a wide range of well-known and well-designed fonts.

Licensing, however, remains a thorny problem, with each type foundry having its own set of rules about font embedding or linking. No matter which option you choose to bring additional fonts into your app, be careful to check the fonts' licensing requirements to make sure your application stays nice and legal.

Basic rules of thumb

Body text should be roman, with a limited column width (ideally no more than 600 pixels) to enhance readability.
It's okay to use caps, but they create a lot of emphasis, and making text bold and all caps is the VISUAL EQUIVALENT OF SHOUTING. Don't do it unless you really need to or you reduce the visual volume by shrinking the font size slightly and/or adding letterspacing. (See the hierarchy examples for effective uses of all-caps headers.)
Just because you can use tons of fonts on the web now doesn't mean you should. Sticking with system fonts is better than using an unusual font that will distract from the content.

For more information

Typetester is a great tool for selecting and comparing fonts.
Thinking With Type: a site for a book by Ellen Lupton that has basic typographic information. More for traditional typography as opposed to screen/application typography, but still applicable for the basics.
Becoming a Font Embedding Master, blog post by Jonathan Snook.
For wannabe typegeeks: On Web Typography by Jason Santa Maria.
A handy survey of commonly installed fonts by platform.

Visual Design Tips for Web App Developers: #2 - Use a small set of UI affordances, and apply them consistently

2010-10-29T06:53:00.000-07:00

When developing a complex application, using the fewest interface elements and behaviors consistently is critical to make your application look organized and behave as expected. For example, this version of an older application has three separate ways of closing a window:

Users must close the leftmost popup by mousing out of it, the center popup by clicking a link or a nearby button, and the top popup by clicking a link that looks completely different from the one in the center popup. Having one way to close a window rather than three would reduce the number of visual cues, improving the appearance, and would help the user know what to expect from the affordance, improving usability.

Here’s another example, the editing interface from the latest version of Microsoft's Photo Gallery software.

It looks like the design and development team tried to introduce some consistency by using an “x” icon for deletion. The problem is that not all the “x” icons do the same thing – the brushstroke icons at top left and bottom delete the photo, the heavily stroked red x at upper right closes the photo file without deleting it, and the small gray x at right closes the metadata pane. All of these actions have very different consequences – especially deletion and file closure! – so their icons should not feel so closely related, or should at least be more clearly identified than they are.

Consistency can be hard to achieve when different teams are working on different parts of an application, and when features are in flux. Set logical rules for where and how interface elements appear based on knowledge of how most people will use the application and existing conventions of any related application UIs. Work to maintain the consistent language as features gel. The payoff will be an application that looks and feels professionally designed, and rules that when documented can serve to guide further development.

For more information:

Mashable’s list of 10 web UI kits and resources for designers (just as handy for developers in a pinch!)
The JQuery UI wiki has a good page about its button design, hierarchy, and behaviors.

Visual Design Tips for Web App Developers: #1 - Align elements

2010-10-19T11:54:00.000-07:00

We've worked with a lot of great developers who not only want to make their apps work well – they want them to look good, too. We’ve put together a list of tips for developers who don't have a designer to work with when needed, who want to improve the aesthetics (and the usability) of their apps or who want to have a bit of insight into the designer's approach. This post is the first in an occasional series.

1. Align elements
If you have a UI that has a lot of elements on it, one way to improve the look is to align elements "flush left" or along the left of the lines of a grid. We’re not talking about selecting or designing and using a grid – that needs to be done in advance of development, is more in the designer’s skill set and can be more than a developer wants to deal with. We’re talking about a quick and simple rule of thumb that can be done late in the game – aligning elements flush left to the fewest possible number of vertical lines.

Lines and grids aren’t literal representations of vertical and horizontal lines across the page; they’re virtual guides to help you place elements consistently and logically, which can present the illusion of fewer elements and create less visual activity for the eye. They just plain make your UI look “cleaner.” If you want the gory details of grid design and usage, there are plenty of places to look – see links at the end of this post. In the example image, not all elements align, but enough do to make this busy layout look organized and not chaotic.

To illustrate further, we’ve taken an old UI and reduced the number of left vertical “lines.” This decreases the visual “activity” created by the ragged white space created by aligning form labels right. The change increases the distance from field label to field, but the gaps created are not as distracting to the eye.

Before

After

More information about aligning page elements:

Luke Wroblewski's web application form design page goes into detail regarding the pros and cons of form alignment.
The ultimate guide for designing with grids – overview, techniques, examples and tools.
The best old-school graphic design manual on grids is The Grid by Allen Hurlburt.

Notes from FutureM Boston: “The Future of the Web User Experience”

2010-10-12T13:39:00.000-07:00

On October 6, I attended part of MITX's FutureM program, where Bill Albert, director of Bentley University's Design and Usability Center, and Moira Dorsey, an analyst at Forrester, spoke with Weymouth Design President and CEO Tom Anderson about what the future might hold for web user experience design and content. Here are my notes from the talks.

Moira Dorsey

New forms of technology start by emulating older forms (like the "horseless carriage"), and then evolve.
Online experience has yet to find its true form.
70% of US consumers prefer "rich" interactions (Forrester statistic).
Framework for the future: CARS - Customized, Aggregated, Relevant, Social.
Cool example: Wikitude augmented reality travel guide
User research is the key to knitting together experiences across channels.
Customer experience maps are a good tool used to help as well.

Moira's presentation is posted here on the Forrester site.

Bill Albert

There are a lot of new tools to help collect quantitative and qualitative data – help designers and businesses get a clearer picture.
New tools facilitate micro-studies – can test at the pixel-level.
Do users trust your site? Find it attractive? The devil is in the details.
In the UX industry, Bill sees a shift from usability to persuasion – usability beyond the web to all communications.
"Usable" is no longer enough.
Studies on user experiences – example of four ads for Fidelity. The promotion that was the least ad-like (no image, no background color) got the most clicks

Bill's presentation in a .pdf is here

Thoughts and question

These were very solid presentations that complemented each other well. Both talked about how design is no longer about the web – it goes beyond to all channels, and research with users is key to getting the UX across channels right.

At the end, I was thinking about the 70% that Moira mentioned prefer "rich experiences" and the majority of testers Bill mentioned who selected the Fidelity ad that was the most plain, and asked, "How can the difference between these seemingly extreme examples be reconciled?"

Bill and Moira's answer was that the plain ad was central to helping people accomplish a task – a serious one about retirement planning. It goes back to data. An example of "rich" is Google Maps. If the "richness" is too fancy that is a problem. My take away is this: data + rich + simplicity = happy users.

Gourmet Live: fun to read, a pain to use

2010-10-08T13:18:00.000-07:00

I subscribed to Gourmet magazine for nearly twenty years. My parents subscribed for forty. So when Condé Nast abruptly pulled the plug on the magazine a year ago, we, like many other subscribers, were upset about losing a connection to the food world we'd had for a very, very long time.

So I was thrilled when I discovered earlier this year that Gourmet Live would be released. If you haven't heard of Gourmet Live yet, it's a free iPad application that brings back key aspects of the Gourmet experience: the professional, engaging food writing; the crisp design and mouthwatering photography; and most important, the recipes. It also incorporates gameplay aspects – something I was initially dubious about, and remain so – that open up new content when readers finish looking at certain articles.

When I downloaded Gourmet Live last week and read my first issue, I was beside myself with joy. Here was my magazine, back from the dead! But the deeper I got into it, the more I began to notice the seams, the places where things didn't fit together perfectly or work the way I expected. In an early release – as of October 6th, they're up to a (buggy and iPad-crashing) version 1.02 – I expect there to be kinks to work out. But I don't expect basic user experience blunders.

Gameplay is fine for those who enjoy it, but I want my content.
I enjoy playing games and solving puzzles, but a pixel hunt isn't much of a game. And that's essentially what Gourmet Live requires you to do to unlock extra content – scroll to the end of the articles, which sometimes rewards you with new content, and sometimes doesn't. How do you know how many rewards you can win in a given issue? You don't. How can you guess which articles might offer a reward? You can't. "Gameplay" runs smack up against the basic usability principle of making it easy for people to figure out what they can do next, and there's nothing satisfying about being left wondering if you have to scroll through every article or recipe, even the ones you might not be interested in, for the possible hope of finding something you else you might or might not enjoy.

I've got my content – now, how do I find it again?
Content you download or unlock is displayed as cover thumbnails on "bookshelves" in a Library area. Given how terrific Gourmet's photography has always been, this is a visually appealing interface, but it makes finding information harder than it needs to be.

In the screenshot below, I've got two "issues": "Great Chefs, Great Ideas" and "Nouveau Cajun and More."

I've also got three problems:

Three of the recipe rewards are related to content in "Nouveau Cajun and More," but the only way to tell is to know that those items appear between their parent issue and "Great Chefs, Great Ideas."
What if I remember there was an interesting-looking pinto bean mole chili recipe in one of the rewards? How do I figure out which one? Without a search engine – which I sincerely hope is an upcoming feature – I must open "Soups" or "Fall Recipes," the most likely candidates, to see if one of them has the recipe. With Gourmet Live scheduled to publish new content at least once a week, this screen is going to fill up quickly, and the longer the app goes without a search feature, the less useful it becomes.
The substitute for a search feature, the "Your Favorites" area, too closely resembles an issue of the magazine, even with its yellow highlight. Although this solution was implemented to simplify the even clunkier Favorites navigation in a previous version of the software, it's still not quite right – it should be called out as secondary navigation, not masquerading as a content item.

Great recipes! I'd love to share them with my friends ... but I can't.
Gourmet Live connects to Facebook and Twitter, which makes perfect sense; after all, people are going to want to share recipes, articles, and restaurant reviews with their friends, right? I know it's what I did with the print version, and there are plenty of food sites out there now, including Condé Nast's own Epicurious, that offer this feature.

But what can you share on Gourmet Live? The fact that you've unlocked a reward. That's it. If you've set up the app to share reward information, it sends a banal, faux-cheerful message to your social network whenever you unlock something, and where does the link in the message take your friends? Not to an online version of the article you were reading (even an abridged one), but rather to a page encouraging people to download Gourmet Live. As implemented, sharing in Gourmet Live is a business-centered feature, not a user-centered one.

Where to next?
To the development team's credit, they're taking user feedback from social networks and iTunes reviews into account to help shape future software revisions. I can only hope that as the application matures, it addresses these basic usability issues and becomes as easy to use as the print version was.

I want to love Gourmet Live as much as I loved the original magazine. But right now, it feels like a pale imitation of what it used to be.

Speaking to Students on Designing the User Experience

2010-10-04T07:29:00.000-07:00

For the past six years, I've been a guest-speaker in Ed Barrett's MIT class 21W785, "Communicating With Web-Based Media." Years earlier, when it was still called "Communications in Cyberspace," I helped informally TA the class, which led to co-authoring The MIT Guide to Teaching Web Site Design with Ed, as well as Suzana Lisanti. (The book is now woefully out of date on the technical side of things, but still has good information about how to plan and organize a class like 21W785.)

I always enjoy speaking to Ed's class, because for many of these students, this is probably their first exposure to a user-centered view of how to develop a complex website or application. Few, if any, have previously had to think about how their site's design – both its user interface and its visuals – needs to please anyone other than themselves.

My goal is to give them tools they can use to get quick feedback, such as sample user interview questions, as well as tools to help turn that feedback into something more concrete to guide them through design and development, such as scenarios, site maps, and clickable wireframes. Given the short timeframe students have to create their projects, Ed and I don't expect that they'll use every tool I give them – but just getting them to start thinking about the people who'll be using what they build is a big step forward, and one that should help them succeed in the professional world.

Slides from this year's presentation are visible below or downloadable from Slideshare.

Better Health Websites Through Better Design: Lisa Neal Gualtieri Interviews Tania Schlatter

2010-09-29T12:28:00.000-07:00

I've worked with Adjunct Clinical Professor at Tufts University School of Medicine and Editor-in-Chief of eLearn Magazine Lisa Neal Gualtieri on a variety of projects for a number of years. Lisa sees the big picture and works to make all aspects of a site its best – the content, design and overall user experience. I was honored that Lisa asked to interview me about design and health-related sites.

The following is an excerpt from the interview published on Lisa's blog on September 25, 2010. Read the full interview in Lisa's blog.

Lisa: Color is one of the most noticeable things in a site and, I imagine, one of the areas where a designer is dealing with opinions, taste, trends, and recognizable branding both from colors that are associated with companies or with diseases (like purple for Alzheimer’s disease). What is the best way to select colors and a color palette? How does a site color scheme work with advertising? I ask this because I just saw myDr.com.au where the advertisements are by far the most vivid parts of the home page.

Tania: Color is a tool that helps set a tone and create visual relationships. Color needs to be selected based on strategic goals, not subjective preferences. For example, it is a great tool for helping information-rich sites be more legible and navigable. The BBC Health site uses color to consistently distinguish navigation from content, which both looks great and helps the user.

If an organization has colors that it uses in non-web communications, the designer and client team need to consider if it is desirable to link the website to other communications visually. If it is, then using the same color palette is an excellent way to do that.

MyDr.com.au looks like it is trying to balance the need to convey useful information with the need to make money from advertisements. If the site is more colorful the ads will be less prominent, which could be a problem for the site’s bottom line. The site’s use of blue with a little brown is consistent which helps the user distinguish editorial content from promotions and which may help visitors focus on content.

Lisa: Speaking of imagery, many sites use stock images of smiling people, yet the sites are often about serious diseases. What makes imagery appropriate for a health site?

Tania: Appropriate imagery related to health helps inform, so while not visually appealing, photos that show what the text is describing are appropriate. These images need to make sense visually for the audience, so it is important that they are accurate and informative. One way to deal with photos that are informative but not so nice to look at is to use them small and allow the user to click to see them larger.

Photos of caregivers/providers are appropriate and helpful, both as headshots with biographical information and showing people in their working situations. Showing healthcare workers on the job can be an effective way to help site visitors know what to expect from an unfamiliar situation. For example, seeing practitioners with a patient in the care setting can help people imagine themselves in the situation and manage anxiety about an upcoming visit. Patients need not be shown – their back can be to the camera – but it is great to see both the provider in action and the environment. Sometimes organizations are resistant to using pictures of staff to help set the tone on a website because they do not want to show people who might leave the organization. If the images are used to set a general tone (as opposed to identify specific personnel) then the concern is purely an internal one. Site visitors are not that literal in their reading of photos, and the photos can still be effective.

Read the full interview here: http://lisaneal.wordpress.com/2010/09/25/design/

Establishing Qualitative Criteria for IA and UX in One Fell Swoop: How to Conduct a Card Sort with Storytelling

2010-07-22T18:20:00.001-07:00

Slides from a presentation we did at the Boston Mini UPA conference in June 2010. "Card Sorts with Storytelling" is how we describe the type of research we started doing with site users for MIT Medical in 2008. We combined methods – a card sort, careful questioning and task completion – into a protocol to get information to inform site map, feature and overall IA decision-making, which was stuck due to lack of team consensus. The sessions were successful, and the results were extremely helpful in helping the team focus on making the site as useful as possible for the MIT community.

We refined and repeated the format on several higher-ed projects with similar success. This practice is not intended to replace more rigorous testing, but rather to quickly provide a project team and visual designers with user information when there otherwise would be none.

Establishing Qualitative Criteria for IA and UX in One Fell Swoop -- How to Conduct a Card Sort with Storytelling

View more presentations from Nimble Partners.

User experience design overview for Tufts' School of Medicine web health communication class

2010-07-22T12:43:00.001-07:00

Slides from my talk at Lisa Gualtieri's class at Tufts University SOM. Created for health communication students to give them an overview of design activities and the process of designing sites and apps.

User experience design overview for Tufts' School of Medicine web health communication class

View more presentations from Nimble Partners.

Making "Support" helpful - some tips for Twitter

2010-07-06T16:05:00.000-07:00

We all run into problems now and then using technology – heck, I'm a pretty tech-savvy person myself, and even I sometimes have to contact tech support. And when I do, there is nothing I find more infuriating and representative of poor customer support practices and user experience than hiding vital support information.

Consider a recent example of this: we're having problems getting our tweets to load on the Nimble Partners home page. I've worked tech support myself, so I know that the first step is to try to reproduce the bug and isolate the problem. Since nothing about our code had changed, and nothing about seaofclouds' script had changed either, I suspected the problem was with our Twitter stream. This was easily tested by successfully loading another public Twitter stream onto our home page.

So, now I knew that @nimblepartners was the most likely source of error. Next thing to do: check Twitter's support documentation and Google for potential explanations. I couldn't find anything, so finally I realized I'd have to file a support ticket. Twitter's support website allows you to log in and check the status of your current tickets, but there's one critically important thing it doesn't easily let you do: file a ticket.

That's right: you can spend all day looking through the otherwise well-designed ticket review pages, but if there's an obvious link to file a ticket, I never found one. After many frustrating minutes, I finally gave up and Googled for how to file a ticket, which eventually got me the right link – on an externally hosted site totally separate from Twitter's Support site. (Update: days later, I discovered that FAQs about account abuse and a small selection of other issues have links to the ticket form – but there's no consistent placement for or treatment of a link area.)

I understand why companies want to drive customers to online documentation: it's vastly cheaper than having a human provide assistance, and most of the time, a good FAQ will solve most of the problems. But there's no reason to hide or bury vital contact information – all this does is annoy your user base, and for a company like Twitter that seems to pride itself on interface simplicity and a friendly, inviting user experience, this kind of hide-and-seek game is antithetical to the way they're trying to present themselves.

One possible solution: make the link available on support FAQ pages as part of a consistently placed and worded "did this answer help you?" area at the end of each question. This hides the link from the casual emailer who rarely bothers to click into or read the support questions, but still makes it available for people who genuinely need assistance. Ultimately, it's counterproductive to annoy customers by implying you don't want to talk to them – an ironic result for a company whose basic mission is to promote communication.

A Tip for Visual and Information Design from the Movies

2010-03-19T06:38:00.000-07:00

About this time of year I participate in the AIGA's student portfolio review. Graduating designers pay for the "privilege" of showing their work to as many volunteer professionals as possible within a set time limit. As a reviewer, the heat is on to grasp a student's capabilities in a nanosecond and impart some wisdom that will magically help them transform their portfolio into a thing of power and beauty that will make jaded design hiring managers weep with awe.

These brave and determined kids have paid through the nose for college, paid quite a bit of beer money to be critiqued, and fairly enough, have high expectations of the event. The work varies. In a room of about 16, there are a few standouts. For one or maybe two, it is hard to believe that they had formal design education. Last year I was faced with a portfolio that the student should have been able to use to get a refund from his college, or at least a free extra year. College doesn't work that way, unfortunately, and I had to figure out something constructive to say, fast.

The student used his own illustrations as backgrounds to several CD packages and action movie posters. The illustrations were graffiti-like and the type was big and bold. Overall, the work was a visual explosion, not in a cool way. I started talking about movies – about how in action movies there's a star and a best supporting actor or two. Visual design is like that. You can think of what you are designing as a movie with a cast. To tell the story, there may be a headlining star above everyone else – they are the most important thing. In a comedy or period piece there may be an ensemble cast and the setting may play a key role. In a buddy film there are two stars who are usually very different, and it's the chemistry between them that makes the movie interesting. When you think about your poster or site or whatever as having a cast, and you identify elements of the design in terms of a cast of characters with "roles," it forces you to think about hierarchy and the relationship between elements, which is a good thing. When a film has a lot of big stars, the script has to be written to use them wisely, where they have the most impact.

My student nodded like I was speaking a language that he understood, which made me feel relieved. I have no idea how he's fared, but I used the movie analogy yesterday to help get myself unstuck on a website design. It has helped me, and I really hope it has helped him.

Guest post on designing web-based communities for professionals

2010-03-19T06:32:00.000-07:00

We are pleased to contribute a post about design to Leader Networks' blog, Building Online Communities for Business. We've worked with Vanessa on a few projects, and it is always a pleasure. Vanessa's interest in and knowledge of communities of practice pre-dates the web. She's translated her expertise on the topic from the offline world to the online world, well, expertly.

Our LN post is geared towards an executive audience and is based on what we've learned from several projects: a partner site for MIT's Center for Transportation and Logistics, an invitation-only community for executives in the wireless industry, password-protected sites for business managers and technical clients of ATG software, and an internal community for ATG employees all over the world.

Check it out here: http://blog.leadernetworks.com/2010/03/designing-web-based-communities-for.html

User scenarios beyond the web

2010-02-15T12:59:00.000-08:00

User scenarios have been widely adopted by web designers as a useful tool for helping ensure sites provide what visitors need and expect. Less well-known is that they are also a great tool for ensuring offline communications do the same.

Recently I was in Sears. They have created central checkout kiosks at my local store (Cambridge, MA) which is a step forward, because previously, it was impossible to find a cash register and a salesperson at the same time. Now there's a large checkout hub at the exit/entrance to the connecting mall. When I entered the store I came from downstairs – not from the mall. I did not pass a kiosk. I shopped and could not find where to pay. I looked for signs, and found this (pardon the fuzzy, surreptitiously shot image).

The sign points to a wall. There's no pay kiosk on either side of the wall.

This could be blamed on a number of things, but for the sake of this post I'm going to pin it on a lack of user scenarios when the store was planning the pay kiosks. If, when someone in Sears corporate offices was thinking about or planning the kiosks, the context of shoppers making purchases came up, hopefully they would have realized that finding where to pay is just one part of a flow that ends with paying – that paying is a part of a larger scenario.

A few years ago, we worked with the marketing team at Sloan Executive Education. They run programs that are attended by professionals from all over the world. Aware that there was a flow of information, and that it needed to be consistent to ensure that expectations were met, we mapped out scenarios related to how potential participants found out about the programs, registered, made travel plans and arrived at the program. After listing all the recipient types and situations, we could evaluate the communications and see where information needed to be changed, added or made more consistent.

There are hybrid online/offline situations that call for scenarios as well. Hospitals can have complex and inconsistent technical setups that send healthcare workers back and forth between paper and electronic files. Working with a client who provides software to streamline hospital discharge, we needed to design a fax form that would literally connect paper and digital correspondence. Care facilities received faxes from hospitals to let them know there was a potential patient for them. Included in the fax was a unique code that, when entered on a website, would provide the patient details and acceptance information. We used scenarios that captured the full flow of contact – online and offline. Because we looked beyond the web interactions we were able to design a complete system that worked, not just a form or site that only addressed part of the situation.

Higher education: the destination site is not dead

2009-11-17T08:10:00.000-08:00

The pace and rate of technological change is dizzying. We are seeing and hearing many organizations become disoriented. In higher education as with any organization, when there are funds there is a tendency to want the latest and coolest. The possibilities available - cheap and fast streaming video, presentation design "skins" that change on the fly, the ability to aggregate and display content from a wide variety of sources - are tempting.

Critical thinking must be present in the higher education site redesign process. Like the dessert table at a great buffet, it is easy to over do it, and forget about providing the nutrients your body (like your site visitors) need.

Bottom line - if you are a site for a department at a college or university, your site visitors need facts. They need to know what the department is. They need to know how they might engage with you and for what. They need to know who is in charge of what and who to contact for what. They need to know how your department or organization may be connected to others or the university as a whole. Prospective and current students and their parents get a huge amount of their information from the internet. They are relying on your institution or department's site for the details they need. There are many, many sites that provide inspiration on every topic imaginable. Chances are, if you have a current or potential student on your site, or even a donor, they have been to those sites and are already inspired. They are on your site to move forward and take action - to go beyond inspiration and act.

Organizations must ask themselves - are they in the media business? If not, how cool and inspiring is your cutting edge site going to be in a few months when the content needs updating? How impressive will it be when news feeds pull in content that isn't what your audience is looking for or have already seen somewhere else?

Higher education sites are destinations. Ideally, they do both - inspire the visitor by reassuring them that they are in the right place for their interests (video could really help here), and help them engage. This takes more facts than flash, more veggies than dessert, smelling salts and a heavy dose of restraint (also known as user research).

Challenging the convention of starting with content

2009-11-10T11:10:00.000-08:00

When we were recently designing a new site for ourselves, the effort started with content. We thought that once we had an idea about the content, we'd to do the design. We developed a rough draft of the things we wanted to say, worked with a great writer and came up with a final draft.

Visual designs were based on the content. After a few rounds, we liked the design. The problem was, we were no longer satisfied with the words. What was it about reading the words in the design that made us want to change them? Everything had looked good in Word. If we had been just the web design team and not also the client we would have probably been annoyed: "Don't they know what they want? It's about to launch!" We had fallen into a trap we had seen but not experienced, the inability to visualize something without seeing it complete.

We were reminded that it takes two to tango – content and design go hand in hand to communicate, and should be developed simultaneously (along with behaviors if designing an app) as much as possible to create a cohesive experience. We should have recognized it sooner and prescribed one of our own solutions – using schematic page diagrams (aka wireframes) from the beginning to define content and layout at a high level. Schematics show the types of content without showing actual writing, and the hierarchy of the layout without showing visual design. If we had done them, once the wireframes felt right we could have moved the writing and the visual design along simultaneously, which would have saved a lot of time.

Why we don't design for "Innovation"

2009-09-18T10:46:00.001-07:00

We love technology and the things it can help us do. We are excited by the new functionality and resources we see everyday. However, we regularly see and hear from people who wish the technology they already have met their needs better. Thinking back over our most recent research sessions the participants - executives, students and reporters - all want to access information that addresses their needs in a way that's easy to find.

Solving some of these problems is pretty easy, like designing a faceted search, creating a comprehensive structure for information and designing type and imagery that supports the content. Solving others can be tricky politically, like providing the names of appropriate people to contact if needed (creating transparency). A few more solutions can be time consuming, like developing summaries for a database of long documents or enabling personalization. All of these are manageable, however, and provide a significantly improved user experience.

It would be amazing to develop the next big thing, but we see a lot of room for improved user experiences using the tools we and our clients already have. Learning about what matters to people and providing it quickly and manageably never gets old.

Using card sorts with storytelling to get off to a great start

2009-03-22T18:33:00.000-07:00

Working with non-profits often means large teams with multiple stakeholders, each with a list of desired features and improvements that may have been in the works for years. The expectation level is high – funding has finally been approved, a target launch date planned and everyone knows just what they want – in fact, a site map has been developed. While each stakeholder is trying to address the perceived needs of their audience, when it all gets put together the results can be unprioritized and sprawling. The team may have been meeting for months and are looking for the designers to pick up the ball and run. However, committee-driven IA can be so democratic that it can miss providing the information that site visitors are looking for in the way they expect to find it. Our favorite path to a successful project with multiple stakeholders is holding card sort/participatory design sessions with storytelling as soon as possible.

Traditional card sort sessions involve gathering data from participants by having them sort terms into groups that make the most sense to them. These sessions are a valuable tool for creating navigation that makes sense to the people who will use the site. A large numbers of participants (>30) is needed to provide the data, and software to sort the responses is helpful. While traditional sorts are not difficult to do, we have found that having sessions with fewer participants (5-12) and mixing approaches provides input that covers several areas beyond defining appropriate navigation categories.

When sessions include prompting participants to tell stories about a specific time they used a site, perform a card sort, and use cards to position content and features on a page the way they'd like to see it the data is deep and rich. The results provide a clear picture of each person's mindset, and how that mindset affects how they think about content, categories and what they value. Patterns emerge that point to pretty clear user group needs. While it doesn't provide deep statistical data, it does provide rich scenarios of use and an understanding of needs and values that is just what we need to get buy in from stakeholders to prioritize the feature list and focus the IA on the top issues and most common situations.

Try again ... this time in English.

2009-03-17T15:52:00.000-07:00

One of the most frequent problems we see on websites is jargon-heavy text. There are many reasons why this happens: maybe the writing team is so used to serving an internal audience they don't realize that others can't understand their content; or maybe the website serves an industry that thrives on buzzwords, such as consulting. Sometimes it just happens by accident or because no one has time to really review the text before it gets posted. But no matter the cause, the result is almost always a site that feels insular, unfriendly, and worst of all, crammed with content that doesn't resonate with the audience.

One of the worst offenders on many sites is the legalese on Terms of Use pages. Hardly anyone other than lawyers actually reads these closely; they're just long, impenetrable documents we all have to pretend we've read before we can check off a box and complete a registration form.

But this week, the Consumerist singled out Aviary, a site providing online graphics tools, for their radical and simple approach to their Terms of Use page: they provided an English translation paralleling the legalese. Using concise and friendly language, Aviary spells out everything you'd want to know about their Terms of Use, from who owns the graphics you create on the site, to the different payment plans they offer, to the licensing agreements for site content. Aviary's approach transforms an unreadable page into one that anyone can understand, a goal consistent with their mission to "make creation accessible to artists of all genres."

We hope more companies follow Aviary's lead and make their content clear and easy to read, which is a more successful way to reach their audience than "buzzword compliance."