Case: 7 UX Considerations When Designing Lens Hawk

Lens Hawk is a DSLR lens database.

As a user experience case study I will go over 7 UX considerations we had when designing Lens Hawk - a massive DSLR lens database we’ve created as a side project.

Besides the case specific UX considerations themselves I’ll try to extrapolate the mechanisms beyond the DSLR lens context.

1) Don’t assume the user will remember technical details

People rarely remember technical specifications, they most likely just know the name and model of their device.

I know my camera’s name and that’s about it. I don’t know about CMOS sizes (ASP-C, full frame, Foveon, and so on.), or whether my camera got a built-in auto-focus motor, or have a “K-mount”.

Peoples lives don’t revolve around technical details, so don’t expect them to remember technical specifications, much less understand them. So if possible, create a database of critical filtering specifications and manage all these technical details “behind-the-scenes” and then let the user simply do a name-based lookup. People are much more likely to know the name or model of their product, than one of its technical specifications.

The examples of this technique are endless. At Lens Hawk we’ve created a list of all camera models and their compability details, that way when a user selects his camera the list automatically remove all lenses that are incompatible, due to e.g. CMOZ size, mount type or required AF motor.

Another example would be an e-commerce site specialized in selling motor oil; instead of asking for the manufacturer required oil type, simply ask the customer for their car model, and then show all compatible motor oil.

The obvious downside is the time consumed by creating and maintaining an accurate database of compatibility - but the significant increase in user experience will retain a lot of users that would have otherwise abandoned the process.

2) Auto-complete with partial matching

Partial matching will show results if the search terms are included in the name in any shape or form.

A year ago I wrote a post on when to use drop-down lists (and when not to) based on our usability tests from the checkout study. In essence, when the list is above 15 options the user experience starts to suffer.

Since we have some 130 DSLR camera models, the drop down would obviously be massive - so an auto-complete text field with loose partial matching is an obvious improvement (more on this technique in a future blog post).

3) Deliver results instantly

The most important user experience improvement of instant search results isn’t the waiting time that is reduced by a few seconds. It’s that the search process becomes iterative.

When the results are live the users can see the direct impact of each of the details in their search/filtering. At Lens Hawk, live results were crucial because the users could immediately see the impact on e.g. price when they demand a faster lens.

This means the process becomes iterative and accommodates the user’s decision process, as she decides on her personal sweet spot between price and features / quality.

4) Both mouse and tab interaction possible

Sliders with input fields for the selected values allow for both mouse and keyboard interaction.

Most users prefer interacting with mouse, but when faced with input fields some of the more savvy internet users will prefer the speed of tabbing through the input fields instead. Here we allowed for both types by also having the slider values as text boxes.

If you have input fields in multiple columns, or even content next to input fields, remember to go over the tabbing sequence to make sure it’s logical.

5) Logarithmic sliders for focal length

A logarithmic slider often makes more sense when the results aren’t distributed evenly across the given range.

The focal length for all the lenses range from 4mm to 800mm. But out of the 560 lenses in total, only 36 is above 400mm. This effectively means a normal linear slider is useless, because over 50% of it’s width is used for less than 7% of the results.

A logarithmic slider is the answer here, as it distributes the sliders’ precision to better match the most common results. (Coincidentally Dimtry Fadeyev at UsabilityPost posted about logarithmic sliders the other day.)

In general you should consider a logarithmic slider for all inputs where the results aren’t distributed in a somewhat linear manner across the entire range.

6) Combine filtering and sorting of multiple specifications

If you can filter by certain attributes, you should be able to sort by them as well.

Filtering is great at removing all the irrelevant options. Sorting is great at prioritizing all the relevant results after your most important criteria.

On most lists, the only parameters you can sort on are price and popularity (and sometimes relevance). However, allowing people to sort by all parameters that they can also filter on, gives the user endless more opportunities to leave out a filtering option if ever in doubt, and simply sort by it instead.

7) Loading time explanation

Load time is a bore, so make sure you explain the benefits of the wait.

Initial load time sucks and users hate it. One obvious drawback of live sorting is that it typically requires the user to preload a lot of data.

But you can do a bit to soothe the user experience (besides obviously reducing the actual loadtime), by explaining to the user why he is waiting or how long he has to wait. In this case we went on to describe how much data is being preloaded and also added a spinner to visually show that the browser is still responding.

When you have reduced the actual load time another possibility is to reduce the perceived load time. On Lens Hawk this is partly done by showing the sidebar option before the loading starts. By showing some of the page elements while the user is waiting for the list to load you provide the user with a glimpse of what they’ll get if they stay and wait.