FamilySearch Developer Journey
Reducing onboarding time from 2 weeks to 2 hours.
Role
UX Designer
Timeline
July to December '24
Team
Product manager, senior designer, web developer, backend developers
End Product
New developer dashboard and associated pages
Summary
During this project, I reduced churn to the FamilySearch developer program by:
Designing a new dashboard experience for third-party developers
Conducting usability testing for the dashboard flow and all associated pages
Collaborating with developers, PMs, and designers within a product trip in an agile/scrum framework
Problem
The developer program had a 93% churn rate
Before the start of this project, the FamilySearch developer program experience consisted of disconnected web pages, confusing documentation, and a slow approval process. This resulted in a high churn rate and hours of wasted time for both FamilySearch team members and third-party developers. There was also precedence of non-developers accidentally making accounts, leading to more frustration. To make this experience better, my team and I researched, designed, and iterated until we found a solution that significantly improved the churn rate and customer satisfaction.
Desired outcome
A simplified onboarding experience featuring a new FamilySearch Developer dashboard for third party devs.
Process
Crash course in developing with APIs
To fully understand this project, I had to turn off my design brain for a bit and learn to think like a developer. I spent a couple weeks familiarizing myself with the process & terminology.
We also examined developer sites for other business, evaluating what features we might be missing and to evaluate what needs we could be missing. Finally, I coordinated frequent meetings with my PM (a former developer) to learn more about the ins-and-outs of the developer experience.
Also, my team and myself conducted interviews with developers who had experience navigating our current flow. We discovered that…
1.
Navigating through multiple sites was confusing.
2.
It could take weeks to receive API keys.
3.
Developers had to contact FamilySearch at every step.
What do the users want? (Usability testing)
Conducting research allowed my team and I to move onto flow-building, assumption testing, and a rough wireframe. I tested a rough wireframe with potential customers and learned what features we were missing.
Confusion during the onboarding process (entering the portal/the portal design didn't match expectations)
Developers were unsure when they could start building an integration
Certain parts of the flow were unfamiliar (beta vs production access, app review)
I conducted usability tests with developers who had experience in API and backend web development.
Getting feedback from designers helped me improve usability
I had gotten stuck in a rut; during testing, developers could eventually complete the task but not without some confusion. My design didn’t make sense, but developers struggled to articulate why. This is when it became vital to get feedback from other designers within FamilySearch. New perspectives helped me jumpstart a more user-friendly design.
Before getting feedback, it looked like this….
Lesson learned
Testing revealed that I had incorrect assumptions, but more testing wasn't the answer. Working with other designers helped me get other perspectives and redesign, making the site more suited to user needs.
I redesigned the flow and used continuous testing to improve
Previous iterations & research were vital to the dashboard redesign. The updated wireframe better fit user needs; instead of going through each step in order, the new design allowed the developer to navigate through information as needed.
… after getting feedback, I improved & simplified the main portal.
I returned to iterating & testing to validate my design changes
To ensure my updated design was more focused & aligned with the company needs, I spent time doing the following…
1.
Whiteboarding so I could account for any potential edge cases in the user flow.
2.
Updating the wireframe with Zion UI components & match the FamilySearch design system.
3.
Meeting with UX writers to correlate all visible text & establish correct tone/voice.
4.
Continuously interviewed developers with each design iteration to make sure I was on the right track.
A snapshot of a user test where we tested an extra-simplified version of the page (we ended up going with this version… read on to learn more!)
Simplifying the features of the portal made our users much happier
Until this point, I had worked on this design largely on my own. After my team’s senior designer returned from leave, we worked to get rid of a few small tension points. Mainly, my team's senior designer helped me understand how we could simplify even further. We made the following changes:
1.
An integration’s settings & review details were not needed for all users, so we hid those options until a user was ready.
2.
A developer's integration list was moved to its own page, allowing resource links to be moved to a more accessible location.
Testing results
During the final round of testing, 100% of the users were able to finish the flow without error (up from only ~20%).
Results
The final design increased customer satisfaction
While none of the features changed, the organization was incredibly simplified by the end of the project. By focusing on progressive disclosure, I was able to design the many complicated steps of the developer journey into easily digestible chunks. All developers and stakeholders were pleased with the results.
Reflection
Lessons learned
Taking time to do thorough research & understand the user is vital to ensuring a quality product.
Get feedback early & often to prevent unnecessary backpedaling. Collaboration is key to success.
It's easier to add features to a simplified design than to pare down a bulky design; start simple.