Category: User Experience

Often as web developers and designers we forget that we are not a typical web browsing laymen. Even though we’ve created the handy, stunningly good looking help section on a site, a user shouldn’t have to use it. By simply observing a few users in the beginning of a project we can find countless ways to improve a site’s functionality and ease of use.

Recently one of our clients asked us to conduct usability studies to ensure that our wireframe and creative directions would be enticing and functional for their website’s users. Below is a brief summary of the two processes we conducted: focus groups and user testing.

Focus Groups

Website focus groups are critical in understanding how a site is used by a target audience and how a site’s conversion rate can be improved. By conducting focus groups on various design directions we were able to determine what our users would think and feel when they visit our redesigned site. We were able to compile feedback that can then be used to enhance the site’s user experience, increasing the site’s overall appeal and functionality and ultimately drawing in new users.

A website focus group study begins by outlining specific goals. For example, one of the goals of the focus groups may be to determine what appeals more to the target audience: images of people using a given product or just the product itself. Another goal may be to determine the response to a given page structure: Are users able to easily locate the site’s main navigation? Does the primary promo space engage the user or is another portion of the page grabbing their attention?

One of the most crucial aspects of a focus group is the selection of the participants. At this point the client has revealed the site’s target audience: age spread, demographics, etc. The number of participants for each session is intentionally kept relatively small to encourage open discussion and to promote a comfortable environment.

To ensure the conversations remain on topic a moderator is present during the entire process. Using a Moderator’s Guide, we balance the encouragement of free discussion with the underlying focus of the meeting – the outlined goals. Balancing the use of the script and free-form discussions the moderator guarantees the information received is kept relevant. Others involved in the focus group process observe the study, including note-taking and digital video and audio recording of the session.

Depending on the goal of the focus group, we are able to gather opinions about the site, including information on the site’s usage or what the participants need in order to use the site more efficiently. This information adds to the understanding of the site’s target audience, helps plan the site’s strategy, and helps to identify any areas for improvement.

User Testing

In addition to our focus groups our team conducted usability testing on key areas of functionality using a protoype. Our userbility testing involved interviewing individuals who were representative of the target audience and leading them through a series of predefined scenarios. By asking them to accomplish specific, representative tasks to determine ease of use and recommend improvements, we gathered first-hand information about how users would behave and their opinions towards each workflow.

The advantage of user testing is you learn what the target audience can and can’t accomplish, understand why users are having trouble, how to correct it, and receive direct feedback. The disadvantages are obvious: it can be more expensive to test individuals, especially when you’re dealing with multiple user types and a large number of test participants. In addition to a testing facility and moderator costs, there are also costs to recruit and compensate test participants.

Determining whether a website is compelling is the ultimate goal in user testing. During our most recent user testing session we used a variation of MultivariateTesting. This allowed us to use several variations of product pages to test the users understanding and usage of each variant.

The beauty of Multivariate Testing is that it offers the ability to isolate and assess the performance of virtually every element of a web site, landing page, or application. From page layout, to headline text, to complete color palette variations, Multivariate Testing can be highly effective in identifying what works and what doesn’t from a user’s perspective.

With our focus groups and user testing complete, we created a consolidated feedback document to pass on to the client. With recommendations in hand we allowed to client to form their own opinion of what may need to be changed and we go from there. Though the process can be extensive and tedious the results are worth it. Within one week we were able to make our site that much more user friendly and attractive to new customers.

The best way to develop an excellent customer experience is to use input from actual customers.  Conducting usability research will allow you to explore and/or validate design options and focus on knowledge that enables you to meet the needs of users/customers.

So, let’s say that you would like SolutionSet to perform usability research on your behalf, but how does it work and how can you get the most out of observing each session?

Typical usability research methodology

Unlike focus groups, usability research is typically a one-on-one sessions, set up to gather users’ natural reactions, without outside influence. A trained moderator will spend the duration of the session in the room with the participant and observers watch the study from a separate area. There are many logistical options for observation rooms and recording technologies. It really depends on your research objectives and budget. Learn more about budget usability options from a previous blog post.

Participants will be asked to complete tasks with the website or prototype that we would like all users in the real world to be able to accomplish without difficulty. The participants will be assured that the website is the center of attention and that they themselves are not being tested in any way. They will also be encouraged to think out aloud to facilitate the recording of their thoughts, expectations, and reactions to the pages.

Getting the most out of observation

Users often express opinions that do not coincide with our expectations. Study participants sometimes are confused about your company’s offerings, have difficulty completing tasks, or they criticize the appearance of a page. These reactions can be the most important data we collect! It is better to gather an unscathed and fully honest assessment of our work now than to release products into the public where the same confusion may occur.

Observing can be a mentally taxing exercise, especially for those who attend all the day’s sessions. Please maintain focus, keep conversations to a minimum, and take notes you would like to share with the group during the debriefing.

What to observe

Every signal the participant gives counts! Hand gestures, body language, facial expressions, and pauses in speech all count in addition to what the participant explicitly says and does. These tacit signals sometimes signify areas of improvement we will be able to act on.

Make note of similarities in participants’ feedback, for example when multiple participants are experiencing the same pitfalls or expressing similar criticisms. These commonalities typically identify the most obvious areas for optimization.

Record questions – both for the participant and to the group – that arise in your mind during the session. Near the end of a session, time permitting, the moderator will enter the observation room to gather questions for the participant during the wrap-up portion.

Debriefing

The purpose of the debriefing is to come to a mutual understanding of what occurred during the session. We would like to discuss and identify what you found to be really impactful and help us prioritize findings from a business perspective. This is a rewarding but sometimes arduous process, as there often may be multiple interpretations of the participant’s reactions.

Thanks for observing, a successful usability research project depends on it!

So you’ve built yourself an email. Or banner ad. Or just about anything that mentions your URL. Interested parties have been lured to your website and they’re looking for instant gratification. Is the red carpet laid out or is the page business as usual?

Scott Brinker wrote a superb article for searchengineland about post-click marketing best practices. Brinker created a graphic that shows the eight dimensions of excellent landing pages:

You’ve got about one second to reassure your landing page visitors that their clicks weren’t a mistake, so figuring out how to make your message big, quick, and clear is of the utmost importance. Take in the full article here.

Google conducted a study on how our eyes process their search results (something they clearly have a stake in figuring out). From the source:

Our User Experience Research team has found that people evaluate the search results page so quickly that they make most of their decisions unconsciously. To help us get some insight into this split-second decision-making process, we use eye-tracking equipment in our usability labs. This lets us see how our study participants scan the search results page, and is the next best thing to actually being able to read their minds.

This video shows how one participant scanned results to the query “how to tie a tie” in real time. It helps to illustrate a fairly obvious point—you’re either on the first page, or you’re toast.

Check out the full story here.

The relationship between designers and developers is too often overlooked on projects. Commonly the two teams are removed from each other and designers are asked to simply throw their work over the fence to the HTML monkeys who faithfully turn the designs into a webpage using 10,000 typewriters. At SolutionSet, the “front-end” of a website is a combined effort of three different teams; The IA/UE team does the sitemap and the wireframes, the design team creates the designs, and the HTML/CSS team takes the designs and turns them into a web page. It is all too easy to fall into a pattern of non-communication between the departments where we start to lose focus on the real people that live on the other side of the proverbial fence.

In the web industry, there is a long standing battle between the design team and the development team. One source of the conflict comes from the varying backgrounds of the designers who may have a stronger background in advertising or print rather than web. In reality, it is the designer’s job is to push the envelope and make something inspirational, drawing from a diversity of sources, not just the web. HTML/CSS developers usually make poor designers because the more experience they have with HTML, the more practical their designs become. This is another source of the conflict: the developers can feel like the designers are punishing them by building designs that have drop-shadows over gradients, multiple different homepages load at random, as well as many other interesting and creative ideas that become difficult to translate into a syntax.

The conflict can get even more heated with a looming deadline. With a few pen strokes on a Wacom tablet, huge swaths of functionality can be added to a project. Suddenly there are light boxes everywhere, stylized tooltips, special buttons, a different width for the left column on every page, and the list goes on. Digesting a PSD is a daunting task and the natural process of design approvals ensures that each page will be *slightly* inconsistent. And of course, the design needs to be ready by next week so that the back-end team can take over.

It is extremely difficult (and not always desirable) for the designer to fully consider the development implications of a specific design. The developer is also faced with the fact that they are going to need to get elbow deep in the design, inspect it with a fine tooth comb—often zoomed to 1600%—and do it fast. This can get vicious for both sides.

Designers can develop too!
First, any designer that knows the most basic of the HTML/CSS rules will already bring something special to the table. Web designers should familiarize themselves with the basic rules of HTML/CSS and interactive elements in Javascript. What bugs exist in IE6 and IE7? What are the difficulties that come with lightbox that covers a flash element? Will my developer be able to implement an ajax image gallery if he has 6 HTML pages to build in a week? With basic HTML skills, the designer can not only create beautiful designs for the web but also determine the best way to create web beauty and developer friendly designs.

Developers can be designers too!
This one is huge. Get a front-end developer into the project life cycle earlier. Get them in on the design reviews, interactive design reviews, introduce them to the project timeline, the client, and the designer. This will allow the designer and developer to communicate with each other and gain a better sense of the difficulties of both sides. Letting developers become part of the design process allows them to gain respect from the designers for knowing what visual hierarchy is just as the developers are impressed by the designer for knowing about the double-margin bug in IE. It’s important to remember that most front-end developers went to school for web design not a degree in HTML/CSS.

Module design/development
In college a web designer friend of mine introduced me to a design methodology that he practiced that completely inspired me and has since become my primary way of development. When designing, he first determines the layout of the site (Right sash, left sash, 3 col, etc), the color scheme, and builds a logo. From here he designs all of the sites standard elements. This includes h1 - h4, paragraph text, links, link hovers, ordered and unordered lists, blockquotes, tables, numbers, drop caps, forms, buttons, any elements that the site will need. Then he designs by element in a modular way. He will take the header box and start designing only the header. He will add his login form, his logo, anything he wants to go in the header. He will not touch the navigation, the body, the footer, nothing else on the page until his header is complete. Then he moves to another element, and one after another he puts together a page. This is now how I develop. Build a navigation (or whichever element is ready to develop) in HTML/CSS/Javascript, test in all browsers, then copy/paste into the main site layout. This allows me to complete element by element and keep them all separate not only in my html but on my stylesheet. Everything remains completely organized, consistently cross browser compatible, and easily replicable.

A strong bond between the designer and the developer can create an extremely efficient development cycle using this type of methodology. There is always an offset between what the designer is designing and what the developer is developing. We obviously can’t be developing the footer until the designs are complete. The idea of modular development reduces the offset. If both the designer and developer can move from element to element, both teams can nearly work in unison.

At SolutionSet—time permitting—we produce style guides after we’ve had the initial designs approved by the client. Style guides essentially distills the Photoshop document into its base elements. There will be a page describing the grid, a page listing out all of the header styles, and so on. This is also a positive step in the direction towards modular design. Style guides help catch funny situations like having 25 different header styles on a site. In general, the style guide records the intent of the designer much better than the raw PSD’s. A designer under a time crunch can make minuscule mistakes (most frustratingly page to page) that aren’t noticeable to the naked eye but make a big difference in the CSS.

There’s always ways to improve a process. The biggest challenge is trying to make common practice out of something that is constantly changing. Every project is unique, every design will be completely original, new browsers will launch. It’s a tough world to keep up with. We shall see if some of these new ides bring anything to light. If you have other ideas, please contribute.

We attended a webinar today, with the scary (but motivating) title “Get Ready For Combat This Holiday Season - Winning The Battle For Market Share In A Ruthless Economy”. Sucharita Mulpuru, Principal Analyst at Forrester Research doled out some recommendations for getting your eCommerce act together for holiday ‘09.

These included:

Site Experience - Your site availability should be above 99% (during 2008 holiday season, the average hovered around 96%), key content should load in 3 seconds or less, language should be the language that the consumer uses (not internal widget-focused language, as good as that might make you feel), and “add to cart buttons” should be prominently displayed. In summary, your site should be available, fast and easily understood by the shopper. Sounds like a no-brainer, but how many times have you been flummoxed by looking for the “add to cart” button?

Shipping - We can’t really talk about online holiday shopping without talking about shipping, right? According the Ms. Mulpuru’s data, shipping is one of the biggest cues for consumers, highly correlated with conversion rate. And the prediction is: this year more than ever, since consumers are going to be extremely concerned about value. So get that shipping cost down, even if it means raising the cost of products to offset the cost of shipping. Further, expose the cost of shipping early and often in the shopper’s session. One of the biggest reasons for shopping cart abandonment is “surprises” at the end, like shipping costs.

Check-Out Experience - With shopping cart abandon rate 50% and higher, there’s lots of room for improvement. A good recommendation: test your check-out flow i.e. single screen check-out vs. multiple-screen. If you’re a regular reader of this blog, then you know we’re gigantic fans of “data not assumptions”, so get your test on while you still have time to optimize before the holidays.

While we’re all basking in the afterglow of the Memorial Day weekend, it may seem too early to get started on holiday site planning. But it is never too early to implement tests, check your basics, and make a plan for improving on them. Any one of the three things above could eat up most of your time between now and the start of the holiday shopping season in October.

In my last post I mentioned that we were planning on using Silverback combined with screen sharing software for our next round of usability research. Well, to follow-up, the testing went really well. We set up one conference room for the moderator, which included a MacBook pro with an additional external webcam and Silverback, Skype, and GoToMeeting software installed. Then in a second ‘observation’ conference room we set up a PC and large screen monitor with Skype and GoToMeeting. With this set up the observers could see the participant’s facial expressions via video from the external webcam on Skype and their screen interactions via GoToMeeting. In fact the setup could allow clients to real-time remotely view the sessions. In addition, Silverback installed on the moderator laptop captures picture-in-picture video and screen interactions. Of course, you could use Morae by TechSmith, which allows for remote viewing and robust video editing, but that comes at a price and the whole idea was to provide our client with the best bang for their buck!

We always loved show and tell when we were a wee one. Showing off our Barbie collection, or our jar of fireflies, or the souvenir snow globe from the family vacation was always so exciting.

And you know what? It still is, that is If you think selling more stuff is exciting. And you wouldn’t be reading our blog if you didn’t…

Well, at least one company has proven that show ‘n tell works. Can’t argue with an increase of 35% in conversions!

Our colleagues in our digital group have a point-of-view on website usability research, and some innovative thinking on the topic. Check it out here.

Postal addresses are one of the most basic form elements we encounter on the web and not much has been done to change the way they appear on a form since their inception. For most cases this format is functional, but it leaves much to be desired in the way of usability. Their layout is one of the remnants of the offline world that was not fully thought out when ported into the web.

Let’s look at how addresses are formatted in the United States:

Address line 1
Address line 2
City:
State:
Zip/Postal Code

When thinking web, a more usable layout would be to ask for the ZIP code before the state and pre-populate the state based on the ZIP code entered by the user. Ideally it  would have been nice to ask for the ZIP before the city, and then populate both the city and state fields for the user based on the ZIP, but there are some rare instances where a ZIP code can span multiple counties and therefore this does not work.

E.G.:

Source: http://www.zipinfo.com/products/cz/cz.htm

So we face a very common argument. Familiarity with what you are used to versus making the user’s online life easier. Is it worth changing this layout (i.e.: bringing the zip up above the state) to make this form more usable vs. keeping it in this format that everyone is already familiar with and therefore is usable due to familiarity? It is my opinion that the confusion caused by introducing a few approach here outweighs the improvement to the forms usability, so I would keep the traditional format.

It is when you start to make your address form compatible with international addresses that we start to encounter a real need to re-think how the form is presented to the user.

Some countries have addresses that need three address lines versus the two fields that is commonly used in the United States. The United States is one of the few countries that uses state and ZIP. Most others use province and postal code. While it is possible to list the states within the United States in a drop-down, is not possible to do the same for all the countries in the world.

Some sites overcome this problem by having just one input field labeled “State/Province.” While this works, it is not the most user-friendly.

One variation of satisfying both US and International addresses

An input field for the state causes quite a bit of confusion for the user. What does the site expect them to enter? Should they spell the entire state out? Should they enter the two character abbreviation? Will the system accept their entry if they make a spelling mistake or don’t enter it exactly as it’s programmed to accept?

In a traditional address format, the country comes last. This is the root of all our address formatting woes. The country tells us how the rest of the address fields should be formatted and therefore it makes sense to gather this information early on.

I’ve started advocating the collecting of the country early on for addresses in my wireframes and I find that once clients overcome their initial surprise of being asked for the country first they really like how it simplifies their interaction with the rest of the form.

The default selection will be the country of primary focus or where your primary user base is located with the form containing fields for that country. If the user changes the country selection to something else, the rest of the address fields can very easily be changed by either using AJAX or if needed a page refresh, to match the requirements of the selected country. One thing to keep in mind when doing a page refresh is that you should never lose information that a user might have already entered into the form. This is a golden usability rule that when ignored leaves you with some very unhappy users.

In most cases you will not need to have more than two variations to the address field, one that satisfies an international address format and one that satisfies US and Canadian address formats.
Eg:

Proposed US address format

How the form would look when an international address is selected