Streamlining Customer Accounting Input
What is Ceterus?
Ceterus is an fintech startup that provides bookkeeping and tax services for Small Businesses and Franchises. They offer automated bookkeeping and advanced reporting through an online portal. I worked there as a product designer from 2022 to 2025.
My Role
I served as product designer for this project. All screens here are my original designs. Visual design is a combination of my own and our react library Ant Design.
The direct development team included ~10 engineers and a product manager. Work was organized in an Agile framework with three-week sprints. Strategy was coordinated by the product team and an investor, to which I presented to regularly and served as product attaché.
Impact
Solution
Give customers more control over their financials and redesign the channels for customer input to make it clearer to users what is required of them to get their books closed or complete other accounting processes.
Role
Product Designer
Tools
Figma | Heap
Challenge
Ceterus primarily supports franchise business owners with 2-10 locations, but as customers grew past 10 locations, churn increased. Our systems didn’t scale well, and growing clients struggled with slow or inaccurate bookkeeping and confusing workflows.
Features
Blocker Management and Grouping Improvements
Simplifying Transaction Coding and Feedback
Additional Feature: Transaction Splitting
Data Trends Visualization
Design System + Component Library
Process
This was a large project that reshaped the way Ceterus conducted business. There were 2 major points of focus:
Internally, we will change the way Ceterus closes books and allow external users more control over their financials. Transactions that they categorize will post directly to their accounts rather than being routed through an accountant.
Externally, we will provide a more intuitive experience for categorizing these transactions and display to external users what is required of them to close their books on a more granular level.
Discovery + Research
The most common reasons for churn that Ceterus experiences are either related to the speed at which a company’s books are being closed or the accuracy of those books. Due to recently experiencing some churn from larger customers, the product team focused more on interviews with customers who own a higher number of locations and some recently churned customers.
The interviews led to more findings about the trouble users were having reviewing their own financials and general issues surrounding communication within the application. The existing page responsible for the customer coding of transactions was far from perfect, but the issues were exponentially more troublesome the more locations a user managed.
I had previously noted some issues found within the existing page, Transactions to Code, specifically the functionality of comments and the flow for submitting transactions, but there was another looming issue. Transactions aren’t the only thing that can prevent the books from closing. There could also be issues with a credential or a missing document and all of that currently lives on another page, the Action Center.
So I propose we combine the pages. Seems simple enough. Actually, due to the way we pull Zendesk tickets into the Action Center, they can’t exist with another type of item, like transactions. This is why in the previous Action Center there was simply a link to all the transactions a user has to code that takes them to the Transactions To Code page. That is why there are internal and external focus points. We will have to create another way to handle these miscellaneous items, or Blockers, internally so that we can display them together externally. That project, which would end up being our own custom CRM tool called Blockers, could be a case study on its own, but keep in mind both of these are happening simultaneously.
The original Action Center with a link to the Transactions to Code page.
Now that we’ve figured out how we’re going to get these blockers to coexist, let’s figure out how we're going to display them. In early conversations with leadership, I proposed we introduce a new home page rather than simply add on to the current Action Center. On a new home page these Blockers can be more clearly contextualized and with drawer functionality, users will never have to be pushed to another page.
Early Homepage draft (Old UI) featuring first Financial Insights concept.
From a business perspective this makes sense and these new features will surely increase the usability of the page, but something still feels missing. We're optimizing customer input, but this is essentially still just more work for the customers. Customers are paying us to get their books done and our big update is helping them work better? I do believe the current user flow is slowing the process down, but from the analytics I believed this issue to be more of an engagement problem than a process problem. I want to incentivize this work and provide something to users outside of what they are already paying us for and expecting from us. This is where financial insights come in. Financial insights will bring a new layer to our customer-facing application that not only incentivizes more frequent visits, but can also help inform the business decisions of customers. This would also present a marketing opportunity as this would create a new face for the application. A clearer separation from the Ceterus of old.
During this time I was also asked to reimagine what our application, called "Edge" at the time, could look like in a complete redesign. I knew this possibility was highly unlikely, but it was a fun exercise.
Design
Early Homepage draft (New UI) featuring Financial Insights Concept.
New Can Review page; this would house optional transactions that are not necessary to close books.
Right: Drilldown page (New UI); Drilldown enables users to look at the individual transactions that make up an account line. Currently this lives in a modal on the Profit and Loss page.
A new home page is being introduced, but transactions are still at the forefront of the project. After all, that’s still the main cause for churns. We want to introduce a new solution to this to stakeholders early and often for validation. Over the next 2 weeks I would iterate on different medium fidelity transaction prototypes with leadership and development to discover a simple way to handle complex transactions.
These prototypes I created, aptly Titled "Edge Preview", would be presented to key stakeholders for approval. We wanted to make sure they correctly addressed core problems before development fully began.
In early discussions with leadership there was a focus on 2-line transactions, transactions which a user would only be able to edit 1 line of the transaction. This type of transaction is the most common we deal with and would start to be referred to as a 99%er. The 99%er would be the key to really nailing this transaction editing feature.
The other type of transaction, those with 3 or more lines, would be referred to as multiple line transactions. Early on in development it was discovered that we would not be able to let customers directly edit multiple line transactions. Customers would have to provide a comment to us on these transactions and we would continue handling the edit ourselves. Or so we thought.
Development did ultimately figure out a way to handle both types of transactions, but it came at a cost. The UI would have to handle both types of transactions with the same UI components. This could lose a lot of the simplicity of the 99%er design and potentially create friction for our users with less accounting knowledge.
Multiline Transaction UI with a 4 line transaction.
Multiline Transaction UI with a 99%er.
I pleaded with other members of the product team and development, but we were already working within a tight timeline and maintaining a separate UI wasn't believed to be feasible. However once given the opportunity to validate the designs, there was a strong push back from users about the newer version. I believed this was a case where sacrificing the overall experience for most in favor of edge cases did not make sense and users agreed. Regardless of some additional development time, this was the experience we needed to be aiming for. This feature would no longer ship without that 99%er view.
Initial Launch Version of the 99%er View.
With transaction editing figured out, I continued working on the other redesigns. Scope had officially removed an entire application redesign from the table, but we still pushed forward with the Homepage, Blockers, and hopefully financial statements. The hope was that since the bulk of our users focus on those features, it could still feel like a new application even if those were the only changes made.
Non-transaction blockers were fairly straight forward, externally at least. Most requests fell within a few categories: Information collecting we already had a UI for, external integrations, or text entry. So even if there were technically 50+ blockers we needed to account for, we only needed a few UI choices to cover all those bases. And some of those choices, such as external integrations, were simply buttons (lucky me). Text entry blockers did get a few iterations, however they were limited due to the functionality of the drawer itself.
Early Iteration Blocker drawer for restoring a connection.
Blocker drawer for updating a credential.
One of the big points of conflict during this project was the functionality of the drawer, and more specifically the submit button. I was always pushing for a 1 click solution; no matter how many changes were made within the drawer itself, you hit submit, and all of those are submitted at once. The issue was that things like text entry and form submissions, or even transactions, all seemed to require different layers of submission. Developers pushed back on this, arguing to keep the code as simple and clean as possible, but this time leadership stepped in without the need for more external validation, possibly due to the timeline. Despite the calls for simpler code, the users needed a simpler experience. That was a tradeoff we did not want to sacrifice.
Final Mockup Blocker drawer for information requests.
At some point in all that conversation, financial statement redesign had also been removed from the scope, so focus returned to the Homepage UI. Now that we had more information about the possibilities of this new page and a clearer timeline, I stripped down the UI and focused purely on the experience and workflows for users. I confirmed approval for that before returning to the UI design. This was the home stretch, this is also when things got complicated again.
As the one most knowledgeable about frontend technologies and our infrastructure on the product management team, that also often led to me being the bearer of bad news. The use of our react library, AntD, and the restrictions that come with it, would severely limit the possibilities, but that wasn't my battle to fight. Regardless of those restrictions, it would always be possible to create a satisfying UX solution and a UI that was an improvement upon the previous one. Conversations over the next few days would lead to an alignment on all fronts, leadership, product management and development, until everyone was satisfied and we could move forward.
Conclusion
After a period of UAT, we began to slowly roll out the new update over the period of a few weeks, starting with beta testers. We also had to account for the time to migrate our Zendesk tickets to our new blockers feature. The improvements were noticed almost immediately and users were very active in their usage of the new features like transaction editing. The categorization of blockers led to a more steady input as users now knew what items were specifically blocking them and could prioritize to their needs.
After the full release, we were able to continue to quickly iterate and continue with more features to empower our users such as transaction splitting, a commonly requested feature.