Notes from Radiating Circles of DevX by swyx
This talk from Shawn Wang (aka swyx) provides mental models on how to think about Developer Experience.
I'm writing non-exhaustive notes for this talk so I can remember some of my favourite ideas but I recommend starting with the original.
You can also find Shawn's slides here which I've screenshotted extensively.
What makes an End to End Developer experience
Docs
Power users notice missing things
When you're a power user of the platform and using the docs and constantly realising there are things you look up or have in your head.
For instance, Shawn noticed some environmental variables he was always looking up so brought them all together. And it made its way into the docs.
Understand what users do not know
By speaking to lots of users, the DX team finds commonalities in what users do not know and identifies solutions that might solve it.
Content
What are your goals? Every goal has a tradeoff
If you focus on topical content, it's unlikely to be evergreen. Do you want brand recognition or measureable actions?
Integrations work well with content
At Netlify Shawn helped write code for Netlify Dev. This launch was very successful and also meant he could write lots of authentic content as he helped build it.
Community crosses the chasm
This was the most profound lesson from this whole presentation for me.
Some developers will adopt technology because it does a job.
But many others - the mainstream market - care about things like:
- What are the job opportunities with this technology?
- How is the third-party ecosystem (e.g. libraries)?
- Do my friends use it and what do they say about it?
Crossing this chasm at an early stage is a huge challenge. Community building builds social proof and momentum so that the mainstream market feels like it's not such a risky technology to adopt.
What Developer Experience is
Developers don't want the solution, they want what the solution allows them them to do
Shawn explains it really well with this slide:
With this analogy, the developer experience team are responsible for learning what hole their users want and building the custom drill bits, add-ons and instructions to help them achieve their goal using the core drill.
And to achieve this, DevX engineers bridge product to community.
Why talk in circles?
Because each company tends to have multiple products.
So it fits better as a circle.
Some companies will have different size circles.
For instance, Snowflake got very far without DevRel. They had really good docs and did lots of direct sales. But they didn't even bother much with content.
Developer Exception Engineering
A lot of companies focus on the happy path and move on.
But if you can help people deal better with 'wtf' moments, you will build a lot of trust. Shawn calls this 'real developer experience'.
More info on developer exception engineering
Applying game design principles to DevX
Game designers are the best at experience so learn from them.
Focus on how long it takes to learn a tool in a different method (e.g. video, reading and live workshops).
Reading should have complete docs but also a getting started that should allow you to get started in 10 minutes. A lot of time should be spent on this.
Use feature mapping process to draw learning journeys
Go through every single feature, tag them and group them. Then simplify them into categories.
Finally, map out learning journeys from this.
Two by twos
- Pick two dimensions you care about. E.g. happy path, unhappy path. Invisible, invisible. Pick the two you care most about.
- Think about the big categories you really want e.g. monitoring/observabiity.
- Map them onto the two by two.
It helps you to think about which categories might be underdeveloped.
