Website logo

Willful Asset List

A place to track your key accounts, property and financials for your executor

Role —
Design Director / Design lead
Duration —
3 months
Responsibilities —
Requirements research
User research
Site mapping
Product design
Usability testing
Content strategy
Highlights —

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

Background, goals and my role


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.

Above: Our existing core products (completed in a singular flow) and our proposed new product addition.

Our goals

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.

My role

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.


Examining the data

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.

Above: Some leading customer service insights gathered to support our business case and prioritization of the asset list feature.

We talked to executors

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.

Answering the 5 Ws

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.

How might we support testators post will creation to add a comprehensive list of their assets and encourage users to return to update this asset list as their estate changes.

– Our opportunity statement

Learning about the space

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.

Above: Most estate assets fall under these three categories and our research and calls with banks and insurance companies gave us a template to move forward with.
Above: Our PM Sarah refined our findings from our content research into subcategories with technical requirements for the engineering team.

Competitive analysis

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.

Above: A high-level summary of how our competitors supported an asset list as well as out-of-category ancillary product examples. We linked walkthroughs in separate Google doc presentation slide decks.


Exploration and initial user testing

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.

Above: Samples from our Useberry moderated survey and themes derived from the findings (sticky notes below).
Above: A ranked list of assets from our open card sorting exercise.

Open card sorting

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.

Iterating on the outcomes

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.

Above: Early mockups of the asset list page outside of the core will flow.

How do we package asset list as a product?

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.

Above: An updated sitemap which allocated asset list under a users plan type (instead of a separate product) and the documents page updates. We accounted for a future "Final wishes" project here as well.

Navigation rerouting

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.

Above: Our existing and updated nav menu with a dropdown with products available on a user's selected plan revealed on hover.

Product switching exploration

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.

Above: For returning users, I explored adding a product switcher landing page to help returning users discover the asset list and give us a platform for expansion.

Introducing mini-forms

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.

Above: Explorations to introduce our "mini-form" design pattern would be crucial for how we wanted users to interact with the page.

Usability testing round #2

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.

Above: Our primary persona, Sarah, who represents our high-value demographic.

Testing format

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

Above: Themes and action items from our second round of moderated usability testing. Much of the feedback focused on gaps in knowledge and discovery of the asset list feature.

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.

Education improvements

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.

Above: New and returning users would see our new product switcher when signing back in or clicking the Willful logo. Both would see our new onboarding page for their first use of the feature as well as knowledge articles on the asset list page.

Improved form education

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.

Above: Contextual warning content to ensure users do not enter sensitive information.

New document design

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.

Above: Our newly designed asset list document, found on the documents page.

Final designs for production

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.

Above: Responsive breakpoints for our asset list page.
Above: Responsive breakpoints for our new mini-form component.


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