---
title: (Work in Progress) Smart Invoice UX audit
tag: ux, raidguild, smartinvoice
---

This is a user experience audit on Raid Guild's Smart Invoice tool to identify gaps and suggest improvements. To set the context, some assumptions will be made to make up for limited data, as well as to have quicker iterations.

Since Smart Invoice tries to solve the age-old business payments and invoicing problem with the Web3 lens (i.e. personas and technology), it is helpful to first understand the core problem of invoicing before diving into the context of web3

As a general rule, invoicing is a painful but necessary part of ensuring business payments are being paid. As such, most users would see it as an unglamorous task that takes up more time than it should. Ideally, it should be as quick, transactional, and invisible as possible, so that people can complete it and get busy with other things.

With that, we can zoom into the UX audit for Smart Invoice, first by going through our approach

**Approach**
1. Define scope of research
- User personas, flows, objectives
2. Map out & evaluate user journey
3. Identify gaps & propose improvements

# 1. Research Scope :mag:

## 1.1 User Personas :boy: :girl:

| Characteristic | Payee | Payee | Payer |
| -------------- | --- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Organisation | DAOs, Token entities, Agencies | DAOs, Token entities, Agencies | DAOs, Token entities, Agencies |
| Role | Project / Product Lead | Commercial / Ops Lead | Commercial / Ops Lead |
| Goals | "I want to ensure funds are in, so **I can start work (after all that planning**)" | "I want to ensure funds are in, so **my team can start work**" | "I want to send the funds (only so that the **project can start**) but I want to ensure it's **safe and escrowed**" |
| Pain Points | "I've **too many things, too little time** - planning, execution and now admin tasks like this" | "**My team** that has started the prep work needs the confirmation and **assurance we can start**" | "I don't know if I can **trust my counterparty yet**" |
| Web3 savviness | Main chain ++ | Main chain only | Main chain only |

From the above, both the Payee and Payer's goals are to start the project but they are **hindered by uncertainty whether their effort or funds will be honoured**. Some assumptions were made based on different personas within an organisation.
> * Product/project personas are savvier with Web3 but have less time for invoicing since they are involved in planning and shipping
> * Commercial/ops personas are less savvy with Web3 but have more time / bandwidth for invoicing, since their role is supportive and less tech-focused
> * In both cases, the product needs to have minimal friction, so that it saves time for Product / Project personas, and reduces dropoff for Commercial / Ops personas

Hence if there was a perfect solution, it should **give Payers and Payees maximum assurance (that money is deposited / safely escrowed) with minimum steps and friction**. That would be Smart Invoice's duty to our users.

## 1.2 Existing Flows :computer:

| Common Goal | Payee Flow | Payer Flow |
| ------------------------------- | --------------------------------------------- | -------------------------------------------- |
| Kickoff project | (Start) Create & send invoice | (End) Pay kickoff deposit |
| Move project along (milestones) | (End) View invoice & verify milestone deposit | (Start) View invoice & pay milestone deposit |
| Seek arbitration |View invoice, lock funds and submit for arbitration | View invoice, lock funds and submit for arbitration |

## 1.3 Objectives :chart_with_upwards_trend:

With the above understanding, here are the narrowed-down objectives.

| Objective | Metric | Current | Goal |
| -------- | -------- | -------- |-------- |
| 1 | Increase success rate of kickoff invoices sent by Payee | X% |Y% |
| 2 | Increase success rate of kickoff invoices paid by Payer | X% |Y% |
| 3 | Increase success rate of milestone invoices paid by Payer | X% |Y% |

I've selected the above as they are most crucial in giving users the "Aha" moment (i.e. have maximum assurance to start a project with minimum frictions). This exposes more users to first try the product, continue using it and sharing with others for growth.

# 2. User Journey :walking:

With the user personas identified above, I went through the Smart Invoice flows and summarised the big steps below:

<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Ffile%2Fr8rDWpc2LkT2q9a84WAFFr%2FUntitled%3Fnode-id%3D4%253A1" allowfullscreen></iframe>

From there, I went deeper into the screens to simulate the perspectives of the user and identify user experience gaps.

<iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Ffile%2Fr8rDWpc2LkT2q9a84WAFFr%2FUntitled%3Fnode-id%3D0%253A1" allowfullscreen></iframe>

Instead of running through the comments and suggestions serially, I will group them together into action points for more efficiency in the next section.

# 3. General Evaluations :globe_with_meridians:

Revisiting the principles stated in the Overview section, Smart Invoice's goal is to **give Payers and Payees maximum assurance (that money is deposited / safely escrowed) with minimum steps and friction**

With that, I would classify things that help increase assurance or reduce friction points for users. Conversely, I would consider areas where more assurance can be given or where friction can be further reduced to be areas where we can improve.

Let's begin!

## 3.1 Product works well :+1:
I've tested all major flows that the users from different personas might experience and the experience so far has been great. The major functionalities work without any bugs and there also a lot of field validations along the way to ensure all fields are filled in correctly.

## 3.2 Simplicity of flows :+1:
Since Smart Invoice requires only 4 steps to create an invoice, and 2 steps to pay for an invoice, the process is straightforward and simple, which is great. A summary of the steps can be found below.

|Steps | Payee to create invoice | Payer to pay invoice |
| -------- | --------------------- | ------------ |
| 1 | Enter Project Details | View Invoice |
| 2 | Enter Payment Details | Deposit Funds |
| 3 | Enter Payment Chunks | - |
| 4 | Confirm Details & Create | - |

## 3.3 xDai chain
While being on xDai helps save transaction costs, this might come at an expense of ease of use. I'm expecting future users such as external clients and service providers may not already be on xDai or be well-versed enough to bridge to xDai.

**Here's what they'd need to go through to use Smart Invoice**

1. Add xDai network to their wallet
2. Bridge some ETH/xDAI(?) to xDai network
3. Wrap the xDAi or ETH (if they are paying)

Before jumping to conclusions of deploying Smart Invoice on mainnet or other L2 / side chains (which could have more adoption or better UX, **I would suggest having a more data-driven cost-benefit analysis before moving forward**
1. **Benefit**: What is the average cost of all on-chain transactions for an average Payer and Payee?
- This would determine the value of cost savings on xDai. If projects are generally big with few payment chunks, then xDai's cost savings might not be big.
2. **Cost**: What is the true extent of user friction here? (i.e. How likely is xDai going to become the norm, as compared to ETH or other L2s?)
- This measures the incremental friction for xDai versus their daily ETH / Defi activities.
- If xDai has a big or increasing share of ETH users, then user friction is likely to be low or go down from here. If otherwise, we might need mainnet or sidechain deployments
- I did some quick research and it seems like 30-day active wallets on xDai and Ethereum is around 36K: 550K, implying a 6% share of ETH wallets

After the above exercise, we can then better assess which is the choice moving forward, depending on the scenario:

| Scenario | Cost | Benefit | Choice |
| --- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------- | ----------------------- |
| 1 | Signing cost for invoice is bearable | User friction on xDai is high and unlikely to drop meaningfully | Deplot on Mainnet |
| 2 | Signing cost for invoice is on Mainnet too high | User friction on xDai is high and unlikely to drop meaningfully as compared to other alternatives | find other alternatives |
| 3 | Signing cost for invoice on Mainnet is too high | User friction is not that high or will go down | Stay on xDai |

## 3.4 Imagery & Art Style
While the Raid Guild swords logo, Hogwarts-looking background and RPG-like art style are very uniquely Raid Guild, the imagery makes it confusing for first-time users who are expecting a business payment tool.


Anecdotally, this went through my head the first time I chanced upon Smart Invoice during the Cohort 1 call.
* "I am on this site that I'm supposed to create invoices, cool"
* "Why does this look like a game?"
* "Am I on the right site?"
* "Hmm, smart invoice?"
* "I'm confused"

Eventually, I bounced off the site after reading the "What is this?" and being confused by the 2 very different ideas in my head: business payments & business RPGs

**Moving forward, I'd suggest we have a middle-ground, where we introduce more icons and images that are more related to the domain of business, deals, payments and invoices, while showing the art style of RaidGuild's unique RPG roots more subtly.**

## 3.5 Site navigation
The site navigation and hamburger menu is a missed opportunity for users to get to the 2 main CTAs faster. Currently, the hamburger menu only opens Home, FAQ, and Support.


**To move forward, my suggestion here would be to add the 2 CTAs here to help users better navigate the site.**

## 3.6 Tight feedback loops :+1:
For most web3 products that I've used, when you click on a certain button that requires you to do something on-chain with your wallet, there is typically no feedback loop / message for the user and the wallet just opens up instantly.

I was pleasantly surprised using Smart Invoice and seeing that we have feedback screens that tells the user what is happening. Also, when transactions are signed and confirmed, the updating and refreshing of the page makes the feedback loop very tight. This is great.



## 3.7 Generally clear language :+1:
Language used throughout the product is generally clear and straight to the point, which helped the information fields easy to understand and fill in. This is great.

There are only 2 screens where new words were introduced in the flow, which I thought was a little confusing. To move forward, I'd suggest standardising the text as such:

| Step | Current Screen | Comment | Suggestion |
| ----------------------------- | ------------------------------------ | -------------------------------------------- | ---------------------------------------- |
| Create Invoice |  | Clear CTA "Create Invoice" | - |
| Invoice Registration Received |  | Title now is "Invoice Registration Received" | Change to "Creating Invoice" | |
| Invoice Registered |  | Title is now "Invoice Registered" | Change to "Invoice Successfully Created" |

# 4. Screen-specific Evaluations :round_pushpin:
## 4.1 Pay Invoice screen
This "Pay Invoice" screen is seen when the Payer has received the invoice link from the Payee and wants to deposit funds.

Unlike the rest of the screens which are simple, there are too many assets on screen that the user needs to process, especially when the invoice involves multiple payment chunks.


**I understand the need to be specific and thorough in describing details regarding payment, but the following assets could be simplified further:**

| Asset | Current | Comment | Suggestion |
| ----- | --- | ------- | -------- |
| Helper text | "How much will you be deepositing today?" | Since it's pink, it draws my attention to it but only make things marginally clearer. | Remove it |
| Dropdown beside currency amount | Arrow dropdown | As a user, I'd think the dropdown is a prompt to select a currency. This is however not required as the currency is specified in the invoice link. | Remove it |

## 4.2 View Paid Invoice screen
The "View Paid Invoice screen" is seen when a Payer has deposited funds for the Smart Invoice and is viewing the invoice here. Generally, the screen uses the same invoice summary screen which is clear and informative.


However, the issue here is with the placement of the "Lock" button. Since the "Lock" action comes with major consequences (like a "Nuke" button) and is used only in minority of projects, the current placement conveys too much importance to the button and may confuse new users.

**Hence, my suggestion would be to preserve the 2 CTAs layout with "Deposit" and "Release" and move "Lock" button to the side, where it is still visible but clear that it is not the main CTA**

## 4.3 Missed opportunities for user joy
As a product,there are 3 significant milestones in Smart Invoice that should bring users joy:
1. After a Payee have created a Smart Invoice
2. After a Payer has deposited funds into Smart Invoice
3. After a Payer has released funds to the Payee

These should have dedicated success screens to assure the user that their respective actions have been completed, and also give the users joy

| Milestone | Current | Comment | Suggestion |
| ---------------------------- | ------- | ------- | ---------- |
| Invoice successfully created |  | This assures users of success, but can be more celebratory| |
| Funds successfully deposited | | This is too implicit. Can be more direct and celebratory | Have a dedicated success screen for funds deposit|
| Funds successfully released |  | This is too implicit. Can be more direct and celebratory | Have a dedicated success screen for funds deposit |

## 4.4 Locked funds screen
This screen happens when Payees or Payers are requesting to lock funds and are required to enter some inputs before submitting the case for arbitration.

From a user's perspective, the screen looked daunting with a lot of text. On closer look, they were generally explaining how the LexDao process works, which I thought could be summarised. Also, I thought the language could be more straightforward in being more direct in explaining how the process works.


**Moving forward, I suggest summarising and being more direct in the different texts used to explain the arbitration process, so that it is less visually heavy for users when they're seeking arbitration** (which I believe would be helpful during the emotionally draining period of seeking arbitration)
# 5. Summary :checkered_flag:

To recap, we started this UX audit of Smart Invoice to achieve the following 3 objectives:
| Objective | Metric | Current | Goal |
| -------- | -------- | -------- |-------- |
| 1 | Increase success rate of kickoff invoices sent by Payee | X% |Y% |
| 2 | Increase success rate of kickoff invoices paid by Payer | X% |Y% |
| 3 | Increase success rate of milestone invoices paid by Payer | X% |Y% |

In general, the Smart Invoice tool's flows, features and functionality are very well-designed. They are clear, concise and achieve what they promise to users - a funds request, deposit, escrow and release mechanism to facilitate business payments for web3.

Here is a quick summary of what went well, and how else we can improve.

## What went well :rocket:
| S/N | Points |
| --- | ------------ |
| 1. | Straightforward and simple flow |
| 2. | Clear language used throughout |
| 3. | Tight feedback loops for on-chain transactions|
| 4. | Product works as intended |

## How we can improve :crossed_swords:

| S/N | Flow | Workstream | Points | Objective |
| --- | ------------------------------------------ | --- | ----------------------------------------------------------------------------------------------- | --------- |
| 1. | General | Design + Frontend | Use assets related to business payments while projecting Raid Guild's personality subtly | 1,2,3 |
| 2. | General | Design + Frontend | Insert main CTAs in hamburger menu | 1,2,3 |
| 3. | General | Research | Explore research to decide whether we should deploy to mainnet or other L2s | 1,2,3 |
| 4. | Pay Invoice | Design + Frontend | Reduce assets by removing text and dropdown assets | 2,3 |
| 5. | View Paid Invoice | Design + Frontend | Move "Lock" button to the side and keep 2 CTAs | 2,3 |
| 6. | Creating Invoice & Invoice Created screens | Copywriting | Standardise words used on the screen | 1 |
| 7. | Various screens | Design + Frontend | Create dedicated success screens for significant actions (e.g. funds deposited, funds released) | 1 |
8.| Lock Funds | Copywriting |Make text more concise and direct | - |

If the suggestions were to be taken forward, the resources required will be more on the Design and Frontend Dev side.

---

Thank you for reading this document until here :pray: Please let me know if there are any areas which I have misinterpreted, assumed wrongly or operated on the wrong context - would love to know how I can further improve on this.

Looking forward to the feedback :smile:

---

<!-- #### Notes from Blogpost

**User universe (Problem) - What are the issues with current invoices? Hence the need for Smart Invoice**
1. Long payment terms which introduces business uncertainty & cashflow problems
2. Inefficient for DAOs which can automate payments via smart contracts

**Solution - How does Smart Invoice solve these issues?**
1. Escrow contracts: Start work after seeing funds deposit
2. Milestone payments: Escalating, multi-phased milestones
3. Arbitration: Funds locked, selected arbitrator to come in

<!--
1. Tells the story but doesn't illustrate how the tool works enough
-->

<!--
Image Collection for SmartInvoice

Create Invoice
Step 1: 
Step 2: 
Step 3: 
Step 4: 

Complete Invoice
Invoice Registering: 
Invoice Registered: 

View Invoice

Pay Invoice

-->

<!-- #### Notes from Documentation

1. No screenshots - hard to follow
2. No process - hard to know what steps are required
-->

<!-- #### Notes from trial
1. Step by step process is good
2. Maybe some fields can be intimidating
4. Good validation of fields for address, but edge case (if i put the same addresses, the transaction is blocked but no error message)
-->