Evaluating and redesiging navigation to address churn
With an understanding that users find Buildertrend overwhelming and confusing, our team felt like navigation could play a role. We set out to evaluate the current navigation and explore new options.
Role: User Interviewer/Tester, Prototyper
Year: 2023
Collaborators: Than Sidwell, Matt Donovan, Layne Russell
Duration: ≈ 1 month
One of the top reasons users cite when canceling their Buildertrend subscription is that they feel overwhelmed trying to learn the software. Several contributing factors overwhelm software users: complex interfaces, too much information, unfocused notifications, etc. In Buildertrend's case, our team felt like navigation and how we present features could play a role.
While approaching this project, our team faced a problem-framing obstacle: Users aren't going to explicitly make the connection that the navigation, or how we're presenting a set of 32 different features, is overwhelming them.
To build the case for updating Buildertrend's navigation, we needed to collect an array of information that points to why the current navigation is a problem for users. Hopefully, that evidence, in addition to ideas for how we could improve, would be enough to garner the support we needed to improve the experience.
Problems with existing navigation
Problem A: Categorization
Because Buildertrend is a tool used to manage all aspects of a residential construction project, the current top-level navigation organizes the existing feature set into seemingly reasonable categories: sales, project management, file management, and financials. However, our research team's analysis of card sorting activities showed that, in reality, this straightforward indexing of features doesn't meet the expectations of many of our users.
At the recommended 60% agreement threshold, Buildertrend users could not find a consensus on organizing the application feature set into a reasonable number of categories. For example, consider the problem of deciding which category the estimating feature belongs to; some builders feel this is a sales feature, while others think it is a financial one.
A dendrogram of the card sorting results showed it was difficult for users to agree on what groups certain features belong to.
Problem B: Feature usage
The presentation of feature options isn't reflective of user behavior.
We learned from feature usage data that the average user only uses four features. Knowing this made our team wonder: do users need all of the features a click away at all times?
Problem C: Job menu
The "job menu," a key navigation component, is used to filter jobs. There are two core problems with the job menu.
1. It doesn't look like a filter, resulting in users wondering what it's used for.
2. Relative to how often users change jobs (not very often), it takes up an excessive amount of screen real estate.
Clear hierarchy
The layout of the current navigation prioritized the job menu, but data showed that users change features more often than they change jobs, so we shifted feature navigation to the left side of the screen, aligning the navigation with what's important to users.
By building the new feature navigation so that it expands on hover, we afforded the most screen real estate to what we know is most important to users: their workspace.
Matching the user's mental model
Because we filled the space where the job menu previously was with the updated feature navigation, we redesigned the job menu as a dropdown and positioned it in the top left of the screen. Functionally, the job menu is a filter, so matching its UI to standard conventions helped users understand its purpose more efficiently.
Inject personalization and allow customization
Buildertrend covers a broad scope of the construction management experience, and its users have various needs depending on their context. We learned from user data that the average user only uses four features. With this data in mind, we designed the new sidebar navigation to present users with a limited feature set. Because no users use the same set of features, we designed the experience to provide users with the option to customize their navigation.
With a limited feature set, we felt that some level of personalization in the navigation would also be helpful. Using usage data, we have the ability to personalize each user's navigation by surfacing recently used features at the bottom of their feature list. Providing users with what they need when they don't necessarily expect it is a great way to manufacture "aha" moments and increase user satisfaction.
Evaluating proposed solutions
By user-testing the proposed navigation against the current navigation, we validated that the proposed navigation would create a more efficient, intuitive, and ultimately less overwhelming experience.
We created prototypes of both experiences and had ten users complete tasks using Buildertrend's current navigation, and another ten users completed the same tasks using the redesigned navigation. In doing so, we landed on a few key takeaways.
User testing takeaways
• We ended each test by asking the users to complete a SUS survey. Users of the existing navigation averaged 84.24/100, while users of the proposed navigation averaged 96/100, an increase of 11.76 points.
• Using the proposed navigation, users could navigate to any feature 3.6 seconds faster on average. Moreover, users could navigate to features in the sidebar defaults at a rate of 6.5 seconds faster on average.
• Changing the job menu to a dropdown filter resulted in an 8.5-second decrease (from 23 to 14.5) in users' time to change jobs.
Presenting the results
We presented these results to leaders throughout our product organization. The response to this proposal was lukewarm. We aligned some stakeholders on the problem and received positive feedback on our proposed solution. Still, ultimately, a shift in priorities within the organization led to the deprioritization of any changes to navigation for now.
Though this work was deprioritized, I walked away with a few valuable takeaways. For one, I learned that it's difficult to prove that something as nebulous as navigation is a problem contributing to churn.
I also walked away feeling like our team did a satisfactory job in pointing out problems with the current navigation, and improving the current navigation experience with our proposed solution, but we struggled to illustrate precisely how the current navigation was negatively effecting churn. How we connect those dots is something I'm still grappling with (if you have a perspective on this, I would love to hear it!).
I believe that if and when the time comes to tackle this problem, we'll have good ideas to work from.
