Helping people write better technical API documentations with a collaborative approach.
What's Broken & Why
Modern software moves fast, but documentation doesn't. Code lives in Git. Documentation lives somewhere else. When code changes, docs often don't follow.
This happens mainly because of an ownership gap. Developers don't see docs as part of their job, and writers don't have the context. So the gap keeps growing.
Team
1 Designer (myself) • 3 Engineers • 2 Growth & Marketing Managers
Duration
~ 1 Year (MVP + Feedback + Iterations + Testing)
What Did I Do?
I owned design & product end-to-end and tested with real users. Found key patterns across that feedback, and shaped the product journey.
Research
Stakeholder Alignment
User Testing
Design System
High Fidelity Prototyping
Design QA & Handoff
Motion Design
Going Beyond My Role
This was a PLG approach unlike our sales led products. I actively contributed to marketing by designing interactive product videos on Jittr (including the ones you see in this project)
Product Videos
Wedinars
User Interviews
Brand Awareness
Marketing Initiatives
What We Wanted To Solve?
Design a place for developers and writers to collaborate on docs.
For Users
Make docs faster to publish.
For Businesses
Reduce doc-related support queries.
Hypothesis
Docs and code stay synchronised → Accuracy increases → Customers always get updated information → Support tickets go down.
A Problem Worth Solving?
We interviewed users to understand what existing tools fail to solve for, focusing on their day-to-day challenges, rather than jumping straight to which features to build.
Impact
Efficiency
Reduced the steps-to-publish, from 7 to 2, making documentation faster to publish.
Trust & Validation
We migrated our own internal APIwiz docs. which turned into a dogfooding exercise.
Adoption
We onboarded enterprise customers like — RCBC, EWB Bank.
Engagement & Reach
Attracted users from various countries, with a 53.9% returning visitor rate.
Product in action
Experience the product described in this case study.
Visit Docuwiz
What To Build & For Whom
Based on the user insights, we mapped what each of these personas actually needed to get their job done.
Provide a structure and feedback loop.
Clean, block-based editing, structured writing support, continuous feedback loop.
Design an easy way to get doc live.
Simple setup journey, sync code with docs, preview, publish, and hosting.
Allow them to keep the docs accurate.
Track changes across, verify specs against real flow.
Facilitate collaborative approach
Make it easier to get team to collaborate on documentation process
Build Fast & Test (MVP)
Built an MVP with a simple goal: plug docs into source control and host them on DocuWiz. But this was really a testing phase, the primary intent was to make something real enough to get litmus-tested by actual users.
Was Anybody Interested In It?
How Did We Gather Feedback
Team gathered user feedback on MVP. I learned that no amount of synthetic personas or simulated user research replaces the insight you get from watching a real person struggle with your product.
Litmus Test
Testing Pool Size
Collect Users’ Quotes
What they said vs what they need
Find Patterns
Find out frequent Points
Prioritise & Fix
Weighed impact against effort, then built.
Listening To The Users
I documented their feedbacks into quotes to understand what they are asking for.
User Feedback
"docuwiz appears to publish without my explicit request/consent. This should be corrected (very high importance) to establish trust."
David Biesack
"Importing the Petstore spec failed with 'Please Resolve Errors before generating' despite 0 errors."
Vladimir Gorej
"when importing a YAML OpenAPI spec — a format the product explicitly states it supports — the Uploaded Files page displays OAS VIOLATIONS: Invalid JSON... This is a trust-breaking bug."
Gale James
"a component gallery or documentation playground and dark mode. Both are calls for surfacing what already exists more than building net-new"
Avinit Chakravarti
"By step five of the onboarding flow, I had not built anything."
Shane
Finding Common Patterns
I found out common and frequent points across whole feedback
Onboarding
The flow assumes users arrive spec-in-hand. Three independent feedbacks — too many steps before any output, a buried CTA, and no fallback for anyone without a spec file ready.
Error-State Transparency
The interface tells the user something happened, without giving them the information or control to act on itblems that don't exist.
Feature Discoverability
The design hides capability that already exists. Rated 3/5 — "clean and modern but too minimal" — with the biggest blocker named directly as discoverability, not missing features.
AI Feature UX Friction
The AI-enhancement entry point dead-ends with a blocking dialog, inconsistent labeling between screens, and no consistent way to find the feature again once past initial setup.
Finding Themes
Instead of taking feedback as it is, we dug into the root cause, checking it against our original hypothesis, and planed action from there.
Brainstorming - How Might We
Based on the problems we saw with our hypothesis, we started branstorming solutions
Make the first action obvious?
Let users see value before uploading doc?
Show users everything the product does?
But Should We Fix Everything?
Due to limited time and resources, we had to prioritise what to solve and place our product accordingly. For that we mapped Impact VS Effort chart
New User Journey
Product Launch
Feedback from early users revealed where the experience broke down, helping us reshape flows to reduce friction and guide users toward meaningful outcomes.
Did Anyone Buy It?
Yes, we built a community of technical writers, organised webinars to build our presence in the market. But in order to sell it we had to understand where we stood out compared to our competitors
Intuitive UI
Make docs faster to publish.
Feature Rich
Reduce doc-related support queries.
Reasonably Priced
Docs and code stay synchronised → Accuracy increases → Customers always get updated information → Support tickets go down.
Learnings
Working closely with partner teams reinforced the value of shared thinking. Aligning early and often helped us create a more cohesive experience, where the product felt consistent and intentional across touch points.
What’s Next
We’re actively collecting user feedback and pulling items from the backlog. With a strong foundation in place, the focus shifts to fine-tuning the experience, strengthening existing flows, and making the product more delightful.
70% Improving
our effort on improving existing features and user requests
30% Building
on exploring and building new capabilities