A place to track your key accounts, property and financials for your executor
We introduced a new document generation feature, the first since Willful's inception
Our biggest cross-functional project to date, we coordinated our release with customer service, marketing and business development teams
We introduced key design patterns with this feature build which would solve usability issues in our core flow
In the 3 months post-release, 1 in 6 users adopted and used our new feature and 16% of unpaid users also completed payment as their next action
Willful’s core product, a legally-valid online will generation tool, does not include a list of assets that a person owns. While a list of assets is not needed for a will to be legally valid, it is a useful tool for an executor when it comes to closing up an estate, helping offset a lot of the burden of tracking down a person's property.
Adding an asset list feature to our app posed an interesting challenge to our app architecture. Everything we had built up to this point supported a single flow which generated will and power of attorney documents. We now had to consider how our app could support generating a new document, how this would integrate into a user's journey and where would it live within our app.
Determine when should users build their asset list
We had an idea that this new document creation process should not disrupt our core will creation flow, we wanted to explore where in a user's journey made the most sense for them to create this document. We also wanted to consider where in our app architecture it should live and what needed to change. Not negatively affecting our current conversion rate was an important metric for us going into this project.
Explore how we package asset list
We had parallel product strategy work to do on how we package this product — is this an add-on item or included in our existing plans? Do users need to pay before they access this feature?
Ensure our MVP is comprehensive enough for executors
As we are not experts in what executors need, we needed to comprehensively define our MVP ensuring it meets the minimum requirements for executors when they administer an estate. Determine what is necessary and what are nice-to-haves.
Our COO Julia and our PM Sarah did the heavy lifting in scoping out this project, Julia leading the initial pricing and willingness-to-pay research, supported by Sarah and building the project business case. I was involved in a consultation role throughout and facilitated the prioritization of this project as a member of the leadership team and product team.
After we green-lit this project, I supported our PM (Sarah) with the business requirements and built a project plan to coordinate design efforts over a 3-month project deadline to meet quarterly goals. This included research, customer interviews, prototyping, usability testing, final visual design and QA.
Sarah and I paired together on the initial research and I led the design and validation efforts for the rest of the project activities.
Through various customer service touchpoints, we have learned that many Willful customers are surprised that we currently do not allow them to provide asset information on our platform.
When we looked at our customer support data in the 12 months leading up to this project, we found that one in three customer phone calls lists a request for asset list support in some form. In addition, we learned that the ability to list assets was the most frequently asked-for feature associated with low NPS scores. On the B2B side of the business, we have also heard from existing and prospective partners about the importance of this feature and lost sales as a result.
Prior to kicking off this project, our co-founder, Kevin, facilitated a series of interviews with experienced and inexperienced executors (4 of each). We wanted to learn about their knowledge and experience of being an executor and uncover opportunities. I was able to sit in on and observe some of these interviews.
What we learned was that experienced and former executors were really aware of the magnitude of the role and planned ahead, gathering the information they needed right away and also seeking out professional help. Inexperienced executors, however, typically did not plan ahead and mostly underestimated the time and effort involved. We discovered opportunities to help get executors prepared for the task ahead, this included what to look for when choosing an executor, checklists of what to do and when and gathering lists of assets.
A useful exercise I like to do when kicking off larger projects is to define our problem statement by answering the 5 Ws—who is experiencing the problem, what is the problem that needs to be solved, where is the problem happening, when does the problem occur and why do we need to address this problem. With this approach, the team can align on a lean user-centred opportunity statement and we get in to discovery and problem-solving.
After gathering initial business requirements and project goals, our first stop was to learn about what the process was like for executors who had to close up estates and what resources were out there to support them. We wanted to get a sense of what assets we should account for and what detail of content executors needed from an asset list.
I advised on our initial strategy of gathering resources provided to executors from banks and insurance companies in Canada and then playing the role of the executor by setting up consultation calls with estate planning representatives at these large companies to really learn about this process from a user's perspective.
Now that we had a pin in the type of content we needed to support, we began conducting some lean competitive analysis. We had prior knowledge of some of our competitors supporting an asset list feature so now we could take a more informed look at how they supported this. We wanted to observe where in their flows this was presented to users, what type of content was captured and how this product was packaged.
We also looked at out-of-category competitors through the lens of supporting ancillary products adjacent to their core products. This helped when considering our architecture, repackaging strategy and user experience.
With a rough list of categories and subcategories, we felt that we should support, we got started on design exploration. Before I went too far, I wanted to speak with a select list of users who had reached out to customer service requesting an asset list feature. This was a great opportunity to learn about what they wanted from this feature, where in the process they would expect to use it, how often they would update, and so on.
I conducted a round of user interviews which involved usage and willingness to pay questions, an asset-type open card sorting exercise as well as first-click and tree testing to learn about where they think it should live. We also got some early design feedback on low-fidelity prototypes of our in-flow or out-of-flow exploration.
For our card sorting exercise, we asked users to choose from a predefined list of asset types and sort into categories that they would name themselves. We asked users to list any asset types we had missed themselves.
This exercise gave us insight into what assets each user would want to list and what assets they would be less likely to list. Our category buckets aligned closely with our participant's suggestions so we were confident to move forward.
From the first round of tests, we could see that our user group found real value in this feature and we had confidence in our MVP list of assets and categories that we would like to support for our MVP release. Feedback from our prototypes indicated that we needed to branch out the asset list from our core flow and focus on providing clear guidance and education.
On the leadership and product strategy side, we had determined that while we have good data to sell asset list separately, we opted to bundle it with our Premium plans to support a future price increase and in the short term, upgrade tension with our Essentials plan.
With these updates in mind, I facilitated a site mapping exercise with the project stakeholders to garner alignment on how our product architecture would scale, accounting for future projects in our roadmap as well.
Taking the new sitemap into design exploration, it was clear we needed to support multiple navigation options. Our existing navigation surfaced our core links (Dashboard, Documents and Appointees) at the top left next to the Willful logo. This was our preferred approach from an accessibility point of view, but we needed to account for at least two more links in the near future.
We created a new “plan” navigation which would support and contain all the products available to users under that plan. As documents are our end product, we wanted to keep this as a top-level nav item.
Returning users who signed back into their account would previously be taken directly to a will overview dashboard. With the addition of the asset list feature, I explored changing the current will overview landing page to a product switcher landing page to help returning users discover this new feature. This new landing page would give us a platform for other products, features and updates we wanted to highlight.
Since user interaction would be on a single page and not a flow, we needed a new design pattern that would work well for this interaction. I designed an interactive modal containing the inputs and forms needed for adding content blocks to a page.
The introduction of mini-forms (as we termed it) would also help address product debt and improve usability in other areas of the app. This was part of a longer-term effort to replace legacy design patterns that had been implemented before my time.
With flows for new and existing users explored, I set up a second round of testing with 5 non-Willful users that aligned with our primary persona (Sarah). We chose to recruit users who do not have a will and are new to the will creation experience and they would play the role of new and returning users to test our flows.
We had assumed there would be some knowledge and usability issues, especially for new users, so I documented our hypotheses ahead of the sessions.
Our main objectives for this second round of testing were to evaluate the discoverability of the asset list as a new user onboarding, mid-flow and as a returning user. We wanted feedback on our navigation update, our product switcher and on the process of building an asset list. We developed 6 task-based scenarios for users to undertake:
—
Onboard to our platform
—
Select a plan
—
Discover your asset list and sign back in
—
Complete your asset list
—
Explore and remove an item
—
View your asset list
As discussed during product strategy discussions, our benchmark for successfully de-risking projects is 80% confidence or higher. Less than 80% means iterations and another round of testing. We were satisfied that we passed the 80% threshold and that we would monitor discovery and nav updates in production using Amplitude funnels. Other points of feedback presented opportunities to improve education in onboarding, form content and supplementary articles as well as some visual design polish.
Moving into final visual design, the main improvements we needed to make were adding more guidance and education along with some visual design polish.
We added an onboarding screen to explain the value and use of an asset list for your executor. This would be shown to first time users that haven’t listed any assets yet. We also worked with the Marketing department to create knowledge articles related to asset list and we added those to the right side column of the asset list page. On the mini-forms themselves we added inline guidance to specific questions and provided warnings to users about adding sensitive information.
Feedback from usability testing indicated that users needed more contextual guidance to ensure they do not enter any sensitive information in their asset list. We added inline warning content to educated users about what type of content was required.
One of the more exciting parts of this feature build is that we had the opportunity to redesign our documents, including a new cover page and layout for the asset list content. We added anchor links to our documents page to help discoverability and clearly delineated between a user's legal documents and supportive documents.
New components and layouts were delivered in our for responsive breakpoints along with detailed specifications for interaction and motion. This included our new navigation, mini-forms, category cards and layouts for each new screen.
The launch of our asset list feature was a major success. Along with providing a heavily sought-after feature for our users, we made some major improvements to our design patterns and design system. A big point of congratulations was owed to the engineering team who built new document generation code, a first for the current team at Wilful. Along with the successful launch, we were able to collect the following analytics in the 3 months following the release:
—
934 documents created with an average of 7.7 assets listed
—
31% of users choose asset list from the product switcher after signing back in
—
2.3% increase in conversion after users use asset list
—
45% of unpaid users who add an asset, complete checkout
—
1 in 6 users that have plans with asset list available have (listed assets and) downloaded their asset list document
—
16% of users who add an asset, complete checkout as their next action
Systemizing design at scale for the largest sporting goods retailer in the United States