Article overview

Case: 7 UX Considerations When Designing Lens Hawk

· By · 6 comments ·

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 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.

Why?

It’s a lot of fun to do these small projects and try out different UX approaches, and you learn a lot when actually applying them in practice.

Lens Hawk itself is still in early beta but all feedback is much appreciated, both UX and non-UX.

Mike September 9, 2011 Reply to this comment

Nice concept, though you may want to revisit the UI from an iOS perspective.

Jamie, Baymard Institute September 9, 2011 Reply to this comment

Yes, you’re absolutely right Mike.

Dedicated tablet and smartphone layouts are definitely part of our plans for future releases.

Rui Lopes September 16, 2011 Reply to this comment

So, what’s the non-usability part of the UX you mention? Why not calling ***usability*** to all of these items (instead of UX), when nothing else is discussed?

Christian, Baymard Institute September 20, 2011 Reply to this comment

Hi Rui, it depends on how you define UX. If defined this way: http://neospot.se/usability-vs-user-experience/

Usability answers the question, “Can the user accomplish their goal?” with effectiveness, efficiency, and satisfaction about the results (as per the ISO 9241-11 definition of usability). User Experience also answers the question, “Did the user have as delightful an experience as possible doing so?”. User Experience takes far more effort to do well, but the results have far better impact.

Then I’d say both #1 and #2 also falls within UX, and not just Usability.

grooves1200 July 23, 2012 Reply to this comment

cool site — what specific technology did you use to build it?

Kirill Vechtomov March 7, 2013 Reply to this comment

Hi Christian,
Great case study! Thanks for sharing this!
I am just starting to dig into UX design deeper, but I’ve been very interested in it for a while. I have several suggestions how you could improve the UX. Speaking from a subjective user perspective (I’m a passionate photo enthusiast):

I really love that it’s fast and not overloaded with details. I also love that the list is being filtered automatically depending on the camera brand, this is very cool UX. Great job!

Some things I would suggest:
1. As the main idea of those filters on the left is to change the values, I’d make the values significantly bigger (comparing to sliders). Giving it a quick look, numbers are too small, I feel I need to make a bit extra effort in reading them. Comparing them with the sliders, sliders have more visual weight, though my personal opinion – it should be the opposite.
2. While the initial list is loading, I can’t do anything on the left side, even the sliders are hidden. One of the most common use cases would be when a user knows approximately what range of focal lengths he/she is looking for (e.g. looking to get a very wide-angle range lens). So while the list was loading I was willing to spend this time adjusting the filters on the left not to waste time. This would be cool if user could set the filter while the list is loading and then, when all db has been loaded, the listing view would check the filter settings at that particular moment and show only those results.
3. I don’t see any difference between “Prime” and “Constant aperture” filters. They are doing exactly the same thing.
4. Making a typo in the “Camera” field resets the text entered making me re-type it. For example, if I enter “nikkon” and click anywhere outside of this field, the field gets reset. A bit annoying. Might be even more annoying for a user who types fast and not very accurately. My suggestion would be to leave what the user has entered and change the font color to red, if no matches found.
5. I tiny little bit confusing that Focal length field doesn’t support decimal values, only integer, though Aperture field supports decimal and there are decimal values for the focal range. Obvious example – the minimal focal length on the wide angle is shown as “4”, though in fact the minimal in your DB is 4.5mm. There are several wide-angle lenses with decimal values. Not a big deal, but I was very curious when I saw that you have a lens with 4mm focal length, as I’ve never heard about 4mm, only 4.5mm =)

Overall, very good job!

Post a comment!

Close overlay