WalletIQ started with a broad ambition: make personal finances easier to manage. That sounds clear until you try to turn it into an interface. “Managing money” can mean tracking transactions, creating budgets, planning bills, monitoring accounts, forecasting cash flow, or simply feeling less uncertain.
My first instinct was to make the application capable. The better instinct was to make it legible.
The shift from data to decisions
A transaction table can be accurate and still leave the user with the same question they had before opening the app: Am I okay?
That question changed the product. Instead of treating every financial feature as equally important, I began organizing the interface around a smaller set of decisions:
- How much can I still spend this week?
- What happened on a particular day?
- Which upcoming fixed costs should I be thinking about?
- Can I understand the product without handing it private financial data?
Those questions gave the application a hierarchy. Weekly spending became more prominent. The calendar became central rather than secondary. The demo became a product experience rather than a collection of screenshots.
Removing features was product work
I considered Plaid integration, CSV uploads, automated categorization, receipt scanning, and several other features. Some would have made the application look more complete. They also would have created more failure points and distracted from the part I was actually trying to prove.
The MVP did not need to prove that WalletIQ could connect to everything. It needed to prove that WalletIQ could explain something.
Removing those features created space to improve the interactions that remained: selecting dates, understanding transaction details, navigating the walkthrough, and seeing the relationship between spending and time.
The interface kept exposing weak language
One of the most useful parts of building the app was discovering how easily financial language can create the wrong mental model. A negative number might be mathematically correct but visually alarming. A balance might be accurate but irrelevant to the immediate decision. A label such as “budget” might imply restriction when the intended message is awareness.
I revised the wording repeatedly because the interface was not merely presenting numbers. It was telling the user how to interpret them.
The demo had to behave like the product
Because WalletIQ is also a portfolio project, I needed someone to understand it quickly. A static presentation would show what the app looked like, but not how it felt to use.
I chose to create a public interactive demo with realistic fictional data. That decision introduced its own product problems: the walkthrough needed to appear once, scrolling had to work on shorter laptop screens, highlights needed to follow the selected element, and the user had to be able to leave the tour and explore.
Those were not side issues. They were the experience.
What the project taught me
WalletIQ taught me that product work is often the discipline of narrowing. The app improved when each screen had a clearer job, each metric had a clearer interpretation, and each feature had to justify the attention it demanded.
The biggest lesson was simple: building a product is not the same as accumulating functionality. A useful product helps a person see what matters next.
← Back to writing