Back

Oct 2024

Designing a finance tool suite for DAOs

While I was leading Parcel’s (parcel.money) design team, we were riddled with user suggestions and features on our roadmap that were important but would become product/tech debt a few months down the line. We took a step back and built something from the ground up that helped users build healthier financial workflows.

The problem

Existing crypto payment tools, including Parcel at that time, were doubling down on a generic payment process that often required only a CSV of token amounts and wallet addresses. This approach broke down in practise as over-unification led to loss of specificity and control:

Payroll, expenses, and bills have fundamentally different structures.

Generic flows limited metadata and access control.

Financial data became harder to trust and act on.

Approach

Separated workflows by intent and designed for deep, context-specific metadata

A flexible payroll system that supports multi-token payouts, flexible pay cycles, contributor access & more.

List of active payroll on Parcel.
A contributor's profile on Parcel.
Payroll processing UI with pay cycle information.

An expense management module with support for contributor access.

Requested Expenses page on Parcel.
Add Expense form on Parcel.

A seamless bill payments system designed for speed.

Payments needing approval on Parcel.
Send Money form on Parcel.
A side drawer showing details of a bill payment seeking approval.

Maintained a unified core experience with granular access control

After the operators have reviewed payroll, expenses, and bill payments details, all transactions are queued up in one place ready for execution.

SAFE transactions page on Parcel.
A side drawer showcasing SAFE transaction details on Parcel.

Parcel was built on top of SAFE, so having queued transactions was inevitable.

Made bookkeeping the source of truth

Clear traceability across inflows and outflows with reporting and integration with QuickBooks.

Bookkeeping UI on Parcel.
A side drawer showcasing transactions ready to be synced with QuickBooks.

Outcome

Trying to do the simple things and taking user feedback at face value is a slippery slope. It only leads to product/tech debt that grows larger than the user problems at hand. Thinking and building in systems is still the only way to design experiences on a shared foundation.

Improved data accuracy and financial visibility across workflows.

Reduced reliance on external tools for tracking and reconciliation.

Reached $50K ARR in a category dominated by free tools.

Processed $100M+ in transactions while still in beta.

Great things are crafted when you zoom in

While building in systems, we zoomed out and reused components/patterns as much as possible, but we also zoomed in to see how users experienced what we were building. If we believed that the industry standard was not the right thing to do, we recreated it until we believed it was. It’s details like these that compound into the bigger picture.

Screen recording of a user entering their ENS in wallet address input.

On most apps, the ENS input doesn't reveal the underlying address, or lazily have it as a supporting text in the next line. This conflicts with the user's trust & familiarity with UI elements.

On most apps, the ENS input doesn't reveal the underlying address, or lazily have it as a supporting text in the next line. This conflicts with the user's trust & familiarity with UI elements.

Screen recording of a user navigating errors before making a payment.

Most apps check for errors post user's action and do not have meaningful messages when dealing with multiple errors. Some don't even show you the total before making a transaction.

Most apps check for errors post user's action and do not have meaningful messages when dealing with multiple errors. Some don't even show you the total before making a transaction.