The talk covers Onfido's journey as a company from developer-led documentation to a full-time holistic focus on Developer Experience— and what that means for us. Some examples are achieving consistency across our API client libraries and moving on from OpenAPI-generated libraries, trialling a documentation-led approach for developing the newest version of the Onfido API, and separating our product and technical documentation without compromising on user experience.

1. Ben Ahmady and Minh Nguyen
Developer Experience as a Product

2. Our Vision
We’re creating an open
world where identity is
the key to access
API at the core of our
overall product offering

3. 🎯 The team's mission is to build a product experience that converts and retains customers
at scale—from trial, to integration, through to long-term use.
Our team
ATTRACT ACTIVATE INTEGRATE ENGAGE
🧲 💰 👩‍💻 😍

4. Developer Experience as a Product
(Minh) Beyond the code: a razor-sharp focus on the why
(Minh) Product discovery: breaking changes don't have to mean
breaking experiences
(Ben) Execution excellence: mission-driven teams with end-to-end
ownership

5. Developer Experience
Faster integration Revenue
Happy customers

6. Minh
Beyond the code

7. Beyond the code
When talking about developer experience and APIs...
A razor-sharp focus on the why

9. Beyond the code
Developer experience = an engineering thing? 🧑 💻
A razor-sharp focus on the why

10. Beyond the code
Customers don’t use your API because they like you…
...they do it because it helps them solve a problem 💪
A razor-sharp focus on the why

11. Beyond the code
Payment API ⚙
SMS API ⚙
Identity verification API ⚙
A razor-sharp focus on the why
Collect money easily and securely 💰
Complete a second-factor step 🛡
Verify someone is who they say they are ✅

12. Beyond the code
APIs are not neutral conduits, they are designed and built to solve a
customer problem…
A razor-sharp focus on the why

13. Beyond the code
Let’s take an example. You have rainfall data, and are asked to build an
API to monetise it.
A razor-sharp focus on the why

14. Beyond the code
A razor-sharp focus on the why
NEW
DEVELOPER
EXPERIENCE
INITIATIVE
ENGINEERING
LEAD
BUILD DOCUMENT
🧑 💻 👷 🛠 ✍
LAUNCH
🚀

15. Beyond the code
A razor-sharp focus on the why
NEW
DEVELOPER
EXPERIENCE
INITIATIVE
ENGINEERING
LEAD
BUILD DOCUMENT
💡 👷 🛠 ✍
LAUNCH
🚀
NEW
DEVELOPER
EXPERIENCE
INITIATIVE
RESEARCH
AND
VALIDATE
USER NEEDS
PROTOTYPE,
DOCUMENT,
TEST
PROTOTYPE,
DOCUMENT,
TEST
💡 🧑 🔬 🛠 🛠
LAUNCH AND
TRACK
🚀

16. Beyond the code
What does it mean for my rainfall API?
A razor-sharp focus on the why

17. Beyond the code
APIs are not neutral conduits, they are designed and built to solve a
customer problem…
... in a way that supports the business 🚀
A razor-sharp focus on the why

18. Beyond the code
How do we know if we are effective at supporting the business?
Defining and tracking metrics 📈
A razor-sharp focus on the why

19. Beyond the code
1. Health metrics 🏥 how performant and reliable are our systems?
2. Growth metrics 📈 how good are we at acquiring, activating, and
retaining customers?
3. Feature metrics 🛠 how effective are we at solving customer
problems?
A razor-sharp focus on the why

20. Beyond the code
Time to integrate
A razor-sharp focus on the why
Quick go-live Retained and renewing clients
Number of support queries Time to upgrade
Happy client

21. Beyond the code
With critical objectives, constant feature requests, and evolving
technology, a great experience comes from methodical prioritisation 🔬
A razor-sharp focus on the why

22. Beyond the code
Pick from the framework toolbox:
● User story maps
● Kano model
● Simple, lovable, complete
● RICE
As long as it’s:
1. Evidence-based
2. A shared exercise
3. Around common objectives
A razor-sharp focus on the why

23. Minh
Product
discovery

24. Product discovery
Who interacts with your API?
Who benefits from the value of your API?
What motivates them?
What environment are they in?
What state-of-mind are they likely to be in?
Breaking changes don't have to mean breaking experiences

25. Product discovery
Avoid tunnel vision, consider the holistic developer experience
Avoid individual heroes, take people on a collective journey
Avoid local optimisation, be smart when picking which lever to pull
Breaking changes don't have to mean breaking experiences

26. Product discovery
Developer experience is layered like an onion
Breaking changes don't have to mean breaking experiences

27. Product discovery
Validate for utility and usability...not only feasibility 🧑 🔬
Breaking changes don't have to mean breaking experiences

28. Product discovery
Deal with APIs’ inconvenient truth, backwards compatibility 🚧
Breaking changes don't have to mean breaking experiences

29. Ben
Execution
excellence

30. Execution excellence
From developer-led to a holistic focus
Rebranded
client
interfaces
API v3
Improved
analytics
Developer Hub
revamp
Token cycling &
management
New quick-start
guides
Custom client
libraries
New docs
system
Product/tech
content

31. Execution excellence
● Documentation as visible part of the product 👀
● Distribution is key:
○ product marketing 🛒
○ sales enablement 💲
○ change management 🚥
○ release notes ⌨
● "Technical technical writer" = DX focus
Cross-functional team centred around a shared mission

32. Execution excellence
● "Client Acquisition & Experience"
● DX - holistic API experience⚡
○ reference documentation 📖
○ information architecture 🏘
and tooling (Postman, client libraries, OpenAPI etc.) 🔨
○ process and feedback 🟢
Mission-driven teams with end-to-end ownership

33. Execution excellence
Holistic API experience⚡
... not just the customer's!
Mission-driven teams with end-to-end ownership

34. Execution excellence
Enhanced token management (Dashboard)

35. API v2
POST /v2/applicants/{applicant_id}/checks/
{
"type": "express",
"reports": [
{
"name": "document"
},
{
"name": "facial_similarity",
"variant": "standard"
}
]
}
OLD

36. API v3
POST /v3/checks/
{
"applicant_id": "<APPLICANT_ID>",
"report_names": ["document","facial_similarity_photo"]
}
NEW

37. Execution excellence
Separation of product and technical content

38. Execution excellence
● "Developers like to copy + paste!"
● Simpler API experience = simpler documentation = 😁
● Migration guide
Assumptions (and intuition) aren't always bad

39. Execution excellence
Simpler API and public documentation

40. Execution excellence
Simpler API and public documentation

41. Execution excellence
Simpler API and public documentation

42. Execution excellence
Visual impact

43. Execution excellence
Process... feedback!
3
Send URL via
Slack, email if
Git diff not
possible
1
Make
changes
based on
best
assumptions
or user
research
2
Deploy
changes
internally
with CI/CD
(GitLab)
4
Receive
feedback
(several places)
5
Make more
changes
6
Repeat 4-5

44. Execution excellence
● Treat the experience holistically 󾠮
● Distribution is key 📮
● We're all "technical" ⌨
● Assumptions aren't always bad 🤔
● Feedback is vital 🟢
● Simpler overall experience = happy everyone! 😁
Summary

45. Thank you!