Data Organization that Works Against Users: Ancestry.com Part 2

It is always tempting, when organizing search results over a variety of data sets, to organize those results by data set.  It's easy, programmatically, and to someone who is working on the system and is intimately familiar with all the databases, it makes sense.  I've seen this done in medical, industrial, insurance, and manufacturing databases.  It is very common.

It is not the best way to present search results to users, however.  Ancestry.com is working hard to prove this point.

At the moment, one of my tasks is the compilation, chronologically, of a family's service members and service records.  All of the World War II participants, all of the World War I participants, and so on.  This information is sketchy, often, so it doesn't filter up to the 'Hints' level in Ancestry.com - you have to search for it yourself.  And that's where the fun begins.

For example, here is one person - Samual Crawford of Virginia (1750-1818).  You know, by these dates, that he could have participated in the American Revolution, and was alive for the French and Indian War and the War of 1812.  Ancestry.com knows these dates too, but doesn't use them in their search results.  They instead offer me search results for the Civil War, which took place 40 years after Samuel's death. 

The Narrowing options are data types, which can be hard for the layperson to distinguish.  For example, what is the difference between a service record and a soldier roll? 

But I know that Revolutionary soldiers were often issued land warrants in payment for their service.  So I head to the pensions subsection, where I find a land warrant issued to a Samuel Crawford.  But here I make another discovery.  The data IS organized by war - the breadcrumb tells me so: "Revolutionary War > 1788 Warrants: 00001-14220 > 08600-09299 > 639" it says.  AHA, I think.  Maybe here is how I can search just the records for that war.  But no, it doesn't let me enter a search term here.  I can only browse through it by warrant number.

So not only are they presenting the data by sets that aren't meaningful, but they are in fact organizing the data in useful categories, and then preventing users from searching with those categories.  Again, it is a strange thing to exact such punishment of your subscriber and active user base, forcing them to spend longer and more frustrating time to get data you could more easily provide.

Here are the lessons to be learned:

1.  Spend time asking the questions your users are likely to ask: "Samuel Crawford was alive from 1750 to 1818.  Was he in the Revolution?" is more likely than "This man is named Samuel Crawford.  I wonder if other people named Samuel Crawford were in other wars?"

2. If you have data that can be used to narrow a search, like the dates for Samuel's life, use that data.

3. If you find a categorization useful for organizing your data, ask yourself whether that categorization would be useful for users as well.

4. Keep your presented data organization consistent, and don't present data structures that users can't access, as Ancestry.com does here: