Over the years, FamilySearch has conducted contextual research of multiple markets and has noticed a unique challenge for the beginner.

Though powerful, the process of studying one’s family history is a rigorous process. It requires research skills, analysis of historical records and synthesis of that information to connect the dots.

For hobbyists like our active user base, the FamilySearch toolbox is one of the most robust in the industry, however it is anything but beginner friendly. It takes a large investment of time to understand how the software works and the tools don’t do a good job of helping the user intuit their purpose. Because of this it takes a lot of time and effort for a user get to the value of the product.

The research team at FamilySearch interviewed several “beginner” users to find out what they “hired” FamilySearch to accomplish. 

Users of family history software feel a sense of peace and belonging when they understand where they came from. They hire these types of tools to learn facts and stories about their ancestors, ultimately they want to find out who their ancestors were and discover how they are connected.  To do this they go through the process of piecing together family narratives, and preserve artifacts like marriage certificates and photos. 

Because of this desire to know more about their family, acquisition of new user is not the issue. People that are interested, come in flocks, and are willing to create an account, if they think they might be able to find some missing information.

To give you an idea, the current weekly sign up rate for a FamilySearch account is enough to fill a collegiate football stadium.

In a beginner intent survey, we learned that only 15% of users return the following month after sign up. After 12 months, less than 3% return.

Caden Damiano – UX Designer

He collaborated with Denis on early conceptual strategy and the crafting the UE, early flows and user testing.

Denis Modugno – UX Designer

Denis was involved in early competitive research and was lead on this project. He worked on designing initial mocks based on our work. 

Ryan Parker – Product Manager

Owner of the project.

Based on the above research and what the FamilySearch team learned in the last few years, we came to the conclusion that, in order to retain people and give them what we were hired for, the best way was to help our users to build their "FamilyTree" starting from a known ancestor, instead of themselves. This process would hopefully make them want to come back over and over again.

Our first approach to solve this problem, resulted in a two-day pow-ow (that internally we call "Hackaton") where a group of designers and managers, closed themselves in a room and tried to come up with a quick and simple low fidelity prototype, to prove the concept and start testing with users.

After presenting our "Hackaton" to few stake holders, we realized that, even though our first attempt at solving the problem had potential, there were things that we needed to think through more thoroughly, if we wanted the organization to pay attention to our proposal.

Our first task was to audit the original hackathon concept. To get away from a UI,and think more about the process, we created a rough flow that audited our hackathon solution. From there we took our flow to the product design architect in charge of the whole overarching experience of the FamilySearch site, and he red teamed our concept on a whiteboard identifying friction points we hadn’t considered.

We took the learnings from our meeting and went back to the drawing board to refine the flow. When we came out with a solution that we thought was good enough, we ran it again by the product architect, to see if we missed anything.

Notice the decrease in red marker? We felt good about it too.

The product design architect brought up some interesting questions. Like how we would be able to bring people back if they left mid-flow? Would we send them an email, Facebook message, or text? What happens if they don’t know anything but the name of their great-grandfather? What would the experience look like if they wanted to build up instead of backward? How do we segment the users for either experience?

We did the best we could to work out these questions and came up with a refined user flow that aimed to address any contingencies that the product design architect brought up.

Now that we had a thorough understanding of the concept, we wanted to use a contextual design tool called a User Environment (UE) to better craft the onboarding flow.

We chunked the app into ‘focus areas” to see the logical flow of our designs. Think of it like designing a choose your own adventure novel.

A user environment forces you to challenge the logic and intentions of placing certain components at different parts of the app. The end result is that we have a blueprint of the experience without being bothered with visual design and interactions.

Denis (red shirt) acted as the computer, changing the screens as we asked questions and drove the user interview. 

The whole methodology of a logical prototype is to test how the target users use mental models to navigate conceptual tasks. Since there is no UI, the users need to rely on their own understanding of family history (or the lack thereof), to help themselves use our prototype. This allows us to see if we need to include more contextual help in the experience.

What we learned during user testing is that a novice in the field of genealogy is curious about not just their ancestors, but moving laterally as well, looking at aunts and uncles and seeing the various branches of interesting family members. 

The interesting thing about testing is that the logical flow of the prototype made sense to the user. Without UI, they only needed only a little bit of context to navigate our post-it notes and complete a task. 

This means that their mental models of how a family is structured follow our conceptual assumptions of how someone can start recording their family research backwards. 

We validated our assumption. They desire the freedom to explore, whether that is starting further back, moving sideways or going up.

Currently, we only allow the user to build up. That’s it!

With our new discoveries, we went to our product design architect once more, to show him what we had. He then looked at it and said, “Chinese is trying to do the same thing”.

At the same time, we were crafting the UE, the product design architect was auditing all efforts in the organization to create a tree building experience.

In his work, he noticed that the dedicated Chinese team was designing a similar solution that allows a Chinese user to go backward because of their unique perspective on genealogy.

Chinese people think of genealogy as starting with the past and going forward in time to the current generation. Westerners see it as going back in time.

So to accommodate that perception of family, the Chinese team was creating a backward experience as well. 

So we stopped designing and started to align our efforts with the Chinese teams.

FamilySearch at the time was actually putting more resources into figuring out the Chinese market, so I was assigned to help with the Chinese tree view and help the Chinese get their designs in time for development.

Denis and I looked at what we were working on and we proposed that instead of creating an entirely different Chinese experience, we should merge what we have there into our current portrait tree view so we can have the backward tree building functionality while allowing for a more accessible experience for Chinese patrons.

After some meeting proposing the idea, stakeholders agreed that the two should be combined. Below is a mock made by Chinese team designer Christine of all our combined work. 

There are many conceptual considerations when designing a complex software feature. Even though we had buy-in from stakeholders, the current technology stack did not support the proposed feature set.

So to be nice to developers, we really had to thoroughly think out a feasible solution that would justify a change in architecture. So put the user first, but design the solutions so well that an engineer doesn’t cringe when implementation time comes around.

This is an ongoing project, we will update it as it develops.