Thanks for the phenomenal piece of software which is BISQ. I just want to point out the following negative aspects I have experience in the spirit of feedback to your UX specialist:
The situation:
Two of my trades got mired down for over 48h in blockchain verification during the recent blockchain spam attack / congestion. (This has now resolved). In both, I am selling BTC for FIAT. During this time, one trading partner opened a support ticket, and I did the same using ctr + o for the other trade. The arbitrator response was good, and I was pointed to the “don’t panic” post on the support forum. At this point, I have a red “2” indicator both on “Portfolio” and “Support”.
Since blockchain verification, I have been regularly checking for progress on start of payment. My indicators have not changed, so I am waiting for “Confirm Payment Recieved” to go green in my “Open Trades screen”. This does not happen, so I am feeling nervous. By pure chance, I flick back to my support screen and see a new message for both trades by the arbitrator that FIAT payment has been initiated (Great!!). My trades are all good, my trust in BISQ is secure, but my UX has not been optimal as confusion and doubt were part of the process.
To put this as more concise suggestions:
The nomenclature between “support ticket” and “dispute” needs to be clarified. I was not expecting a “support ticket” to end the automated workflow and put an arbitrator in charge of transaction handling. I am still unclear if there is a difference between the two. I also don’t want my trading partner to think that I am disputing any action of theirs. I purely opened a support ticket to notify the arbitrator and my trading partner that I intended to proceed with the trade despite the technical delay.
Indicators should identify items that are new and not seen by the user. I know this can be complex in practice, but maybe something like the numbers working as the do presently, but the colour only goes red when something has changed?
Thanks for your feedback on your trading experience and your suggestions!
@dispute/support ticket: This is confusing at the moment indeed as there are only “disputes” at the moment, which are displayed in the the support section. So there is no difference between the two. We’ll streamline the wording. Besides creating a dispute manually or automatically, there is no communication possibility between the traders atm, only through the arbitrator. The reason behind this is to prevent any trade party to try out scam tactics through this communication channel and also to prevent flooding the p2p network with messages. What might make sense is to offer pre-defined means of communication for this kind of situations.
At the simplest level, when the arbitrator posted an update, the colour on the “support” indicator could have changed to let me know that something new has happened.
True - now I know what you mean. We could think about only showing it, if there are news that haven’t been seen and reset it after entering the section. So it behaves more similar like on e.g. mobile apps. I’ll put it on my list.
Scam tactics will always be a problem, even when answering the telephone or emailing a bank, or walking out my front door and saying “Hello World!”. Maybe a micro transaction fee for each message + only possible between trading partners + monitored by arbitrators could discourage fraudsters and prevent flooding?
I feel that there is a very real UX issue related to transparency in communication, support and arbitration. This will only become more taxing on your human resources as the trading community grows and ways need to be found to discourage escalations caused simply by people not knowing what to expect and what is happening. This needs to happen without people having to read the white paper or having to go to the forum.
The thread I am linking from is a good example. Regardless of whether the user’s issue is founded or unfounded, there is a need for both contractual parties + the arbitrator to be privy to the same information. Also, both parties need to feel that “something is happening” in a timely (or at least predictable) fashion.
To illustrate with my experience, I had two identical disputes in parallel (which were technical and could have been support issues) therefore not complicated in nature. Both were resolved (so credit where credit is due). From the critical point of money having been transferred to one party (FIAT to my bank account) the disparity between a 5minute and 20hour ticket time closure is sure to make anybody nervous and concerned that something has gone wrong. This type of unsurety can lead to panic, loss of trust and angry words on public communication channels.
I am an early adopter of many things, and what you are doing is phenomenal. I am interested in the details and failsafes of systems (automated and human):
While it is understandable that complex arbitration takes a long time, what failsafes are in place if an arbitrator should become physically unavailable (systemic redundancy)? Is there anything in place to prevent simple arbitration issues to backlog behind more complex ones? Have you a strategy in place to scale if there were a surge in userbase?
Also, it needs to be asked that if a high proportion of disputes on what is set to be a high volume trading platform, become complex, is there maybe many other critical problems that need resolution? I have no stomach for the potential of what should be a simple trade taking up months of my attention.
I can see these types of things becoming make or break for Bisq reputation, but also hope that my comments are taken in the spirit of identifying problems and finding solutions.
I can assure you that the arbitration process, which is a core part of the Bisq exchange network, is in our focus and we’ll do everything to reduce the necessity to create a dispute at all.
More detailed information on arbitrator/arbitration and fallback scenarios can be found here:
If either trader is not satisfied with the decision of the arbitrator, he may request a second and final arbitration round, performed by a senior arbitrator. The latter reviews the available evidence and renders his decision. If the original arbitrator is found to have behaved dishonestly, further steps are taken to penalize his behavior, based on the severity of his fault.
There is a plan in place also how to scale the arbitration process which of course is difficult to align with short term high spikes in trading volume or arbitration cases caused by other technical issues (delayed blockchain confirmations) like we saw recently. In short term we’ll focus on finding a way how to increase transparency during BTC blockchain spikes, so every party of the trade knows whats going on. One way to solve this is to improve the dynamic fee calculation, so all transactions will be confirmed more quickly (of course this will cause higher mining fee costs) and/or displaying the expected time until confirmation based on third party services like https://bitcoinfees.earn.com. We could also think about offering a status page on the Bisq and the Bitcoin network and send a push notification to the clients when we monitor network spikes, that might cause this kind of behavior. Of course also to enable some kind of communication between traders could help reducing arbitration efforts.
As you can see there are a couple of options we are considering at the moment and will implement as soon as we’ve decided. Any ongoing feedback and ideas from your side are of course always more than welcome!
Yes, this is exactly what I think the software and system can improve on by design, and what arbitrators can improve on by experience and training.
From what I observe in the “Market” information from Bisq, you are averaging ±22 trades/day for the month of Dec to date with 2 visible arbitrators.
My own experience has been appropriate for an early adopter trading on an early release platform, but this is a use scenario which is likely to change rapidly as has happened to major centralised exchanges recently. My suspicion is that a high percentage of recent trades ended up in arbitration unnecessarily, and this will happen again for reasons we haven’t imagined yet.
As practical workflow suggestions:
Be support focused, not a binary nothing/arbitration option. Trader 1 opens a support ticket which does not stop the automated workflow. Trader 2 and the arbitrator are notified of the details in the ticket. Trader 1 pays microfee for support (maybe something like $0.20 from trade security deposit)
A pool of arbitrators see the ticket and any of them respond within limit (maybe 1h?) that arbitrator xyz has been assigned and has y tickets in their queue. Expect about x hours for a response. If this is a dispute, please click on “open dispute” (which is now visible option in the GUI with a countdown till active of maybe 1h cooling down time) and be aware that this will halt automated trading flow and may take days to resolve.
Trader 2 is now aware of what is happening. They are able to respond to trader 1 and arbitrators ($0.20): “No need for dispute, I can see that the Honeybadger was bitten by the snake but will get up soon, no need for a dispute yet. Have a look at bisq.community/abc”
Time passes, everbody knows what is going on, nobody is throwing toys out of cots or pulling out hair! The problem probably resolves itself, or the arbitrator is able to identify a software bug and provide a solution or pass it on to tech support.
I bet you @christoph 0.1Btc that something in the spirit of above is going to reduce the need for arbitration by at least 90%, allowing you to scale efficiently with 0 staff increase.
Even with the workflow as it right now, I think that you will see a significant increase in user satisfaction if arbitrators are trained to simply respond promptly to both traders with “We are here, we are listening but are working through a significant queue”. Repeat this message with slight human language touches every 12 hours if needed. It is important to understand that the traders are dealing with (for them) large amounts of capital on a new and unproven system. They have a right to be nervous and need to be reassured.
The problem probably resolves itself, or the arbitrator is able to identify a software bug and provide a solution or pass it on to tech support.