At the beginning there was privacy and privacy only. Nothing else mattered. Users understood it. We didn't have to care about stability and UX, all we needed to build is privacy. We've done that and the next step was to make Wasabi a decent Bitcoin wallet that's stable and works. While the work on privacy and the work on stability can never be called complete, at some point we must say things are good enough and it's time to move on to the next thing. I believe the time has come to call the stability and performance work so I hereby announce we have achieved that goal, so it is time to think of the UX, too.

The UX work stands on 3 main pillars: Research + UI + Abstractions.

The research work has been ongoing since the beginning of the year, championed by @lontivero @nothingmuch and @seresistvanandras. WabiSabi will change the way we coinjoin. It will make privacy cheaper, faster, more secure and it will improve upon inherent limitations, like the base denomination. You might have noticed that currently this team is implementing the cryptographic primitives in this repository.
UI was a long running pain point and reason for constant criticism of Wasabi Wallet and now it is time to change that. This isn't a Wasabi issue per se, it's more like the result of the (otherwise great) FOSS workflow we're practicing, see: How Do the Open Source Communities Address Usability and UX Issues? An Exploratory Study
Usability and user experience (UX) issues are often not well emphasized and addressed in open source software (OSS) development.
Just to note one example is the "Next" button:

How did this happen?
First it was the "Generate Wallet" button and the terms and conditions checkbox was next to it. It was looking fine.
Then someone suggested "Next" should be a more accurate description of the button. We agreed (including me) and so we changed it. It was still looking fine although it started to look worse and it also ruined the cohesion of the software as the main buttons of all the wallet manager tabs were called the same as the tab itself: generate wallet, recover wallet, load wallet, test password (except the hardware wallet tab.)
Then we refactored the workflow of the terms and conditions and the next button became a terrible looking small, barely noticeable thing even though this is the very first thing a new user encounters.
This did not only resulted in a worse UI than it was before, but it also took a lot of development time.
There are numerous examples of bad UI results not only Wasabi, but also in nearly every other project that follows the FOSS workflow.
In the past, we have tried a couple of things to improve the UI situation, nothing really worked well. Our newest idea is to setup a UI team lead by our most experienced UI developer, @danwalmsley I want to give as much freedom to him as possible. I want Dan to be the dictator of the UI. Just like the Research team, the UI team reviews their own PRs and they can overwrite any of our decisions or dismiss any of our suggestions without reasoning when it comes to the UI if they see fit. Other team members include @jmacato and @soosr.
We may create UI PRs, review their pull requests, but we don't have to and they are free to, more encouraged to dismiss our points. There's a lot of work to be done and it's more efficient when most decisions are made with
expert instinct.
Of course, this freedom will be taken away every time before we release so we can make sure the software is well tested and ready for the release.
The UI team work starts right after https://github.com/zkSNACKs/WalletWasabi/pull/3925 is merged.
I'm going to elaborate on this soon, I'm just looking for the right place to do so.
Under the moniker of abstractions I identified the 3 main pain point of Wasabi compared to other Bitcoin wallets. These are: multi wallet, coin control and coinjoin.
We have the most advanced multi wallet managing system of all Bitcoin wallets. I didn't decide on having this, because it makes sense, but rather I decided on having this, because it was easy to have. This was a bad design decision as it's a distraction from working on privacy, but now we have this, it works well, so we should make it also look nice instead of removing it.
The main issue we have is having duplicated load wallet controls when the user opens the wallet. The fix has already been stared by designing a new dashboard, which should resolve it: https://github.com/zkSNACKs/WalletWasabi/pull/4317

In 2017 I wrote an infamous article: Coin Control Is Must Learn If You Care About Your Privacy In Bitcoin
My main point was that one must learn how to separate their pre and post mix coins manually, because otherwise they would just be clustered together. But Wasabi did not exist back then and this point can be addressed programmatically, in fact my proposed solution was separation of pre and post-mix wallets by accounts and "Privacy Improvement Suggestions" for spending rather than having a coin control tab. Although in Wasabi for some reason I decided that we must have a proper coin control tab, so we do have one. But this does not have to be the case. It can be almost fully abstracted away for post mix coins and so we should: https://github.com/zkSNACKs/WalletWasabi/issues/4337.

The gist of the idea is to:
Ideally the user would always mix and never spend non-mixed coins. Furthermore we should defer the max button's goal to after transaction preview. (User can choose to spend more or less in a way to not generate change.) This would be a privacy improvement suggestion after initial tx build.
Finally Coinjoin. The hardest part is to abstract coinjoin away from the user. How shall we do that? It's not that hard, in fact I have already done that before and I regret that I dropped the design decisions in Wasabi. Let's take a look at HiddenWallet:


There are 3 things to notice here.
I believe the current Wasabi workflow is the failure of the second system effect (in other words I f*d up) and we should aim to avoid it for WabiSabi.
The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.[1]
I agree with most of what was said here except for the new dashboard, it just adds clutter to the UI, maybe it will also add some time when starting the wallet.
I do think that most users won't use it most of the time, they would just start Wasabi and load their wallet.
This dashboard is inspired from Visual Studio's dashboard and personally I have never used it, but instead this is one of the first things I disable when I install VS and this makes it load faster.
@yahiheb compared to the background services, the overhead/loading of the dashboard would be insignificant even with its features fully implemented... Also i wonder why you think it's a clutter? it's a better alternative compared to our current wallet manager imo.
@jmacato I agree that our current wallet manager is not perfect (specially the load wallet tab) and should be improved,
but my issue with the dashboard is that I think it doesn't anything that benefits the user, quite the opposite, most users will have only 1 or 2 wallets and most of the time they just want to open Wasabi and load a wallet. Wasabi is a bitcoin wallet it is not a place to publish articles or stuff like that.
Let me ask you and the other VS/Code users do you use their dashboard? I personally never use it.
Personally i use the vscode's dashboard because my most recently used projects are there most of the time. It's supposed to be a shortcut to the recent actions you did with the app and i think that dashboard fulfills that. Anyways this is offtopic here, let's move the discussion to the dashboard UI PR.
@yahiheb I think you are right here, I have never used the dashboard and I have never knew anyone using it (@jmacato is the first one that I know) but the point is that this new organization is precisely to avoid having this kind of discussions. Software designed by committees and/or in by democratic decision use to be ugly. So, lets the UI team work and see what they come with.
Just chiming in to say that WabiSabi credentials removes many off-chain constraints, but doing CoinJoins with good privacy still requires many constraints and considerations.
A lot can be done to make CoinJoins simpler than they are right now for the mixing use case. Making arbitrary payments from a CoinJoin would also be posible. PayJoin-like transfers within a CoinJoin would also be possible, but complex to implement and integrate. Lots of details to work through.
I was going to post a bit more but I'll keep it short and save what I typed here as notes for a call or something. My hope is that WabiSabi in the longer term can help provide privacy in a way that is more welcoming to beginners, without getting in the way of advanced users being able to do more than they currently can. I am pretty sure it's possible thanks to some thought experiments and discussions with @johnsBeharry, @DanGould, @MaxHillebrand and others.
Some of this is on freeze now as the UI team will probably need us to not touch the UI for a while.
Some pics for those who missed it. Something like this can happen with the new MS fluent design:


This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Superseded by WW2: https://blog.wasabiwallet.io/wasabi-wallet-2/
Most helpful comment
Some pics for those who missed it. Something like this can happen with the new MS fluent design: