Restructuring
the transaction model
to scale financial planning
5% → 18%
Planned transaction adoption
Planned transaction adoption
80% → 92%
80% → 92%
Completion rate
Completion rate
72% → 95%
Transactions with a category
Transactions with a category
Domain
B2C
FinTech
Mobile app
B2C, FinTech, Mobile app
Users
Microbusiness owners
Sole proprietors
Freelancers
Microbusiness owners, Sole proprietors, Freelancers
Team
Product Manager
Tech Lead
Backend & Frontend Developers
Quality Assurance Specialist
Senior Product Designer (me)
Product Manager, Tech Lead, Backend & Frontend Developers, QA, Senior Product Designer (me)
What I did
Research
Product analytics
Information architecture
Interaction design
UI design & Design system
Research, Product analytics, Information architecture, Interaction design, UI design and Design system
Product
Kimi is a financial accounting app for microbusiness owners.
Kimi is a financial accounting app for microbusiness owners. While most bank transactions are imported automatically, users still manually record
cash expenses, contractor payments, and transfers. These manual entries directly determine the quality of reports, budgets, and forecasts.
Kimi is a financial accounting app for microbusiness owners. While most bank transactions are imported
automatically, users still manually record cash expenses, contractor payments, and transfers. These manual entries directly determine the quality of reports, budgets, and forecasts.
While most bank transactions are imported automatically, users still manually record cash expenses, contractor payments, and transfers. These manual entries directly determine the quality of reports, budgets, and forecasts.
Business Context
The goal was to evolve the product from an expense tracking app into a financial planning tool. The next roadmap milestone was Recurring Transactions, it is
a feature enabling users to plan regular expenses and improve cash-flow forecasting.
The goal was to evolve the product from an expense tracking app into a financial planning tool. The next
roadmap milestone was Recurring Transactions, it is a feature enabling users to plan regular expenses
and improve cash-flow forecasting.
Before launching the new functionality, it was important to understand whether the existing transaction creation model could scale without increasing complexity for users.
However, before launching the new functionality, it was important to understand whether the existing
transaction creation model could scale without increasing complexity.
Before launching the new functionality, it was important
to understand whether the existing transaction creation model
could scale without increasing complexity for users.
Research
I conducted the research in 2 phases:
Quantitative: I partnered with the PM to analyze the transaction funnel and user
behavior across Actual and Planned transactions.Qualitative: I conducted usability tests, interviews, a design audit, and competitor
analysis to explain the observed behavior
Key findings from research:
1. One in five transactions was abandoned
1. One in finve transactions was abandoned
The completion rate was only 80%, leaving gaps in users’ financial data.
The completion rate was only 80%, leaving gaps
in users’ financial data.
2. Planned transactions weren’t adopted
2. Planned transactions
weren’t adopted
Adoption remained at 5%, indicating users weren’t moving from expense tracking to financial planning.
3. Users didn’t understand “Planned transactions”
8/10 participants expected planning to be part of transaction creation rather than a separate mode.
8/10 participants expected planning to be part
of transaction creation rather than a separate mode.
4. The architecture mixed independent concepts
The creation flow combined transaction type, transaction timing, and navigation into a single decision, making the interface difficult to understand and extend.
The creation flow combined transaction type,
transaction timing, and navigation into a single decision, making the interface difficult to understand and extend.
Before
After
Overview
Overview
Key Insight
The research revealed that the issue wasn’t the Planned feature itself —
it was the interaction model. Users naturally answered two questions in sequence:
The research revealed that the issue wasn’t the Planned
feature itself — it was the interaction model. Users naturally answered two questions in sequence:
The research revealed that the issue wasn’t the Planned feature itself — it was the interaction model.
Users naturally answered two questions in sequence:
- What kind of transaction is this?
- When does it happen?
The interface forced users to answer both at the same time, making Planned feel like an alternative mode rather than
a transaction property.
The interface forced users to answer both
at the same time, making Planned feel like
an alternative mode rather than
a transaction property.
The interface forced users to answer both at the same time, making Planned feel like an alternative mode rather than a transaction property.
Before
After
Design Principle
Instead of treating “Planned” as just another mode,
I proposed redefining the transaction model.
Instead of treating “Planned” as just another mode, I proposed redefining
the transaction model.
Every transaction answers two questions:
What kind of transaction is this?
Expense / Income / Transfer
When does it happen?
Actual / Planned
Separating type and time allowed us to maintain a unified creation flow, making planning a natural part of it. This model also enabled recurring payments to be added without redesigning the transaction creation flow.
Separating type and time allowed us to maintain
a unified creation flow, making planning a natural part of it. This model also enabled recurring payments to be added without redesigning
the transaction creation flow.
Separating type and time allowed us to maintain a unified creation flow, making planning a natural part
of it. The model also enabled recurring payments to be added without redesigning the transaction creation.
After
After
Design validation
Before release, I validated the new flow through usability testing.
Before release, I validated the new flow through
usability testing.
- After the redesign, 9 out of 10 participants were able
to explain when to use “Actual” and when to use “Planned.”
- All participants completed the scenario without prompts.
- After the redesign, 9 out of 10 participants were able to explain when to use “Actual” and when to use “Planned.”
- All participants completed the scenario without prompts.
After the test, I asked the Single Ease Question — “How easy was it to create
a transaction?” And the average rating was 6.3 out of 7.
After the test, I asked the Single Ease Question — “How easy was it to create a transaction?”And the average rating was 6.3 out of 7.
After the test, I asked the Single Ease Question — “How easy was it to create a transaction?”
And the average rating was 6.3 out of 7.
Second iteration
Step-one drop-off was the symptom, not the goal. Optimizing one screen would have capped the win, so I ran a detailed UX audit of the full wizard and presented it
to the team, which set the direction for the next iteration.
Step-one drop-off was the symptom, not the goal. Optimizing one screen would have capped the win, so I ran
a detailed UX audit of the full wizard and presented it
to the team, which set the direction for the next iteration.
Step-one drop-off was the symptom, not the goal. Optimizing one screen would have capped the win, so I ran a detailed UX audit of the full wizard and presented it to the team, which set the direction for the next iteration.
UX audit of the wizard
UX audit of the wizard
If we streamline the setup by reducing steps and fixing UI friction, users will reach the “Invite” stage faster, significantly increasing conversion to the invite candidates step.
If we streamline the setup by reducing steps and fixing UI friction, users will reach the “Invite” stage faster, significantly increasing conversion to the invite candidates step.
Step 2 — Skills
I rebuilt the cards for inline editing so users could adjust skills without friction, smoothed the flow for adding a new skill, and removed redundant actions.
I rebuilt the cards for inline editing so users could adjust skills without friction, smoothed the flow for adding a new skill, and removed redundant actions.
Before
After
Step 3 — Cases
Users wanted options, not a single fixed output. I added AI regeneration so they could choose between case variants, and flexible inline editing.
Users wanted options, not a single fixed output. I added AI regeneration so they could choose between case variants, and flexible inline editing.
Before
After
Final Design
