Rimble presents: the state of transaction states (Devcon5)
Devcon·Fri, Oct 9, 2020, 12:00 AM
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/rimble-presents-the-state-of-transaction-states Whenever we speak to builders they say "the most pain-in-the-ass part of making dApps is those pesky transaction states" (paraphrased). So we decided to do some of the work for you and now we want to share it. Over the last few months we've been turning transaction states inside-out to grasp the do's and don'ts of keeping users in the loop about their on-chain activities. And what this means for how you should build them. We asked ourselves: What do users want to know? What are they thinking after 2 minutes and it looks like nothing's happened? Should we use blockchain lingo? Do users actually trust dApp transaction messages? And what happens if you run out of gas? Plus, plenty more. Then we interviewed, designed, tested, demoed, iterated and repeated in order to get the answers you and every dApp developer needs. At this talk, we'll share everything we've learned and show you how you can turn these user insights into great user experiences for your own projects. Speaker(s): Ryan Cordell, Gustavo Esquinca, Zach Kalman, Sharon Kaziunas, Mike Lockwitz, Alex Singh Skill level: Beginner Track: UX & Design Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
Transcript
[Applause] cool so we're gonna have kick things up and thanks everyone for coming my name is Ryan it might be work for the wrinkled team at consensus and we're gonna be talking today about transaction states specifically the UX of transaction States but how much time to go into what we release right now that if you're interested it's kinda QR codes and that's all upside or follow the link I guess to set the scene why we're talking about this today our main user group are developers in this place we build components and write ballots to try and help dr. Belman remembers sort of improve UX allowable so we speak to a lot of developers we do a lot of research lot of interviews and something that came up sort of again and again as a penguin the developers was transaction states and house designer exactly so instead of one thing to sort of theorize around what might potentially make a good transaction stay to X we thought we try and uncover the secret to transaction to X and our own across these getting our hands dirty and going out to the fields do some research labs because on and it's kind of reminded me you know getting onto the tail that house that city or the trouble here at one and there's no relief for guessing who that might be it's Indiana Jones so beginning if the indexes all help us talk through some of the main problems around transaction works so first I'll never eat no transaction so what happens if a user trusts transact that doesn't have the required funds how do we help users get even how do we educate them on those needed and these fear the fact that you means ease to make these can leave a bitter taste and although transaction fees might be normal to all right this is something that's well often unexpected and unsettling the new users transactions can drag so compared to the sort of web to experiences we used to when a transaction might say minutes hours even days how can we help communicate what's happening to users and on that note how much should we actually explain about what's happening how much should we be explaining about why it's taking that extra time how much of the blockchain in general should we be shown to the users and how much should we leave behind the sins cherry on top of the cake is that of course they're irreversible so that's quite scary especially for new users if something goes wrong there's no chance to you know call customer service get things change and we don't want that leading to transaction regret or even worse very regret where people end up in the ecosystem is forgiving up there together and it's nice to have interesting sub a demo we come across quite often around the notion of education so it's a labor of do users know what they're doing and if they don't what they're doing are they incentivize sufficiently to go sort of educate themselves and make their best best effort at it so that's one of the main problems and completely understand why this is such a okay such a pain point I think it's important to also talk about the opportunities for sort of spending more time on to designing transaction states and hopefully this will convince any teams are there to maybe solve hit this up as a priority after they leave a sucker [Music] so that's that we talked about a little bit about some of the behavioral science sort of justification examiners so first up it's the halo event and its elastic it's probably complicated to solve an account for a service and that bad user experience will rub off on people's expectations for the rest of the service now this fighters maintenance is a compression we can certainly solving transactions and we still have the exact same meaning so if you user is exposed to it's really bad you know concrete like this for example it doesn't really explain what to do why he needs one little token to have this sort of quite confusing approval function woman it's gonna create a bad experience even if you know your doubt has been the coolest tech house the smoothest connecting connecting the wallet experience I think a great analogy for this is the Kingdom of the Crystal Skull movie which one that baby is tarnished the reputation of the entire franchise the pecan draw is very similar so two copies of bias impacts have people remember past events so these intense positive or negative moments each of the peaks and the final moments of the experience end and some calculus transaction was probably award quite often represents or end part an experience with a done and again they always have a very high likelihood of being either an intense positive or an intense negative experience so again this could really dissolve again if you have the nicest DAP leading up to the transaction then it really impacts these or how either remembers your that and they've read that sort of trust that you might have fostered up until that point I'm gonna shields mainly again but rip steam coming at the end of the bottom and moving into the franchise has certainly tiny stuff for me okay know right users eventually even trust work to you know so a study conducted by my Institute in twenty eighteen thousand they found that 28% of users abandon their tasks because of complicated check out blacks now the study also found that main reasons Bannerman was over the use of jargon lacked a visual design and I think at the moment obviously in these experiments will face of material and apps and this is quite often the case in in work for applications as well so again a really good opportunity it's it's over spend more time thinking about the design of transactions and make that bridge that abandoned and increase their trust into that okay so we spoking buses and problems and talk to us and the opportunities we're gonna show you a quick demo and then this is all come out of this or research and the design inspiration I mentioned earlier we spend the last two months speaking to some savvy blockchain users not so savvy try and understand what a bit that secret sauce to transaction yet being just a caviar slightly we focus mainly on darkness that might be trying to appeal to a more mainstream audience and try and reach that's all outside the brain so the demo is for potentially a Def Con application where I guess purchase your two kids as NF TS so my timer talked us through that so let grant said we build a lot of demos for user testing for this one we're using it opens up wins GRC 7:21 contracts we're using truffle for the contract management and deployment and then on the client side we're using drizzle to keep the blockchain data in sync the client side and we're using our own component system I believe I and some web 3 components that we build just to keep things easy and fast for us 12 and then we're extending bristle with third-party data that comes from just regular API services reason eath gas stations API to get a gas estimate that we can use to calculate a transaction fee and an estimated wait time based on just like what the average price of gas is going to be right now so we're using those two kind of key important pieces of information on the Eiger the transaction fee is what we're calling it instead of talking about gas and we're estimating that just based on like what method the contracts calling and the average price of gas at the time the same for the estimated wait time we can just kind of see how long transactions are taking at a set gas price and we're just assuming things and we're just kind of guessing for the most part obviously users can change how much faster paying for transaction but just keeping that expectation of threat is really helpful so I do like a quick diagram also like another technique that we're using here which is like trying to keep wet free away from the user as long as possible we don't want to hit somebody right off the bat with a connect dialog or we don't want to minimize functionality in the damage so like they've done some sort of proof that they are on Jane or they're connected to watching so once the user has expressed an intention that's when we start doing our pre-flight transfer you should have like a modern browser they have connected wallet but we're on the right network which were sure like those things are going to be can check their balance you can run a simulation on the call that they're doing you get that transaction fee then we can check their balance to make sure that they're gonna have enough money for what we're trying to buy and the transaction fee and then we can give them stuffs right there so even wait prevent them from even starting a transaction that we know is not going to work so once we have all that we'll give them not relying on the wallet UX is also like something that we're big believers in so we want to show the user before or right at the time of the transaction like as much of that information as possible so once we've given all that data over to the user they can make the informed decision to be confident that what they're doing is actually going to work and it's going to work the way they expect it to and then they have an idea of how long it's going to take so we'll just go through and it's basically okay though the heirs along the way if there's any problems that'll help remedy and then we finally finished it up with a summary of the transaction details that tell them exactly how much it costs and like where they can get more information either link to either scan or open C or something like that Thanks so I'm gonna dive a little bit deeper in soos or some of the more actionable tips that came out of this research in this demo so in the first lesson that we saw we came up with was to not rely too much on water collects a lot of data out there sort of thing oh we know the wallet can handle the transaction we just need to get the user to that point and the issue here is that wallets can't be specific and actually design the lots of different use cases and I'm within the damp itself you can talk much more clearly about these or the task at hand the users trying to achieve we should help reduce the sort of cognitive load on the user so for example we talked about the fact that once the transaction started is the process of participating send problem just so generic the transaction is pending law in progress this is specifically important error messages - you might be familiar with seeing sort of you know just generic insufficient balance messages of the and this doesn't really help new users or less confident users actually help sorry get back on track what they're trying to do that shims a lot of pre-existing knowledge which normal users are going to have so again within your data needs to be able to make and to make that effort in order to help users get past this popsicle and talk to end in context with what the users trying to do so you know how do not transaction fees in order to pay particular in this instance second lesson is around prevention so we spoke previously about the irreversibility of blockchain transactions to super important speeds or like Tessa pacing and designing for these sort of engines are errors that might occur so that would be like passive UI such as the indications in the top right corner about your wallet the users using their offices that I try and transact with into wallet but it also might be you know actually intentionally designing the some friction into this process so kind of is weird to say this quite often tells me reducing friction reducing friction reducing Clips reducing the nature irreversibility and we felt it was important to give the users final tunity to double-check everything written in a language that they understand compared to what it would be more technically unless specifically do we actually feel this is like yeah super important way they user can check everything's correct I made to be 90% confident transacting thirdly is to set user expectations so I guess the main places you want to say expectations here are around fees and behind me so again on this sort of checkout screen we reference the transaction fee at the time I think it's important to recognize the fee or wallet again this prevents it from feeling a bit like a hidden thing which I might end up the roaming trust in that I think a lot of the users we spoke to didn't have pretty great knowledge of what the transaction fee was so again it gives you much unity to sort of give that sort of explanation the users that don't understand there seems to be quite a general misconception that transaction fee is going to pick down teams themselves it's a network obviously isn't going to help and understanding what's going on and also the estimated wait time so might explains how we sort of done about providing that to the area I think that's really important that although users may not minds the way they don't like the Americans over live I wouldn't know long it's going to take so things very important to provide this information upfront so they can better plan well they might want to do next what about scrubbing off to completes on the tasks of course and wait and watch the transaction very the most important thing we want to do is give us a ballpark figure at least so instead of just a static message or a spinner as we we heard the some users felt or thought them and their transaction may be timed out obviously result in the user tries to initiate that which else about that state fountain that will transactions interest or their own lesson for is to provide just enough feedback and I think that the message here mainly it's just because you can get that information from the blockchain because you can call and find out in the transactions in the menthol that's being mined doesn't mean the user wants to know that or but it doesn't mean it doesn't know that in that way so if we like them this experience that we demoed so you might if you touch this baby on Amazon with something you plan to say it gets downloaded from the cloud into your actual device now you don't get a play-by-play of exactly where that content is in the journey that it takes down to your price and that's because the user just wants to know okay how's that process started is it happening as expected and when it's finished essentially and we found that a lot of users that we sort for this in front of you know didn't support of transactions go throw away so it's kind of redundant me to waste time you know crafting those messages about when the transaction event electro finally and design for next step so we talked about it where to about post purchase experience that's not as applicable in very necessarily where we have less channel 6's automation emails so I think the transaction the transaction success message is like a really good opportunity to do that and in order to design successful device versus experience you really need to know the actual end of the baby that has service our point our demo the end goal wasn't to just complete that transaction and always to go to the conference so this message is crafted in a way that explains these that what they need to do once the tickets man I met no wallet it also anticipates that the user may have been blind to get on the heart of my friend and colleague so again you get this spring water at the bottom here which is like if Joseph in it so you're anticipating what the user might want to do next and helping them achieve that problem again assuming they have a knowledge to be able to go into the wallet semi entity to a friend or colleague I think this is a really good opportunity to use more be persistent mobilizing a lot of taps are there help interoperability in mind so you can for example if you like that about you user to generate die for example that's not just how the message is playing is great but could die why don't we say great about the guy got an interest on that compound there's a real option the seeds or cross pollinating s users between adapts roll what can cause a similar vision there I'm just gonna hand back over to mine just a sinner I can't believe you saw my desktop I'm so embarrassed so a lot of it doesn't sound too novel might all sound quite familiar and I think that's the case we don't necessarily need to be reinventing the design of the new x wheel for web theory I think we might just need a bit of a collective nudge to sort remember some of the lessons we already familiar with privacy so I'm just going to hop over to - talk a bit about what's and more technological advancements in space company might mean for transaction notice so we went through traditional transactions and all that being said like it's great that we find energy into figuring this stuff out but honestly if you can get away with not dealing with these problems that's the best design solution so if you can abstract gas away if you can get rid of transaction fees if you can make transaction ten faster and that's within your capabilities absolutely do that so meta transactions is one example where you can just pay the gas on behalf of your users something like the gas station network or the FATA transaction tree light that lets you pay for users gas would get rid of one of the problems of friction points later two solutions was sidechains child plasma chains like bloom and POA third-grade they're fast they have really really basically free transaction fees so again you're not having to even deal with the whole transaction issue design with the developers from the very beginning so when you're not protecting your smart contracts use a proxy pattern that lets you chain will steps together into a single transaction for the end user there's future things coming state channels CK starts that will also let you do obtain if you hang in if you have the ability and the time and then the skill to get rid of transactions from happening that's that's the best way to deal with transactions but that doesn't necessarily mean lower device bones in the museum so just a recap something the overarching heuristics and the sort of foundation behind all these devices still very much it's all very much applies and I still always communicate with the context be specific about what the use of doing the tasks that they're trying to achieve plan for errors anticipate errors design error states help users out the jam don't just tell them this that's happening set the user expectations so always try and keep them in the loop make sure that they're aware of any sort of nasty spot potential Melfi surprises such as fees or not wait times but why just enough information just because you can provide the content doesn't mean that you should try and think about the actual information user needs at the time what is a progress through the general while you're designing and remember next steps you know try and avoid dead ends we don't want the user to be sort of okay very well I've lost I don't know what to do next so consider next steps whenever you're designing a float is probably and that's a again repair chest and plenty more about Rimbaud and scan the QR codes as well Twitter thank you [Applause]
Automatic transcript — names and jargon may be misspelled.