Service
UX, UI, web, desktop
Client
Ownpath, Postman
Duration
1 month
Kula Docs is a platform built around documentation which brings API creators and consumers together to have a community where people can ask questions and contribute to the docs.
A NOTE OF THANKS 🫂
Huge shout-out to the folks at Postman & Ownpath for their inputs throughout the project.
And of course my friend Vikas who was my partner & without whom this project would have been impossible!
The problem
How might we make API documentation a collaborative space for consumers to learn how to successfully use the API as fast as possible?
Project stages
Keeping in mind the strict project deadline, we drafted a timeline that would help define solutions which could address the pain points & problem statement while keeping with the steps of the design process steps.
What is an API though?
APIs or application programming interface are mechanisms that allow two apps to talk to each other to extract and share data.
Every time you use a rideshare app, send a mobile payment, or see today's temperature from your phone, you're using an API.
Think of APIs like Lego blocks where an API documentation is its tutorial guide.
Primary stakeholders in an API
Producers - individual or team of developers that are building an API which other people can use and integrate to achieve an outcome.
Consumers - individual or team of builders, using an API to build a product or feature that aligns with their outcome.
Understanding the users
An important point to remember here is that while improving the actual documentation would be the easiest way to solve for everyone, it is not something that we can control or enforce.
Although I did coding before becoming a designer, I was quite rusty now. So to better understand the space, we spoke to everyone who consumed API in their workflow.
Developers/engineers - back-end, front-end, android, software
Project managers
While the problem statement focused only on public APIs, we conducted interviews to learn both internal & public APIs and how different people consumed them differently.
fig. some questions that we asked
Research findings
After the research, all the findings were collated into an affinity diagram to organize all the ideas into their natural relationships.
These are findings w.r.t public APIs because the problem statement focuses in that space.
Jobs to be done!
JTBD is a framework, or lens, for viewing products and solutions in terms of the jobs i.e. goals customers are trying to achieve. It lets us step back from our business & understand the objectives of the people we serve.
It was really difficult to use at first but once I got the hang of it, it eased the design process further and prevented us from deviating from the goals. Maybe I'll write more about this later.
Every job type drills down further into the scope i.e. asking "how".
Job story
When trying to integrate the API into my product, I want to read and understand the documentation, so I can decide if the API is a good fit.
Main job
Integrate the API into my product.
Small jobs
Evaluate APIs which may be used as solutions in my product.
Determine usefulness of API from its documentation.
Get support for issues found in the API and/or its documentation.
User journey map
A journey map of the current workflow really helps to visualize the phases that a user goes through and where we can contribute.
Introducing - Kula Docs
"Kula" is a Sanskrit word that means... a community of like minded (like-hearted) people coming together for a common goal or purpose.
Which seemed like a very apt fit for the product we were trying to build plus it has a nice ring to it!
Core concepts
The platform is built on 3 fundamental ideas.
Documentation
Organized information with topics and sub-topics.
Critical items shown upfront.
Global search to help find anything.
Helps you discover community & contribution.
Community
Consumer or producer can publish posts.
Doubts, bugs, thoughts, feature requests, announcements.
Helps you find relevant info dependent on your current context.
Community
Helps you suggest edits for doc pages.
Edits can be typos or better explanations or doc updates.
Promotes idea of "by the people, for the people".
White-label docs
Producers currently either use some template or create something of their own for docs. While this works, the experience is sub-standard.
We provide a template which adapts to the brand of producer and provides an infrastructure built upon user and business requirements.
Wireframes
After listing features, we started making high fidelity skeletons of the product we would like to have.
The approach was that the user selects any block of text and this overlay pops up to show relevant actions.
But having such a small space severely limited all functionalities. In the next iteration, we explored showing an overlay side sheet.
We detailed out all the micro-interactions throughout the product. This laid a foundation for making a design system that interconnects all the UI elements together.
Visual design
When we started adding visual aesthetics to the product we realized some critical issues which led us to rethink the entire approach.
The designs below are the final screens with their thought processes.
Landing page
Landing page for typesense API docs with their brand built on Kula Docs. This is where the journey begins for a user.
Community page
This is where consumers and producers come together to discuss about APIs. Every topic in the doc is a distinct space in community containing all its sub-topics.
Service
UX, UI, web, desktop
Client
Ownpath, Postman
Duration
1 month
Kula Docs is a platform built around documentation which brings API creators and consumers together to have a community where people can ask questions and contribute to the docs.
A NOTE OF THANKS 🫂
Huge shout-out to the folks at Postman & Ownpath for their inputs throughout the project.
And of course my friend Vikas who was my partner & without whom this project would have been impossible!
The problem
How might we make API documentation a collaborative space for consumers to learn how to successfully use the API as fast as possible?
Project stages
Keeping in mind the strict project deadline, we drafted a timeline that would help define solutions which could address the pain points & problem statement while keeping with the steps of the design process steps.
What is an API though?
APIs or application programming interface are mechanisms that allow two apps to talk to each other to extract and share data.
Every time you use a rideshare app, send a mobile payment, or see today's temperature from your phone, you're using an API.
Think of APIs like Lego blocks where an API documentation is its tutorial guide.
Primary stakeholders in an API
Producers - individual or team of developers that are building an API which other people can use and integrate to achieve an outcome.
Consumers - individual or team of builders, using an API to build a product or feature that aligns with their outcome.
Understanding the users
An important point to remember here is that while improving the actual documentation would be the easiest way to solve for everyone, it is not something that we can control or enforce.
Although I did coding before becoming a designer, I was quite rusty now. So to better understand the space, we spoke to everyone who consumed API in their workflow.
Developers/engineers - back-end, front-end, android, software
Project managers
While the problem statement focused only on public APIs, we conducted interviews to learn both internal & public APIs and how different people consumed them differently.
fig. some questions that we asked
Research findings
After the research, all the findings were collated into an affinity diagram to organize all the ideas into their natural relationships.
These are findings w.r.t public APIs because the problem statement focuses in that space.
Jobs to be done!
JTBD is a framework, or lens, for viewing products and solutions in terms of the jobs i.e. goals customers are trying to achieve. It lets us step back from our business & understand the objectives of the people we serve.
It was really difficult to use at first but once I got the hang of it, it eased the design process further and prevented us from deviating from the goals. Maybe I'll write more about this later.
Every job type drills down further into the scope i.e. asking "how".
Job story
When trying to integrate the API into my product, I want to read and understand the documentation, so I can decide if the API is a good fit.
Main job
Integrate the API into my product.
Small jobs
Evaluate APIs which may be used as solutions in my product.
Determine usefulness of API from its documentation.
Get support for issues found in the API and/or its documentation.
User journey map
A journey map of the current workflow really helps to visualize the phases that a user goes through and where we can contribute.
Introducing - Kula Docs
"Kula" is a Sanskrit word that means... a community of like minded (like-hearted) people coming together for a common goal or purpose.
Which seemed like a very apt fit for the product we were trying to build plus it has a nice ring to it!
Core concepts
The platform is built on 3 fundamental ideas.
Documentation
Organized information with topics and sub-topics.
Critical items shown upfront.
Global search to help find anything.
Helps you discover community & contribution.
Community
Consumer or producer can publish posts.
Doubts, bugs, thoughts, feature requests, announcements.
Helps you find relevant info dependent on your current context.
Community
Helps you suggest edits for doc pages.
Edits can be typos or better explanations or doc updates.
Promotes idea of "by the people, for the people".
White-label docs
Producers currently either use some template or create something of their own for docs. While this works, the experience is sub-standard.
We provide a template which adapts to the brand of producer and provides an infrastructure built upon user and business requirements.
Wireframes
After listing features, we started making high fidelity skeletons of the product we would like to have.
The approach was that the user selects any block of text and this overlay pops up to show relevant actions.
But having such a small space severely limited all functionalities. In the next iteration, we explored showing an overlay side sheet.
We detailed out all the micro-interactions throughout the product. This laid a foundation for making a design system that interconnects all the UI elements together.
Visual design
When we started adding visual aesthetics to the product we realized some critical issues which led us to rethink the entire approach.
The designs below are the final screens with their thought processes.
Landing page
Landing page for typesense API docs with their brand built on Kula Docs. This is where the journey begins for a user.
Community page
This is where consumers and producers come together to discuss about APIs. Every topic in the doc is a distinct space in community containing all its sub-topics.
Service
UX, UI, web, desktop
Client
Ownpath, Postman
Duration
1 month
Kula Docs is a platform built around documentation which brings API creators and consumers together to have a community where people can ask questions and contribute to the docs.
A NOTE OF THANKS 🫂
Huge shout-out to the folks at Postman & Ownpath for their inputs throughout the project.
And of course my friend Vikas who was my partner & without whom this project would have been impossible!
The problem
How might we make API documentation a collaborative space for consumers to learn how to successfully use the API as fast as possible?
Project stages
Keeping in mind the strict project deadline, we drafted a timeline that would help define solutions which could address the pain points & problem statement while keeping with the steps of the design process steps.
What is an API though?
APIs or application programming interface are mechanisms that allow two apps to talk to each other to extract and share data.
Every time you use a rideshare app, send a mobile payment, or see today's temperature from your phone, you're using an API.
Think of APIs like Lego blocks where an API documentation is its tutorial guide.
Primary stakeholders in an API
Producers - individual or team of developers that are building an API which other people can use and integrate to achieve an outcome.
Consumers - individual or team of builders, using an API to build a product or feature that aligns with their outcome.
Understanding the users
An important point to remember here is that while improving the actual documentation would be the easiest way to solve for everyone, it is not something that we can control or enforce.
Although I did coding before becoming a designer, I was quite rusty now. So to better understand the space, we spoke to everyone who consumed API in their workflow.
Developers/engineers - back-end, front-end, android, software
Project managers
While the problem statement focused only on public APIs, we conducted interviews to learn both internal & public APIs and how different people consumed them differently.
fig. some questions that we asked
Research findings
After the research, all the findings were collated into an affinity diagram to organize all the ideas into their natural relationships.
These are findings w.r.t public APIs because the problem statement focuses in that space.
Jobs to be done!
JTBD is a framework, or lens, for viewing products and solutions in terms of the jobs i.e. goals customers are trying to achieve. It lets us step back from our business & understand the objectives of the people we serve.
It was really difficult to use at first but once I got the hang of it, it eased the design process further and prevented us from deviating from the goals. Maybe I'll write more about this later.
Every job type drills down further into the scope i.e. asking "how".
Job story
When trying to integrate the API into my product, I want to read and understand the documentation, so I can decide if the API is a good fit.
Main job
Integrate the API into my product.
Small jobs
Evaluate APIs which may be used as solutions in my product.
Determine usefulness of API from its documentation.
Get support for issues found in the API and/or its documentation.
User journey map
A journey map of the current workflow really helps to visualize the phases that a user goes through and where we can contribute.
Introducing - Kula Docs
"Kula" is a Sanskrit word that means... a community of like minded (like-hearted) people coming together for a common goal or purpose.
Which seemed like a very apt fit for the product we were trying to build plus it has a nice ring to it!
Core concepts
The platform is built on 3 fundamental ideas.
Documentation
Organized information with topics and sub-topics.
Critical items shown upfront.
Global search to help find anything.
Helps you discover community & contribution.
Community
Consumer or producer can publish posts.
Doubts, bugs, thoughts, feature requests, announcements.
Helps you find relevant info dependent on your current context.
Community
Helps you suggest edits for doc pages.
Edits can be typos or better explanations or doc updates.
Promotes idea of "by the people, for the people".
White-label docs
Producers currently either use some template or create something of their own for docs. While this works, the experience is sub-standard.
We provide a template which adapts to the brand of producer and provides an infrastructure built upon user and business requirements.
Wireframes
After listing features, we started making high fidelity skeletons of the product we would like to have.
The approach was that the user selects any block of text and this overlay pops up to show relevant actions.
But having such a small space severely limited all functionalities. In the next iteration, we explored showing an overlay side sheet.
We detailed out all the micro-interactions throughout the product. This laid a foundation for making a design system that interconnects all the UI elements together.
Visual design
When we started adding visual aesthetics to the product we realized some critical issues which led us to rethink the entire approach.
The designs below are the final screens with their thought processes.
Landing page
Landing page for typesense API docs with their brand built on Kula Docs. This is where the journey begins for a user.
Community page
This is where consumers and producers come together to discuss about APIs. Every topic in the doc is a distinct space in community containing all its sub-topics.