DONE is not a user outcome

DONE is not a user outcome

In a transaction system, Done can be perfectly valid as an internal status.

For the user, it often says almost nothing.

Did the recipient receive the full amount?

Was only part of the transaction completed?

Was the transaction reversed?

Was the money refunded?

Is there anything the user still needs to do?

A system can reach its final technical state while the user is still trying to understand the outcome.

That gap matters.

System state vs. user outcome

Backend systems naturally think in states.

A process might move through:

Created → Submitted → Processing → Done

That structure is useful for engineering.

But users do not open a wallet to understand a state machine. They want to understand what happened to their transaction and their money.

Instead of showing only:

Done

The interface may need to communicate something closer to:

Completed
The transaction was completed successfully.

Partially completed
Only part of the expected transaction was completed.

Refunded
The funds were returned.

Failed
The transaction could not be completed.

The difference is small in UI terms but significant in meaning.

The final state carries the most responsibility

Before confirming a transaction, users usually need clarity around details such as:

• Network
• Recipient
• Amount
• Estimated fee

After submission, the interface has a different job.

It needs to explain the outcome.

A clear transaction history should allow someone to answer three questions quickly:

What happened?

Where is my money now?

Do I need to do anything next?

If the user needs to open a block explorer, contact support, or interpret a generic system status to answer those questions, the product is pushing unnecessary complexity back onto them.

“Successful” can still be ambiguous

Even labels like Success or Completed need context.

For example, a transaction can be technically submitted successfully while the final on-chain result is still pending.

That is why transaction UX should distinguish between stages such as:

Pending — submitted, but not yet final.

Confirmed — successfully confirmed.

Failed — not completed.

And where the product supports more complex transaction flows, additional outcomes such as Partial or Refunded should be surfaced explicitly.

The objective is not to expose every technical detail.

It is to expose the details that change what the user understands or needs to do.

Good transaction UX reduces interpretation

Users should not have to translate infrastructure terminology into human meaning.

The product should do that translation for them.

Instead of:

DONE

Consider:

Transfer completed
0.50 SOL was sent successfully to 8x2...Qk4.

Or:

Transfer refunded
The transfer could not be completed. Your funds were returned to your wallet.

The second version answers the question the user actually has.

Design for confidence, not just completion

Fast infrastructure matters.

Reliable execution matters.

But a transaction is not finished from the user’s perspective until they understand its outcome.

The final screen, transaction history, and status messaging are therefore not secondary UI.

They are part of the trust layer of the product.

At Biti.pro, we think transaction experiences should make state, outcome, and next steps easier to understand — without requiring users to understand the infrastructure underneath.

Because Done may be a system state.

It is not necessarily a user outcome.