Across Northwestern Mutual's Client Web and Mobile experience, investment accounts, connected external accounts, and manually updated external accounts can have their values included or excluded from various calculations — Net Worth, Cash Flow, Market Value, and Investment graphs. The product used similar but inconsistent language and content patterns throughout to communicate these states, creating confusion for clients and design debt for the product team.      

This project began when a UX designer surfaced the inconsistency as a design problem and brought it to me to lead the content discovery. Once I completed the audit, mapped the current state, and developed recommendations, I handed the findings back to the designer.  

No one had mapped the full picture of how inclusion and exclusion actually worked across the experience. The same underlying concept — whether an account's value counted toward a given calculation — was expressed differently depending on where you were in the product, what type of account you had, and whether you were looking at a toggle, a checkbox, a category label, or a graph control.      

This wasn't just a content problem. The inconsistency reflected a deeper structural issue: a single toggle in Account Settings was silently controlling multiple downstream calculations, none of which were named or explained to the user. Clients had no way to know what they were actually changing.      

I led discovery across the full accounts experience — reviewing live designs in QA and client view, engineering documentation, and existing definitions. I mapped all current-state inclusion and exclusion options into Airtable, capturing account type, calculation type, and Net Worth        landing page label for each combination.      

From that mapping I built a flowchart showing the full decision logic — how account type, toggle state, and graph controls interact to determine what a client's numbers actually reflect. That diagram made the structural problems immediately visible in a way that text alone couldn't.      

I then modeled two future-state solution paths — more granular settings vs. bundled settings — building flowcharts for each to show how the complexity changed under each approach, and providing example UX writing for both. Each recommendation was mapped to its estimated engineering lift to help the team prioritize.      

• Toggle/checkbox mental model inconsistency — within the toggle, "on" means excluded; within the graph checkbox, "on" means included. Clients using both controls experienced directly contradictory behavior.
• One setting, many silent calculations — "Exclude from Net Worth" quietly controlled Net Worth total, Historical Net Worth graph, Total Market Value, and Total Value Over Time graph; none of which were disclosed to the user at the point of the setting.
• Exceptions to settings — the graph on the Investments page had a separate, temporary checkbox control that overrode the account-level toggle without saving; creating a disconnect between what clients set and what they saw.
• Disconnect between graphs and totals — accounts excluded from the Historical Total Value graph were still included in the Total Value number directly above it.
• "Excluded" used as a category, not a state — placing "Excluded" as a peer category alongside Insurance and Investment types misrepresented its nature. Excluded is a state of an account, not a type of account.
• Saving inconsistency — settings edited in the modal required saving; settings edited on the graph could not be saved at all. No consistent saving model existed across the experience.

I delivered two solution paths, each with flowcharts, example UX writing, and estimated engineering lift:      

For both paths I wrote example settings definitions — showing exactly how the toggle label, helper text, and state descriptions would change. The goal was to give the team concrete, ready-to-implement language rather than abstract recommendations.      

In practice, the team landed on a hybrid approach — bundling calculations for most users while surfacing more granular controls for power users who need them. We framed this internally as hiding complexity: designing for the common case while keeping the full picture accessible for those who want it.