Nick Dunn's Blog

Aligning search design with user behaviour

Sat, 24 Oct 2009 12:53:00 +0000

When it came to rebuilding the Lightbulbs Direct Ltd website in 2008, the primary aims were to get customers to products faster, and through the checkout as easily as possible. In this retrospective I will discuss the improvements we made after analysing user behaviour and grouping user journeys.

To begin, this is the original search results page from 2005 (right).

The problems with this page extend beyond its visual design:

taxonomic classification is good for search engines but user journeys comprise several consecutive pages just to narrow product choices
many users quickly reverted to complex keyword searches, either specific part numbers or ambiguous “red bulb” or “fridge door”
“Advanced Search” (personal search via a contact form) was used regularly, implying search results unsatisfactory
search results page looked visually complex, could not be easily scan-read and required a lot of scrolling for pagination
a “Buy” link directly from results page is optimistic and pushy
search results cannot be re-filtered or easily amended

Almost importantly of all there was little feedback to the user that their search keywords had been correctly interpreted. How could they be sure that the website knew their search keywords “gls 60w” actually meant “Find me 60 Watt GLS bulbs”?

During the design phase, the user journeys through product search were the main focus of my attention, with a view to solving all of the above problems. We decided on three key entry points into product search, which matched three distinct user groups of varying levels of domain knowledge. Each group would have a search journey tailored to their specific needs, aligned closely with their observed behaviour:

1. “What [XYZ] do they stock?”

These visitors know about product types (bulb, fluorescent tube, spotlight) and they are looking for a specific item of that type. This lends itself very well to the original (albeit poorly named) “Bulb Finder” concept which is essentially a taxonomic drill-down through product categories. By displaying familiar top-level category names on the home page and in an obvious place on every page, users who are familiar with the terms can use them as their entry point.

After several levels of ever-narrowing categories choices, a product listing is displayed. The information shown in the table of products was carefully chosen so that a user can decide whether the product is the right item without having to click through to a product page. In the technical world of electronics, specifications speak louder than captions and descriptions. Nevertheless a small photograph is essential for the user’s decision making process.

2. “My bulb has just blown, I need a replacement now!”

Do you know your 40W from your 60W; your pearl from your white; your Edison from your Bayonet cap? Probably not, and why should you? But imagine that your desk lamp bulb has just blown and you are holding it in your hand. There are no distinguishing marks except for a faded “60W” stamped on the clear glass. This is where the “Bulb Finder” works its magic, allowing a user to provide details up to four pieces of common information easily realised from a busted bulb: Wattage, Voltage, Cap/fitting (push-fit, screw-in) and Colour.

And instead of making this a trial-and-error process, the Bulb Finder gives live feedback as you enter the bulb details. You don’t have to click “Search” and wait for a results page to tell you how many matches there are. This serves the purpose of giving the user control as to when they view the matching products. 600 items found? Maybe you want to narrow it down a bit before jumping in at the deep end. Changes a drop down. No items found? Maybe one of your choices is incorrect, or we simply don’t have what you’re after. Changes a drop down 12 items found? It’s likely we’ve got what you want, take a look.

3. “I know exactly what I want”, or “Panic! I don’t know what I want at all!”

The keyword search satisfies a group of other broader, yet still distinct, users. Perhaps they’ve headed to the search box immediately because they don’t know what “40W Phillips” scrawled on the side of their tube means; or perhaps they’ve been browsing a little and can’t find that elusive niche item; or perhaps they know a specific manufacturer part number for a quick price comparison. Or perhaps they’re simply looking for information about “energy saving” and simply don’t want to be told to purchase something.

Everyone has their own mental model (consciously or unconsciously) of how a search works, and they supply their keywords accordingly. This means that building a good keyword search is incredibly difficult. When developing the keyword search we went to great length to ensure that it remained as flexible and useful as possible:

Converting keywords into technical parameters

Products are stored in an abstract data model similar to the entry-attribute-value pattern, allowing a product to have a specification defined by any number of attributes. However, all items have a set of default attributes comprising the four used in the Bulb Finder (Wattage, Voltage, Cap/Fitting, Colour).

The keyword search uses some complex string-parsing algorithms to translate a search phrase such as “60 WATT bc 240volt” into a product search on Wattage: 60, Cap: Bayonet, Voltage: 240. In the UI, known technical attributes are pre-selected in their respective drop downs and can easily be tweaked or removed.

Modifying search filters

If the user can not find what they want, the search needs to be easily repeatable by tweaking parameters. The attribute drop-downs provide technical clarity, but free-text keywords also need be addressed. Standard keywords are displayed in a familiar strip of tags from which the user can remove individual words if they are deemed to be reducing accuracy.

Scanning and pagination

Products are shown in a simple table, up to ten per page. The small thumbnail allows for instant recognition of more recognisable shapes/colours, and the natural-blue hyperlinked product name is an obvious call to action. Subtle zebra-striping aids scanning horizontally, while wide column spacing and consistent alignment makes vertical scanning a cinch. The total number of results is clearly labelled, and pagination is repeated at the head and foot of the table. This layout displays 2–4 more products above the 1024x768 fold compared to the previous design.

This article has shown that with careful observation of your target audience you can design page elements that are more closely aligned with their behaviour. By adopting this user-centred approach, the site is more useful to its users and becomes instantly more easy to use.

Bekonscot.co.uk redesigned

Tue, 28 Jul 2009 17:37:00 +0000

Cross-browser drop shadows using pure CSS

Sun, 19 Jul 2009 12:32:00 +0000

There’s an awful lot of noise at the moment regarding dropping IE6 and forging ahead with CSS3 properties for the finer touches on web layouts. Do websites need to look exactly the same in every browser?

One such example is adding drop shadows to content blocks. There are countless ways of achieving this, most requiring additional HTML markup and one or more PNG images. Not to mention hacks for IE6 to get render PNGs properly. All of this begins to degrade page performance, when really the drop shadow is merely a secondary design flourish.

CSS3 provides the box-shadow property to achieve just that. Thankfully Safari/Webkit has supported this for some time, and Firefox more recently with Firefox 3.5. Internet Explorer provides a DropShadow filter but this provides a hard-edged shadow unlike its CSS3 counterpart. By combining the Glow and Shadow filters however, we can achieve something that fairly closely resembles the rendered CSS3 shadow. Hurrah!

Here’s an example page and the result across major browsers:

Disadvantages

no support in Opera or Firefox pre-3.5
filters may clash if you also need to set container opacity (e.g. fading using jQuery)
the shadows aren’t exactly the same

Advantages

no additional markup, images or IE6 hacking
faster performance than rendering images (especially IE6 PNG fix)
shadow changes can be tweaked using CSS
no restriction on size — shadow grows as the content grows

Update (19 July 2009, 17:47)

As ZigPress points out in the comments the IE representation is still rather ugly.

By removing the Glow filter and using Shadow filters in its place, and reducing the weight of the shadow, we approach something more forgiving in Internet Explorer using the following CSS:

div {
    filter: 
        progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=0,strength=7)
        progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=90,strength=10)
        progid:DXImageTransform.Microsoft.Shadow(color=#dddddd,direction=180,strength=10)
        progid:DXImageTransform.Microsoft.Shadow(color=#eeeeee,direction=270,strength=7);
}

Export a CSV report from Sifter issues

Tue, 30 Jun 2009 10:51:00 +0000

The Sifter API has been a long time coming and there’s nothing on the horizon yet. I recently embarked on my own set of scripts to automate the process of creating a report from Sifter. The idea is to parse the issues HTML list into XML and then transform to whatever the user desires using XSLT (a printable HTML page, an XML file, a CSV). But I digress.

So I found a natty little update to Sifter that provides native export of your issue list as a CSV file!

Spot /issues?s=... in the URL and change it to /issues.csv?s=. Tada!

I’ll hold out for the API.

Show latest Last.fm plays on your Symphony site

Wed, 10 Jun 2009 17:46:00 +0000

At the top of my blog I have added the name of the last track scrobbled to Last.fm. Symphony made this so easy, eating a biscuit with a fresh brew after five minutes. Here’s how:

First you need a Last.fm user account, and one of the various applications to scrobble your tracks from iTunes (or Windows Media Player, if your life is broken). Then you need to grab an API key. The key will be a hash that looks something like this (note: this is not my real API key!).

3d21e002930b853d2f048e517c577ec7

You can then create a URL using the Last.fm API to return your recent tracks as XML. We will use the user.getRecentTracks method of the API. Your URL should be in this format:

http://ws.audioscrobbler.com/2.0/?method=user.getrecenttracks&user={your-username}&api_key={your-api-key}

Log in to your Symphony site and create a new Data Source, choosing “Dynamic XML” as its source. Paste your API call URL into the URL field and update the cache value to something small, between 1 and 10 minutes should do.

Note that I have also added the XPath expression //track[1] so that only the first track node is included in my Page to keep things lean.

Attach this Data Source to your Page and fire up ?debug to check you can see the fresh track node. You can? Great! I’m glad you’ve been keeping up.

All you need now is a little XSLT magic to write this content into your page. Where you want the track name to appear, add a template match to the track node above:

And neatly out of the way you can create a template to handle the rendering of the content. My template looks like this. Notice I’m checking whether the track has a nowplaying attribute and changing the label accordingly.



    
        
            Currently listening to 
        
        
            Recently listened to

How stupendously easy!

The kettle’s boiled. Time for a cuppa.