Joshua Rio ~ Debunking Design Myths in Dapps DDEX

[Music] okay so up next we have Josh who's a head designer at D Dax and Hydra protocol and he will chat about debunking the myths of design DAP design right that one so um Josh over to you hey what's up everybody obviously today I'm here to talk about debunking adapt design myths so there seems to be this this notion that designs or gaps can be poorly designed and have lackluster user experiences because we're early on in this technology we're still in the quote unquote interest stage and so I want to today in no uncertain terms basically debunk that and call there's no reason to have poorly designed adapts but before I can kind of move on and hopefully validate that I'll give you a little bit of a background about myself so I used to be a pro skateboarder believe it or not some of you might say cool well what does that have to do anything with anything and it just happens to be that when you fly off buildings and you essentially make a living flying down handrails and balancing on an inch of metal while trying not to over or under balanced by a pound avoiding death and dismemberment you get pretty good at either managing risk or ignoring risk and so those tend to be qualities that entrepreneurs have and so when I essentially retired at 24 I went on to then start a bunch of different companies and I built a bunch of different companies across various different spaces I tried to be able to personal operating system I built a military contracting company as well as a bioinformatics and so one of the themes that kept popping up as I seemed to keep working on these various complex technologies and had to find ways to simplify them into intuitive user interfaces which just happened to be one of the pain points for decentralized applications so what I how I got cited in the space was I'll try to use different products when I ran into different friction points I basically tried to fix those products and then I'll send them to the company completely unsolicited and see what they would say and so eventually I ended up getting hired by radar relay I ended up staying there for a little bit and then I moved on to then become the head designer at d/dx and Hydra protocol where I'm at now one of the interesting things about d/dx and Hydra protocol is I get to work on products both at the protocol layer and at the application layer so if you don't know DDX is one of the top decentralized exchanges and in Hydra protocol is essentially a protocol for performance based decentralized exchanges and so by virtue of this very symbiotic relationship where we have an application and then we have a protocol and they each feed into each other I've really had the honour of being able to work across a number of different products so in the last 12 months I have designed browser based apps native iOS and Android decentralized exchanges responsive fully featured decentralized exchanges dashboards iframe embeddable instant trading voyages develop a documentation onboarding flows custom wallets and now something that I'm working on is a multi-chain mobile based decentralized exchange which is a mouthful but easier to design than it is to explain so when I was thinking about what I could do today I thought I could probably teach people how to design decentralized exchanges but I didn't feel as though everyone would find that valuable I thought about you know picking some products and trying to point to good things and bad things but I didn't feel as though that would lead or leave anyone with anything tangible so I thought the next best solution would be to basically mock up a fake product and walk you through at least the way that I approach designing these products because when you're working on so many different products you least have to have that method to your madness or a mental model and so that's what I want to share today so the concept is going to basically be this it's going to be a very small subset or a feature set of a much larger system in this we're going to essentially talk about letting a user transfer tokens from one address to another and while admittedly it looks very simple in a very quick fashion we're going to go over error handling form validation handling local and global state different types of micro interactions different types of foreground/background push notifications writing micro copy thinking in terms of third-party wallets and how to make that experience for your users simpler as well as diff different input accessory accessories and using smart defaults so we're going to make an assumption here that there is an underlying interface you can't see the user has basically clicked on a transfer button of some sort and then a modal has basically popped up and so when a user basically sees this or a stakeholder or someone watching this sees this they see this type of interface for myself I see this and so this is basically my mental model whenever I come into designing any type of product I know for a fact that I'm going to need some type of inline foreground notification these take the shape of toast little drop-down banner notifications it could be push notifications they also have different states such as your pending success some warning states and but we'll talk about more of those in a little bit I also know that we have to have an action title in some kind of descriptive microcopy that helps you use it understand what they're about to do and framing their expectations I also know that we're going to need at least three different forms and all of their various states and then I also make sure that if this is a transaction where a user having is having to sign something we also have some type of wallet message in there then obviously we have a couple of buttons that allows a user to enter or exit in or out of a flow so moving top to bottom it's almost offensive that this is here but I see products over and over again do this wrong they don't have a title they don't have a description they don't frame the current action that the user is going to take and this is an important thing to have because as you're designing responsive systems you never know where a user is going to be using your application and where they're going to be triggering something from for example that this is on a mobile device and a user clicks a transfer button and this modal pops up there's going to be enough content in this modal where it's going to abstract the entire view behind it so if you use it doesn't know where they're at you're going to need to tell them so how I tend to handle this is I just take a very basic description I just basically describe the action I just say you're gonna transfer tokens and then I give it a description underneath that that then almost tries to describe the interface below it and now I'll fully admit that this isn't the tightest microcopy in the world it's not amazing you can play with all the cadence and the tone and all that kind of stuff but it's good enough and I know it's good enough because a user can read this in plain English and in absence of the rest of the interface they know what they need to do they need to transfer a token by adding an amount a token and a recipient address so once you've handled your microcopy kapur correctly then you can play with all the fancy stuff like your font weights Heights and colors and all your vertical rhythms and all that kind of stuff but that's not too important right now next when you're handling tokens it's a best practice to have both the ticker name and the project name there is no way just to own a ticker outright and so I know this for a fact that there will be clashing project names and tickers we have this at Hydra where our token is called hot and then there's also a project called hollow token who has a token called hot and then there's also another project called Hydra protocol as well and so in the interface you just need to basically handle this and make these exceptions and some people might say well I just like to be as concise as possible I just want to have the ticker in here I don't need the project name I'm manually reviewing my tow but let's say that this took this token or this ticker isn't it may be in your top 20 tokens maybe has a thousand dollars worth of volume and then let's say that I like this ticket because it has a great name I would just pay you some money to drop this ticket and drop this token and then list my token and you're going to do that because I pay you enough money to do that and then if you're not handling your project names you're gonna have to chase these exceptions around your product and basically making these manual Flags trying to basically correct or help users understand that this isn't the old token this is this is a new one so just use tickers and project names when you're handling an amount there's a few things that I like to do here first I always like to put an X amount in the or the next amount that it uses it heads in the amount field as an assistive label and the reason that I like to do that is because I don't want to use it to abandon a flow I don't want to use it to have to exit out of this go to their wallet see their balance then come back and enter into this modal all over again I'm a strong believer that you just keep user in the flow and within that flow you give them everything they need to complete an action another thing that I see projects do is not use placeholders this is kind of form design 101 so always put your placeholder in there that is descriptive another thing that I like to do is give users the ability to have some kind of smart defaults and so in here for the most part what a user is going to be doing is sending a max amount of their tokens basically sending them all out at once but I also like to give users the ability to send a small percentage of their tokens and when I do this I like to have both a percentage as well as the actual token quantity itself and I find that this kind of assistive thing whether you implement it or not at least and communicates to a user that you find this valuable I'd let you find them valuable and that you're trying to make their lives easier regardless of whether they're going to use it or not next addresses can be a little bit funky to handle it's essentially two ways to handle an address one of them is long addresses and the other one is shorter dresses and you can do something in between so I think that this is basically optical gibberish it doesn't make any sense it's it's it's difficult to read and most users gonna look at that it's just gonna look like a blur of characters and so what a pattern that is starting to emerge is these kind of short truncated addresses where you basically have the first four and last four characters of a wallet of an address sorry and it just makes it a lot easier for a user to be able to understand and this is actually a pattern that's very similar to handling credit card forms where you have the last four digits and a user just has to kind of quickly verify just a small section of their of their addresses another thing that I think is really awesome is Wallet connect we use that indeed X and it's just a very simple way for a user to be able to automatically scan an address and then input that address into here typing these things out is a pain in the ass and most people are going to copy paste them QR codes or QR scanners on a big deal in the West right now but if you've ever been to China that basically use for absolutely everything especially if you've used or if you use something like WeChat you'd know how how valuable and and how useful of a tool QR scanners next this is something that pretty much everybody does wrong which is handling errors I call these essentially local errors and the local error happens on a local component and I've seen these error messages either not be shown or be shown and kind of these little toast pop-up messages which are just terrible I've seen them put them at the bottom of the forms I think it's just the best idea to basically put it on the same line as the label if you're kind of constrained for space you can also put that underneath at the input as well a good error message also needs at least three things it needs to identify the issue needs to tell use it how to mitigate that issue and then it needs to be written in plain English so you don't want to be telling someone or giving someone some kind of like code based error message just think about how you're going to communicate to user the issues that they'll be facing on any of these inputs the next thing that I think is also very important and I don't think many many products take into consideration is thinking in terms of third-party integrations and so when you're using adapt you're usually going to be usually going to be using something like a meta mask wallet or ledger but I can't count the amount of times that I've had issues with meta mask where I've clicked on a button and then the modal hasn't popped up and so likely I keep clicking the button thinking that the interface is broken and then I see a slight incrementing on the notifications up in the browser window and this is a relatively difficult thing to deal with but what if one of the things that I personally like to do is to think about the wallet and then describe that interface and then tell user some of the issues that they might be running into so in this example this is something that I would do assuming that the user has made a mask installed so this basically this assistive message says upon clicking submit you'll also need to confirm within the meta mask if a window doesn't pop up click the meta mask icon in your browser to complete this transaction again this could be much tighter we could do a lot of different things to make this microcopy better but in this two line sentence basically what we've done is we've essentially identified any of the potential issues that a user might have and told them how to kind of mitigate that and so you're going to need to do this for you made a mask as well as your ledger wallets and anything else at you that you want to integrate next - and transaction fees there's many many different ways to handle this you could do it like this where you have some kind of drop-down that allows used to pick between different speeds for gas one thing that I'm I firmly believe is that we shouldn't be showing gas limits in an interface I think that's far too complex and we need to figure out ways to kind of abstract their complexity away and just give a user smart smart default basically and so when I look at this I say there's a few different elements first we have the speed we have a time and then we have a u.s. a u.s. value before this transaction fee I personally think that this looks a little bit too complex and I think this is one of the troubles when you're trying to simplify an interface is that you can essentially by trying to make things simpler you actually make them more complex there's definitely a point of diminishing returns when it comes to simplicity and so you want to make sure that you kind of kind of almost refactoring the design and these components as you're walking through them to lower the cognitive load on a user so it'll just looks completable to them so I personally wouldn't go with someone something like this I'd probably go with something a little bit like this where instead of kind of letting a user pick the different speeds I just say how long it's going to take and the approximate cost in just in microcopy basically I think that one of the products that really does or handles gas and transaction fees really well is balance they have a pretty intuitive kind of feature on their wallet where you can just again pick between fast slow and average speeds and I try to steal that as often as I can in any kind of product that I'm using cuz I think that that's a really awesome feature another thing that I I see a lot of products not doing is handling their form validation and so what will happen is that they won't validate the form and then once they user click Submit then they'll throw an error that's kind of not how you handle forms right so you should be you should be validating each input as a users moving through it and throwing an error message whenever a user puts some kind of invalid value in there one of the things that I personally like to do I think which is the quickest win is just to put an opacity on the label of 50% and then throw Ackerson not allowed on it just so a user knows that they cannot click on this button there's also some other cool little micro interactions that you could do here you could do both and unclick in an on hover event for the submit button so that when if there's an invalid form like an missing address when they use a hobbles of clicks on the submit button that then throws that error all over again and the user can then just move up quickly and enter in that address and then move forward once the form is valid I just basically turn usually the label back into a hundred percent the passive 0 / 100 percent opacity which is a nice little subtle gesture I think the next thing that I think a lot of depths need to think about is just the different states for the application and to be mindful of how that interface needs to respond to those different states so in this example here the user has gone through putting the appropriate information of click Submit now this user is now in this example up in meta mask confirming this transaction and so the button should go from submit and then basically communicate some type of pending state and another thing you can do here is just disable it so user doesn't try to submit that transaction all over again this is also something that I very opinionated about a lot of depths or applications aren't really handling kind of inline global errors or global notifications so a pattern that I see a lot is that a user will submit an action or a transaction to the blockchain and then the app will show some kind of like little translucent toast message that pops up in either the top left at the top right of the screen I personally think that those are it's a very poor practice because if a user is at the computer and then they get a message on their phone they glance over to their phone or they go to get a drink or go to the restroom they're going to miss that transaction and so that interface isn't communicating to the user that's something something happened and so another little mental model that I like to think of when I like to use when I'm thinking about notifications is there needs to be four elements there needs to be a trigger there needs to be a notification type there needs to be a place to retrieve that notification and there needs to be a way to archive that and basically clean it from the view so in this example the trigger would be the user click clicking submit within meta mask the notification would be some kind of foreground notification it could also be a push notification and then there would also be a secondary activity center where the user can come back in and go through the historical transactions and then we give them the ability basically to archive those remove those from the view same thing with global arrow States in this example this is this is not actually the best example because once their transaction would have been submitted this modal will have presumably disappeared but I'm just trying to kind of articulate how you could handle a successfully trends a successful transaction and so a couple of things that I always like to do is basically reconfirm with microcopy that their transaction was submitted also give them the ability to view that in some kind of block Explorer like ether scan and then also let them know that they can review this notification in an activity center later on lastly Claire your forum state once a user has submitted a transaction make sure that you just deleting or removing all of the token the amount and the address and whatever other information is in your within your UI it would defeat the purpose if we go through all of this effort to make you know easy to use amounts and we describe interfaces we use a really tight micro copy and then we just leave the inputs with their with the data in them because a user is just going to view that as it wasn't submitted and they're going to click Submit and it's going to be frustrating and lackluster so I guess the main takeaways is that things are going to change within your product within your interface within your business they could be regulatory they could be competitive threats they could just be features being added or removed and so you need to architect your applications in a way that are very very flexible then which it's kind of easier said than done but at least aim for that the next thing is that context is king it is important that you understand how a user is using your application not just within the application itself but within the environment that surrounding them for example when I gave the example of you know a toast notification popping up and in them glancing at their phone and then missing that notification so just try to keep the context of the user in your mind as often as possible second to last is this is an early space I don't think anyone's necessarily winning at this stage so if you see something that you like in terms of UX a UI just either beg borrow or steal I see little cool things all the time that I just I take because I think they're really interesting UX innovations like balances gas-phase so I think let's go at the end of the day you just need to keep it simple don't try to overthink it too much and just stick to traditional web 2.

0 best practices lastly these are some of the the I guess on the left some of the people who I think the worthy of a follow and then on the right hand side some of the companies that I think of doing innovative designs and thinking about UX in the space differently if you're an engineer you're probably going to want to follow Beltran who's lyrical polymath he's basically trying to write the web three design standards and it's someone who I personally look up to and basically take his word as as law and then there's obviously lots of cool companies like balance and Dharma's little widget that they just put out and all of their products look really good as well as porous and consensus design as well as wallet connect lastly if you want to follow me that's my Twitter handle it's Josh underscore rear if you ever want to send me an email it's just Josh at DX dot IO and also give DDX in hydra a follow because if it wasn't for them I wouldn't be standing here and I wouldn't have had the opportunity to work on lots of interesting products and lots of cool things and to be part of an awesome community and I am finished [Applause] we do a question sure cool hey Josh what would you say is like the biggest pain point in crypto in general when it comes to design like what's like the cardinal sin and what is the hardest thing to designer hmm that's a very good question the hardest thing I actually think the design is the easiest thing because if you keep it simple it's not that difficult I think one of the hardest things is communicating to all the different stakeholders within their project what the trade-offs are and so DDX is a very interesting project where we have both a Chinese office as well as a u.s. office and so Eastern and Western design philosophies are fundamentally different and so a lot of the time I have to find ways to communicate Western design philosophies to the eastern team and then Eastern philosophies to the to the Western team outside of that I think that it takes a lot of courage to design simple things because you have to toss away a lot of a lot of different stuff it's safe to be complex it's much more riskier to build a simpler product so I'd say probably the hardest thing is taking the risk of making things simpler and hopefully that answers your question yeah right about the a theorem addresses so what do you think of these like pictorial representations about the 8th avatar or something have you used those and what do you think of those are they usable artists I haven't used them myself I do see like little avatars up in made a mask but to me as you use it they don't necessarily mean much it just it looks like a placeholder avatar and I don't like is it like less like a fuzz than the long address of characters I think anything is better than a long address I think E&S will obviously probably help with that at some stage but I don't think that we're necessarily there yet and it doesn't have the adoption that it needs but I think any type of innovation whether it's an avid or Gravatar whether it's a short address or whether it's something else it is yet to be invented will be beneficial