Future of Planning
Creating a shared language for the future of financial planning
Financial planning had outgrown the system it was built on.
That's why the Wealth Planning organization partnered with the Strategy & Innovation team I was a part of to help define the future of planning.
On the surface, the challenge seemed straightforward. Planning capabilities were spread across multiple products, advisor experiences felt disconnected from self-directed experiences, and data existed in multiple places with varying levels of fidelity. The organization wanted to bring these systems together while expanding planning beyond a rigid, goal-based methodology toward something much more flexible and decision-oriented.
Everyone—including me—thought this was a product vision project.
Looking back, I'm not sure it was.
I don't think we were redesigning a planning experience.
We were redefining what planning itself meant.
A shift from retirement planning to life planning
The existing planning ecosystem had been built around retirement planning. The organization's internal silos were visible in the experience, with a clear distinction between planning independently and planning with an advisor. Customers established predefined financial goals, those goals fed into a retirement plan, and the tools supported that methodology remarkably well.
The problem wasn't that the model was broken.
The problem was that the world around it had changed.
Financial planning was becoming less about reaching a predefined retirement outcome and more about navigating an ongoing series of life decisions. Customers wanted guidance that reflected their unique circumstances rather than a collection of predetermined goal types. Our existing planning tools weren't serving everyone equally well. Self-directed customers often found them too rigid, while advisors had developed countless workarounds to accomplish common planning tasks. If the organization was going to continue investing in this ecosystem, we needed to build something that met people where they were instead of forcing them into an outdated methodology.
Planning could no longer begin and end with goals. It needed to support aspirations, decisions, tradeoffs, changing priorities, varying levels of financial maturity, and continuous collaboration between clients and advisors.
Our product partners already understood this when they engaged us.
What none of us had yet was a shared understanding of what this new planning model actually looked like.
That became the real project.
Alignment before AI
We kicked the project off with an AI-enabled design sprint.
There was understandable excitement around using AI. Some of our partners wanted to skip directly to prompting in Figma Make. Their perspective was simple:
"We already know what we're trying to build, so why spend time aligning before generating concepts?"
Experience has taught me that alignment often feels stronger than it actually is.
Looking back, insisting on slowing down here became one of the most important decisions we made. Without a shared understanding of the experience we were trying to create, AI wouldn't accelerate understanding—it would accelerate assumptions.
Instead, we spent the first day and a half building a shared foundation. Together we defined the principles the experience should embody, what success looked like, the behaviors it should and shouldn't encourage, design guardrails, AI behaviors, key user and business friction, and the hypotheses we wanted the vision to prove.
Those exercises weren't deliverables.
They became the operating system for everything that followed.
There was some initial resistance because parts of the team felt this work had already been done. Ironically, those sessions quickly proved why they were necessary. Some of the most valuable conversations of the entire project happened during alignment, as participants surfaced assumptions, uncovered gaps in understanding, and challenged each other's thinking.
We weren't simply documenting ideas.
We were building a shared mental model before asking AI to amplify it.
Creating a shared context
Rather than asking fifteen participants to independently prompt AI from scratch, we synthesized everything we'd aligned on into a single context file that became the foundation for every concept generated during the sprint.
The file contained experience principles, design guardrails, product expectations, AI behaviors, personas, and design targets.
Over the next several hours, approximately fifteen participants generated nearly thirty concepts containing more than 150 screens.
The remarkable part wasn't the volume.
It was the consistency.
Although every concept explored different ideas, they all felt like they belonged to the same product because they shared the same foundation.
This project fundamentally changed how I think about AI.
Before this project, I believed AI's greatest strength was generating ideas.
Now I think its greatest strength is expanding who gets to participate in design.
People who had never opened Figma suddenly had the ability to communicate sophisticated product ideas. Even more importantly, they could recognize their thinking reflected in the evolving prototype. In traditional design sprints, paper sketches often require interpretation before they're translated into interfaces. This time, participants could see ideas that felt much closer to the finished experience, creating a stronger sense of ownership throughout the workshop.
The breadth of exploration also surprised me. Traditional design sprints often converge around two or three recurring themes. Here, nearly every concept felt meaningfully different. AI expanded the solution space in a way I hadn't experienced before.
The AI didn't create alignment.
The people did.
The AI simply amplified it.
Designing what couldn't yet be seen
As we synthesized the strongest ideas into a single end-to-end concept, another challenge emerged.
The screens depended on concepts that didn't yet exist.
Retirement planning already had an established methodology.
Decision-based planning didn't.
It slowly became clear that we weren't extending the existing planning model—we were replacing it.
Retirement planning came with decades of shared language and methodology.
Decision-based planning didn't.
Before we could design the experience, we had to define the concepts the experience was built around.
Every conversation about the interface exposed a deeper conversation about the system.
What exactly is a decision?
How are options created?
How do multiple decisions interact?
How do they affect goals?
How do they affect a plan?
What information should AI consider before recommending any of the above?
How should planning adapt as someone's financial life becomes more sophisticated?
Before we could design interfaces, we first needed to define the system those interfaces represented.
Making the invisible visible
While much of the team expected the next step to be refining screens, we deliberately stepped away from the interface.
Instead, we began mapping the invisible system behind it.
First, the anatomy of a plan.
Then, the anatomy of a decision.
Then the relationships between aspirations, goals, preferences, constraints, options, tradeoffs, and plans.
At first glance, these looked like information architecture diagrams.
They weren't.
They were an attempt to communicate the inner workings of the screens—the things you can't see.
The diagrams gave us a common language for reasoning about planning before debating what the interface should look like. They answered questions that screens alone couldn't answer.
How does the system flex between novice and experienced planners?
How should advisor and client experiences remain consistent while supporting different responsibilities?
What changes as planning becomes more sophisticated?
Looking back, I don't think these diagrams documented the product.
I think they defined it.
Ironically, this became one of the least celebrated parts of the project. Although the work was created in direct response to questions raised during the initial concept review, it remained abstract to many of our product partners. Product organizations naturally evaluate ideas through interfaces, while these models existed one layer beneath them.
Despite that, they became foundational to our work. We referenced them constantly while designing screens, pressure-testing concepts with AI, and evaluating whether new ideas remained coherent as complexity increased. Whether or not they were broadly recognized, I'm convinced the final experience is stronger because we invested the time to define the system before refining the interface.
AI as a thinking partner
This project fundamentally changed how I use AI in my own practice.
Rather than treating AI as a tool for generating answers or designing interfaces, I began integrating it throughout product discovery.
For every experience I designed, I developed a rhythm.
Define what the screen needs to accomplish.
Validate assumptions against synthesized customer research in Dovetail.
Pressure-test ideas using Copilot.
Create structural wireframes.
Validate information hierarchy and content with Copilot.
Translate the experience into high fidelity.
Critique the design with AI before continuing.
The process became a continuous conversation between intuition, research, and AI.
AI never replaced design judgment.
It accelerated learning.
It challenged assumptions.
It broadened the solution space before I invested time refining ideas.
Previously I relied heavily on subject matter experts and fellow designers to pressure-test my thinking. AI now gives me a way to challenge my own thinking before bringing ideas to others. Human feedback is still irreplaceable because it introduces perspectives AI cannot, but the conversations themselves have become more productive because my work arrives with much stronger rationale behind it.
AI also notices things I might not. Sometimes that's a flaw in the logic of a workflow. Sometimes it's an inconsistency in the system. Sometimes it's something as simple as forgetting to replace placeholder copy. I often think of it as having a design critique available throughout the entire design process.
Designing adaptive experiences
One of the most exciting aspects of the project was designing a planning system that adapts rather than simply configures.
Instead of building separate experiences for different customers, we designed a single system capable of flexing based on planning maturity, financial complexity, advisor involvement, and client engagement.
We intentionally maintained consistency between advisor and client experiences wherever possible. This reduced cognitive load while simultaneously increasing reuse across the platform.
The result wasn't simply a collection of interfaces.
It was an adaptable planning system capable of growing alongside people's financial lives.
One example that brought this philosophy to life was how we approached collecting personal financial information. Rather than asking every customer to complete exhaustive forms upfront, we designed a system that continuously evaluated what information already existed, what information was missing, and whether enough context existed to plan confidently. As planning needs evolved, the system progressively gathered new information in response.
The underlying repository remained consistent across advisor dashboards, guided discovery workflows, and presentation mode, allowing the same information to support multiple jobs without forcing users to relearn the experience. The system was always listening for new signals, reassessing confidence, and adapting as clients' financial lives became more complex.
Reflection
Looking back, I don't think the biggest thing we designed was a planning experience.
We designed a shared mental model that made the planning experience possible.
The most valuable artifacts weren't the prototypes.
They were the principles, frameworks, diagrams, and conversations that allowed dozens of people to think about planning through the same lens.
That shared understanding made the interfaces possible.
More importantly, it reinforced something I've come to believe throughout my career.
The hardest part of product design isn't designing the interface.
It's helping people agree on the system behind it.