I was recently assigned to Family Name Assist, a tool designed to help new members find a family name to take to the temple. My initial assignment was to design and implement a new feature: adding great-grandparents to the experience.
But as I started exploring the product, it became clear that the issue wasn’t just about missing functionality. Data, workflows, and policy dependencies all pointed to a deeper problem: Family Name Assist wasn’t meeting its intended goal.
This case study shares my early process of questioning assumptions and reframing the challenge to ensure we’re solving the right problem — not just adding another feature.
For many new members, taking a name to the temple is a meaningful first step in their spiritual journey — it’s important that the experience feels simple and confidence-building. Family Name Assist was created to help newly baptized members take a family name to the temple quickly and confidently.
Recently, I was asked to design a new feature that would allow members to include great-grandparents in the experience. At first, this seemed like a straightforward request — but early data and policy reviews told a different story.
Usage data from similar FamilySearch tools showed that grandparents are taken to the temple 77% more often than great-grandparents. At the same time, adding great-grandparents would trigger a 3–6-month approval process for living-relative permissions — potentially slowing the experience instead of improving it.
Leaders also cited the lack of great-grandparents as a key reason for low adoption, even though existing metrics suggest otherwise.
These findings raised an important question:
“If Family Name Assist isn’t meeting its intended goal, will adding more functionality actually solve the problem — or simply make it harder to use?”
Family Name Assist is meant to simplify what can be an emotional and spiritual first experience for new members. While the interface succeeds in making the process simple, the system surrounding the product—policies, assumptions, and usage patterns—doesn’t fully support that intent.
The tool is being used primarily by leaders to assist youth, not by new members themselves—the opposite of its original goal.
Leadership feedback focuses on adding functionality, even though data shows the existing features could already meet the need if better understood.
Expanding to great-grandparents would introduce policy delays and potential confusion without addressing the underlying adoption issues.
The real challenge isn’t about missing UI elements; it’s about aligning purpose, perception, and policy so the product can achieve its mission.
Through a QA review of the current experience, I noticed that hiding the family tree to simplify the flow may actually make it harder for users to understand what’s happening.
While the interface works well, hiding the tree may blur the connection between members’ actions and family relationships. My hypothesis is that concealing too much of the process might reduce user understanding and confidence—especially for new members learning how temple work connects to family history.
This insight will guide upcoming user testing to validate whether simplicity in this case is creating clarity or confusion.
Family Name Assist’s engagement was compared to Guided Tree-Ordinances Ready serving a nearly identical audience. The results showed that members were 77% more likely to take a grandparent to the temple than a great-grandparent.
This suggested that expanding the feature set wouldn’t improve outcomes — instead, it might increase complexity while failing to address the root cause of drop-off.
As I dug deeper, several systemic dependencies surfaced that could limit the success of any future update.
Together, these findings reveal that Family Name Assist’s barriers are systemic rather than functional—a misalignment between policy, perception, and product purpose.
After synthesizing these findings, I reframed the problem from:
This reframing shifts the focus from feature design to experience strategy.
The question is no longer “What do we add?” but “What do we fix in the system so new members can succeed?”
By clarifying this, I’m helping the team pause, evaluate, and realign before investing in new functionality that may not move us closer to our goal.
This project is still in its earliest phase, but my next steps include:
Partnering with my PM to conduct interviews with leaders and new members to uncover unmet needs and verify assumptions.
Mapping the end-to-end experience — from new member onboarding to first temple visit — to identify gaps in clarity and motivation.
Collaborating with policy and engineering stakeholders to evaluate how to reduce waiting times and simplify permissions.
Testing small, lightweight improvements to the existing experience before exploring new features.
The goal isn’t just to add more functionality — it’s to restore purpose and clarity to Family Name Assist.
This project is already reinforcing one of the most important lessons in design:
The right question is more powerful than the right feature.
By slowing down and examining the system around the product, I’ve been able to help the team see that adding complexity won’t fix clarity.
These are the principles guiding how I approach early-stage, ambiguous projects:
Design starts with inquiry. Questioning assumptions early reveals root problems faster than any prototype.
Evidence builds alignment. Data helps bridge the gap between perception and reality.
Purpose drives success. A product can’t fulfill its mission until policy, experience, and workflow all support the same goal.
This story is still unfolding, but the work has already begun to create impact — not through a new feature, but through a clearer understanding of what success really looks like.