Making Product Development Rock with Awesome Developer Experience (DX)

Transcript

[Music] hi everyone uh it's so good to be back here at eth prag this is the only conference that I had a dog in the audience so it has a special place in my heart um yeah so today we're going to talk about um web three product guide to the DX Galaxy so I am Sasha tanasa Luca I am a product designer and a researcher I am one of the co-founders

of the web 3ux user research panels and currently I am a research opset thesis with a focus on meso Network which is an economic layer for Bitcoin in the past I led the ux and Design research for the threshold network uh and I was part of the team who built tbtc the first fully decentralized representation of Bitcoin on ethereum I like to say about my job that uh I transform extremely complex products into palatable bits but you can also imagine me as a psychic that is channeling the users voice at a product sance Okay so so today's talk is an

onboarding to the DX and devil Concepts and it's supposed to spark curiosity is not a step-by-step guide however it provides some best practices so this this talk should be helpful to anyone who is building developer facing products in web 3 like uh this can be new new l2s new blockchains new networks Dev tools integratable protocols and whatnot so um before we start I would like to get a raise of hands of who knows what DX is oh wow quite a few people good next slide

please so developer experience is the equivalent of user experience when the primary user of the product is a developer a developer is a highly technical user user profile and sometimes this might become an excuse for having overly complicated user Journeys which lead to a traumatic experience so let's shake hands with the shadowy super mythical creature that we have all heard about but never met the almighty developer wearing the power user cloak he knows everything and can read minds so he never needs explanations Jokes Aside due to the fact

that developers are more of a technical Persona the product ux owners end up considering developers as power users so power user is a very deceitful term that makes you forget that developers are normal users too and they will just appreciate and benefit from Simple Solutions just like everybody else let them understand a few things first they have the potential to become power users but they are not power users when you first present a tool an SDK a library so it takes time so in order to build a developer Centric product you need to make sure

that your product is taking into account the following best practices developer needs and user experience so why should we care about DX in web 3 well based on um the Electric Capital survey from 2023 uh 22,000 monthly active open- Source developers contribute to crypto so we need to remember that developers are are at the core of our ecosystem user base ethereum consistently attracts 20 to 25 of new developers coming to web 3 which means that ethereum is onboarding more

developers and the need for straight forward processes may be higher than ever a positive DX can increase adoption and retention and the growth of a chains developer community so let's look at uh github's DX impact on collaboration formula uh this formula takes into account productivity how simply or quickly a change can be made and the E of use of the implemented code plus impact how frictionally is to move from idea to production plus satisfaction how the environment workflows and tools affect developer happiness all together

multiplied by C where C stands for collaboration equals developer experience but let's narrow it down to web 3 so over time in web 3 we kept saying that oh ux is the problem this is why blockchain is not adopted we realized that the users most of the time are other developers thus it's important to learn how to onboard and improve the developers experience there are a number of areas where DX is relevant and it can have a huge impact in web 3 so let me help you with some examples sdks provide abstractions on top of smart contracts

or complex systems that allow the dev to build something on top of the current system without the need to know too much about the internals so for easier to understand Unis swap swaps B economy account abstraction tbtc threshold cryptography then we have Smart contracts like lots of projects don't have the resources to build an SDK on top thus the design they initially make matters more than originally intended and then blockchains how do you integrate build query the blockchain and then in the end web widgets which are small pieces of a website that leave

within your application so the effort of supporting the user should be done as soon as possible uh during the design process instead of after when the user is trying the product and failing this allows you to focus more on the product instead of onboarding new users so let's look at the developer Journey I made this diagram uh of the developer Jour Journey inspired by the design design counil Double Diamond methodology but adapted to DX so developer Journeys are more often complex and longer so imagine developers

are daily recurring users of your product they require continuous interaction and repetition with the product in comparison with other user Journeys like let's say the oneof user journey of someone who is is setting up on wallet they set it up once and that's it also developer Journeys are more complex as other factors such as requirement changes or dependencies on other developer tools protocols chains cause deviation from the path so however seamlessly as it may look um the developer Journey will be scattered with friction points let's take this example we at mees are

building a new network we want different protocols to integrate our Tech the first thing we need to do is to identify the possible friction points and the several external and internal touch points where the developers will interact with multiple aspects of our product so this may help us identify the diversity of roles at each touch point that can help optimize improve and create a better overall developer experience so let's see how um friction may look like in the Ida phase so most likely in this phase we can have a tool compatibility issue like limited or no support um for developer development

tools like let's say Foundry or hard head for the new network uh this friction Point affects the initial ideation phase by introducing uncertainty and potential higher costs in terms of um time and resources needed to either adapt existing tools or create new ones so Teamwork Makes the Dream Work I know it may sound cheesy however good DX just like good ux is not a job of a soulle individual it's a team effort where the outcome of having good experience is embedded in the entire company

culture so there are many roles under this uh DX and devil umbrella however I would like to detail three roles in particular uh the first one is the technical writer their job involves creating updating and maintaining documentation for technical processes products or Services they also do editing Assurance quality assurance and read proofing they collab closely with engineer product managers ux designers and support in order to continuously update and improve the docks and the docks are really really um important these are like uh I haven't added here I

put together a survey uh recently and the top biggest pain point of developers was poor documentation so technical writers are a gem um uux designers and DX researchers these roles are crucial for the DX team because they have the knowledge to design good flows measure the success and Implement feedback loops bringing the vast ux methodology to the table they can apply qualitative and quantitative methods to harness information that can feed back into the development process that will lead to refined user Journeys for the developers so some methods that I can um bet my

life on are the diary studies um in my entire experience I they turned out to be the most holistic type of testing and replace the clunky lab tests um also you can do remote interviews remote usability tests Guerilla tests at conferences least recommended uh and also dog footing it's super super important um and the best way to test out if your documentation is uh doing great or not you can add some analytics on your docs and then you will have data um also I would like to speak a little about Devils or de evangelists how I like to call them uh this role is at the

intersection of software development marketing and Community engagement this person or a group um is the UI of your product the human walking UI their role is to create uh proof of concept educate and advocate for the products at meetups podcasts conferences and hackathons their goal is includes raising awareness and creating and fostering relationships between a company and its technical audience for us developers and Technical stakeholders they are also the perfect link between the product and the developer community and they can harness feedback in C2 so DX and devil are often mentioned

in similar contexts so there is a need to understand the differences between the two since the Deval team interacts directly with the developer Community it forms the human component of the ex there is an overlap within between them but they are not the same uh so the X involves making the product better in its entirety devil is about taking this DX to the community effective Devils Engineers convey empathy towards developer needs gather feedback and insights which the product team will feed back into the experience to make it awesome there is no good DX without Good Devil and no charismatic devil without the backing of amazing

DX so if you want to implement grit DX uh inside of your company I advise you to delve deeper into this guideline that uh Daniel Luca and myself put together last year um grx framework stands for good documentation robustness error handling accessibility and testability um you have a QR code that you can scan and then you will uh have access to the framework um cool and then when you go back home these are the ideas that I'd like you to remember from this talk

DX is ux for developers DX is a team effort and not the responsibility of only one role exceptional DX is the Synergy between the DX team and the DeAngelis team and the great DX framework if you want to fight a good fight along with me and make web 3 a better place for everyone you can enroll here and participate in PID ux and DX studies with web 3 ux this is the user research panel that I was telling you about earlier and then if you want to read more learn more about it you have um all

these uh DX resources the first two ones are the two amazing applied DX research so you have the Edom block Mina research diary study and uh then you also have the threshold Network tbtc client code diary study and you have there the meth methodology and uh the report so you can um use it and apply it in your developer homes as well yeah so in the end don't forget to love your users even if they're developers thank you [Applause] I think we have uh hit the part where

you can ask me questions and I can maybe give you answers all clear cool oh yes phenomenal good examples ofor that's that's a very good question I don't think there are any phenomenal examples okay um but uh I think we're starting to have make a better and better job and yeah sweet yes what would you so I as examples to to build like a

good documentation good documentation um what are good examples I would uh direct you to the threshold Network and uh to the tbtc bridge documentation uh they and especially for how to set up a node if you want to become a Staker they have a really really good stepbystep guide and I think that is a very good DX uh documentation example they have Snippets they have everything and it was backed by research yes maybe one follow up like any big projects that you feel like have really bad documentation it's like a negative

example to use to build something oh unfortunately I don't know any so can't point fingers at anyone but I think when you're stumbling across bad documentation you will feel it it will be painful and you will know okay yes yeah one more question oh sure right here yes um yeah sorry um how would you handle releases well so that developers are aware of new version releases or API changes or anything as such excellent question um we actually had this issue for the client code and um we have realized like my proposal was

to just put it in the client logs because most of the uh people who are staking or are node operation operators are going to look at the node logs so I would put them there in order to make sure they know there is like a new release uh a new client release um and I think this is the easiest and truthful and direct way that you can talk to your actual users but you can also uh have uh joint efforts with uh newsletter in Twitter GitHub repos everywhere you can make sure that they understand but my go to is just like EDI in the logs they

will read yes so from your experience as uh like in terms of developer experience for Web Two web 3 certain like uh tools or like sdks would exist like even for both like for open source projects so any observations in terms of like using tools such as Nelson's heris sixs uh other like uix uh tools that like things that we need to keep eye on when we are developing for web 3 developers like that are different from Web Two developers I I think the fact that uh the environment and ecosystem changes are like much much faster than u in web

2 where everything is just like stands there and we already know about it I think we should uh maybe do a better job with this making sure that that uh we educate the developers with all of the new tools that are supporting the ecosystem changes yeah just one more question sure I love it thank you um do you have any tools you would use to generate the documentation directly from the code for instance open API 3 or any anything else that you think works well um I don't know but I think like

even if you would generate it directly from the code let's say this would be the first pass you should always actually have a tech writer and then test it out with users and see does this make sense and it's important to test it out with users outside of your uh Team because they they are unprimed unbiased they don't know anything about it so they will give you really good insights and you will find the the friction points in your documentation and where it doesn't really work do you see something similar to postman or rapid API in the wet 3 space where it's just collections collections

of apis or whatever it is um and you can sort of search among those I cannot answer this I don't know thank you sure any other questions okay thank you so much thank you guys [Applause]