Writing this post scared me. I must admid that the topics discussed here are not my strongest area of expertise. But at the same time this is the moment I can learn the most. Some time ago I realised that I’ve approached the DX from the end, from the results. This means for example uptodate API docs with code examples (working), getting started guides, easy to understand pricing, support and so on. Those standard elements of great DX can be listed easily and most likely you should have them all eventually.
Developer Personas create the pressure to manufacture diamonds
Building a great developer experience is a marathon anyway with lots of iterations and experiments. Focusing on the “standard elements of DX” listed above you can get good DX. Great developer experience has it’s roots further down the line all the way back to developer personas. According to Dalton and Kahute personas should communicate on three levels:
- Value level: This is the most abstract level and refers to underlying human values and goals that people want to fulfill in their lives.
- Needs level: This level conveys the rational and emotional needs that people have in certain ituations, and can be addressed through products, services, and solutions.
- Solutions level: This is more concrete than either of the other levels. It refers to specific design principles that can guide the development of new products, services, and experiences that will fulfill peoples’ needs and desires.
With help of personas you squeeze the fluffy general DX into compact perfectly fitting targeted developer experience. Initially, personas in software/HCI design were introduced by Alan Cooper around 1999, which he borrowed from marketing and consumer behavior research. Now that same borrow pattern is repeating again. DX people are taking ideas from UX people. There are huge conceptual differences between UX and DX, but that’s a topic for another post. Back to the personas.
At my current job I’m responsible for the DX of Platform of Trust. It’s a data and applications linking and standardizing platform. It’s new platform and thus I have no ready developer base to analyse. Just by reasoning it was easy to discover that we have two directions to support. On the other hand we have data integrating developers and on the other side we have data consuming developers (apps).
Those two groups approaching the platform from opposite directions have very different needs. Crafting just simple one developer profile would not help us to offer easy to understand oonboarding process. We had to think about the needs of those groups separately - two developer personas. We do believe that developers make more and more decisions or at least recommendations about tools and how to proceed. Still the developers on our platform have managers, which also need to understand the offering and values. So we added tech team leads and architects on both sides. All together we have four developer profiles.
- Data integrator
- Data integrator’s manager / tech lead
- App developer
- App developer’s manager / tech lead
Now we can create own landing pages for the data integrator and app developer side. That makes the planning and development easier. It also creates segmentation for analysis and our CMO is pleased since now we can target the messages more accurately. Without the segmentation we would offer generic developer experience for all and the amount of concepts and details to learn would be overwhelming for majority of the developers. Giving for example “door” to enter just data integration world on the platform reduces the “noise” of app development details.
Feels like a real person
In our DX team all agreed that we don’t do anything with technically right but clinical developer personas. We wanted them to be alive! We even considered to order standing cardboard figures of the personas! That is still on hold, but otherwise we are building feeling of a real person. Aim is that in our discussions we refer to developer persona by name (we have real names for them). Ultimate test is that if an outsider would follow our discussion, they would soon ask “who is this Dan you keep on on referring? I haven’t seen him?”. In other words aim is to make our heads think of Dan as member of the team.
If the persona is blunt and clinical, your team is less likely to feel empathy towards it. And we all know that building great developer experience requires empathy. To some that might sound like soft humanistic BS, but in UX world empathy towards the consumers/users has been found to be crucial. Then what is empathy? Wieseke at al define “empathy as a person’s ability to sense another’s thoughts, feelings, and experiences, to share the other’s emotional experience, and to react to the observed experiences of another person”.
Good persona is based on real data
Building great DX is far from pure engineering. Personas are user archetypes that are synthesized from the ethnographic research data and often captured in emotive and visually engaging formats (for example, infographics, posters, or videos). Your developer persona can and should visually reflect the persona too. Imaginery personas are fake, but sometimes the best you can get in the beginning.
Fake it till you make it…sort of
Our personas at Platform of Trust are now semi-fake since we’ve just started to get developers involved on the platform. We have been discussing and following their operations and needs as well as backgrounds but it has not been systematic. That is what we aim to improve. Then we can iterate the personas again and again and improve the guidance developer personas gives for the Product Owners to steer development to the right direction and focus on things that matter. Some scholars (McQuaid et al) suggest using storyboards and narratives to elicit empathy for users with which you can’t interact directly. That is what we are doing as well.
I must admit that all this ethnographic, soft touch, psychology, emotions and feelings driven thinking feels a bit odd to me. That is most likely due to that I daily interact with hardcore developers, conceptualize and draft technical requirements for certain parts of the platform. I’m pulled into techno-centric world and thinking every day. Letting my mind go to the opposite direction during the evenings balances my viewpoints…I guess.
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!