User experience for software and service updates

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.

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

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

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

1. Body text should be roman, with a limited column width (ideally no more than 600 pixels) to enhance readability.
2. 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.) 
3. 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

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

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.