Introduction

Tooni is a personal finance and budgeting tool that helps users take control of their spending through an allocation-based budgeting approach.

This approach helps users manage their money more intentionally by guiding them to distribute it across expenses, savings, and investments in a structured yet flexible way.

Our platform aims to provide a seamless and intuitive experience, making budgeting accessible to both beginners and experienced budgeters.

Context

In late October 2023, Intuit announced the shutdown of its personal finance and budgeting application, Mint, with a partial transition to Credit Karma. However, this migration meant that many key features like budgeting and goal tracking would not be carried over, leaving many long-time users scrambling for a comparable alternative.

Recognizing this gap in the market, I saw an opportunity to create Tooni. However, the last time I used a budgeting application was in 2016–2017, meaning any knowledge I had about the limitations of these tools was rooted in that time period.

With the scheduled shutdown of Mint approaching, I needed to quickly get up to speed on how budgeting applications had evolved and what gaps still remain in the market.

Research

To build Tooni into an effective personal finance and budgeting tool, we first needed to understand how the landscape of budgeting applications had evolved since I last used one in 2016–2017.

Secondly, we needed to decide on the right budgeting methodology to use, weighing the pros and cons of different systems like zero-based budgeting and envelope budgeting.

Then vs. Now

When I first used budgeting applications back in 2016-2017, one of the biggest issues of that time was the lack of customizability. The majority of applications forced users into predefined spending categories which didn’t always matched real-life expenses.

Many also struggled with poor user engagement, making it difficult for users to stay consistent with their budgets. On top of that, most applications were designed primarily for desktop use, with little-to-no mobile functionality, making it inconvenient for users to track their finances on the go.

Today, those same applications have improved in many ways. Custom categories are now common, automation has become a standard feature, and most budgeting tools offer mobile companions alongside their desktop versions.

These days, the only common issues you see are integration issues with financial institutions, data security concerns, and complex interfaces and flows that can overwhelm users, especially new users.

While budgeting applications have come a long way, there are still gaps to address. The challenge now isn’t just about offering more features but ensuring they are intuitive and truly helpful for users.

Budgeting Approach

Before we get into the finer details, we first had to determine which budgeting methodology we were going to use for Tooni. There are several popular approaches, each with its strengths and limitations.

Ultimately, we went with an allocation-based budgeting methodology because it strikes a middle ground between structure and flexibility where users can allocated dollars to categories similar to envelope and zero-based budgeting, but overspending isn’t necessarily restricted.

Rather than enforcing limits, our focus is on awareness. Our goal is to empower users to track their spending and adjust as needed. At the end of the day, it is up to the user to commit to their financial plan.

Design

The current design reflects a series of intentional decisions aimed at balancing functionality and user experience. Every component was carefully considered to ensure it adds value to the user, whether by simplifying interactions, enhancing visual clarity, or improving task efficiency.

Layout

The layout of the application follows a three-column structure that is consistent across most pages. On the left, the Navigation column provides access to all pages and includes a persistent display of the user’s net worth. The central Primary column serves as the main content area for each page, while the right Secondary column acts as a secondary support space and is used to enhance and provide context to the main content.

This structure allows users to quickly access essential navigation and key information without disrupting their workflow. By centralizing the primary content and using the secondary column for relevant insights, users can stay focused and maintain efficiency without the need to switch between pages.

Categories

Categories play a central role in the application, shaping how transactions and budgets function. Each transaction is assigned to a category classified by its importance, which then contributes to the overall budget.

In designing this system, we chose to classify categories based on their importance to the user to offer a more personalized and insightful view of spending. By distinguishing between necessary, discretionary, and wasteful expenses, users can better understand how their spending aligns with their financial priorities.

Budgets are structured around categories with users defining monthly limits for each category and the application tracking spending against those limits through transactions.

This system provides users with a clear understanding of their spending habits and helps them make informed financial decisions.

Visual Indicators

The use of colors in the application serve both functional and visual purposes. Categories are classified based on their importance to the user. Each of these groups is assigned a distinct color to create a clear visual distinction.

These color associations make it easier for users to quickly interpret information and understand their spending patterns at a glance.

Toolbar

The Toolbar is an essential component that streamlines user interactions within a page. It consolidates all relevant functions and operations related to the current page in a fixed and easily accessible position.

Early iterations of the design struggled with button placement, as positioning them within the main content area often interfered with the scroll experience. This challenge led to multiple redesigns before arriving at the current solution, where the Toolbar remains fixed and unobtrusive.

Infinite Scroll vs. Pagination

When I initially considered how to display transactions, infinite scroll seemed like the ideal choice. It provided a modern browsing experience, with no interruptions and limits.

However, the development team pointed out a major constraint, many of the functions and operations in the Toolbar would not be technically possible with infinite scroll. This created a real dilemma because we had designed everything with infinite scroll in mind and I wasn’t keen on the idea of switching to pagination.

After taking a day to think and research, we landed on what I consider to be the perfect compromise. We could use pagination but only display the components for it once the transaction count exceeded a certain threshold, a threshold that surpasses several times the typical monthly transaction volume of an average user.

This approach would provide the best of both worlds, the illusion of infinite scroll in regular use cases and the necessary functionality of pagination in edge cases.

Challenges

Designing and building this application had its fair share of challenges, which resulted in development resets and constant refactors.

One of the biggest challenges I faced was designing with development in mind. Throughout design, there were a number of features and flows that were not practical to build. This resulted in a lot of back-and-forth communication to try to salvage a solution or come up with a suitable alternative. Those experiences have taught me how to balance design goals with technical constraints to create solutions that were feasible.

Another challenge I faced was handing over documentation to developers. Even though I had learned documentation practices and completed a project on it during my program at the UX Design Institute, applying those skills effectively in a real-world setting was difficult.

Since none of the developers had any prior experience with personal finance and budgeting tools, they couldn’t rely on industry knowledge to fill in the gaps that I left behind. This led to a lot back-and-forth communication and rewrites that delayed the development process. This taught me the importance of having comprehensive documentation to streamline development.

Future

As of March 2025, we’re currently focused on working out any kinks in the Transactions page as well as refactoring the database. Once that is finished, we’ll move on to building the Budget page and testing the Transactions page. After that, we’ll aim to launch the minimum viable product and continue iterating on the rest of the features like Goals and Recurring Transactions.

As we move forward, we’ll continue to learn and adapt as we build toward a fully realized product that we can be proud of. If you’ve made it this far, please check us out at www.tooni.ca.