Help Center Migration
Two help centers. Two different problems. One shared system.
Da Vinci's help center needed a developer to fix a typo. Studio's let anyone publish anything. Neither worked. I designed a shared information architecture and governance model that unified both, without making the two products look or behave the same.
-50%
Content rework time
ROLE
Content Strategist & Technical Writer
TIMELINE
2024
TEAM
Enablement, Customer Education, Product, Engineering, CX
TOOLS
Zendesk Guide, Zendesk Explore, GA4, GitHub (legacy)
01
THE CHALLENGE
Two help centers. Two different kinds of friction.
When I started working across Studio and Da Vinci, each help center was broken in the opposite way.
Da Vinci's documentation lived as Markdown files in the product's code repository. A one-line correction meant a GitHub branch, a developer review and a deployment. Search only matched article titles, so a typo or a term buried in the body sent people to a dead end. There were no breadcrumbs, and the navigation mirrored the app's screens instead of the tasks people came to do. Internal teams had quietly stopped using it and went to Slack instead.
Studio was already on Zendesk Guide, so publishing was easy. Too easy. A large library written by many contributors had drifted into duplicate articles, inconsistent structure and terminology, and 19 client-only portals holding 287 articles of one-off content in addition to its over 500 article library.
One system had too much dependency. The other had too little coordination.
The request was to centralize and streamline the help center experience. But moving both products onto the same platform wouldn't fix either problem on its own.
02
THE INSIGHT
The systems didn't need to become identical. They needed to share a foundation.
My first step was to audit both help centers: how articles were organized, how people found them, how contributors published changes and where inconsistency crept in.
The audit showed the problems were connected, but the fixes weren't the same. Da Vinci needed an accessible publishing platform. Studio needed structure and standards. Both needed a shared approach to information architecture, editorial rules, ownership and maintenance.
Studio also settled the obvious shortcut. It was already on Zendesk and still inconsistent, which proved the platform alone wasn't the answer.
That led to the central design decision: unify the system, not just the platform. Standardize the rules that make a help center reliable, and keep each product's experience its own.
03
THE SYSTEM
One information architecture. Two front doors.
I designed a shared foundation for both help centers, built from four parts:
Information architecture. One set of shared categories for the things users do in both products: Getting Started, Building Campaigns, Reporting and Analytics, What's New, and a single Developer Documentation area. Product-specific sections only where the products actually differ. I mapped roughly 370 articles into it, folded standalone troubleshooting sections into the features they belonged to, and moved content that didn't belong out of the help center: internal content to Guru, client-specific content to the Learning Hub.
Content model and standards. Eight topic types (Getting started, Concept, Task, Glossary, Release note, Tutorial, Reference, Troubleshooting), adapted from GitLab's documentation framework, each with a template. A style guide covering voice, terminology, formatting, links and images.
Governance and ownership. A named owner for each help center. A two-channel intake: Notion for release work, Zendesk for everything else. Response targets: first drafts of new articles in 5 to 7 business days, updates in 1 to 3. Quarterly checks for articles that no longer match the product, and quarterly audits of the best and worst performers.
Publishing infrastructure. Da Vinci moved from GitHub to Zendesk Guide, removing developers from routine updates and adding predictive search, breadcrumbs and user-segmented content.
The result: one operating model supporting two distinct help centers.
04
KEY DECISIONS
Standardization without sameness.
01
Standardize the rules, not the experience.
I aligned the patterns for structure, editorial quality, taxonomy and governance, and kept product-specific terminology, navigation and user journeys. Someone looking for Da Vinci documentation shouldn't need to understand Studio's product model to find an answer. Shared standards should make each experience more coherent. Not identical.
02
Remove engineering from routine publishing.
Da Vinci's old workflow treated a documentation fix like a software release. Moving to Zendesk Guide put routine publishing in the content team's hands and shortened the path from spotting a problem to fixing it.
03
Treat governance as part of the architecture.
A shared taxonomy and a set of templates only work if people keep using them. I paired the structural redesign with ownership, intake, response targets and a quarterly verification cadence, so governance became an operating process rather than a one-time cleanup.
04
Design for the next article, not just the existing library.
I researched documentation frameworks before building a single template and chose to adapt GitLab's, because it was designed for many contributors working in the same library. We had two dedicated writers, but I built for a future where PMs and CX could draft articles too. The payoff came from somewhere else entirely: those structured topic types later became the output formats for InkLoom, the AI content production system I built.
05
THE TRANSFORMATION
From two disconnected workflows to one sustainable model.
The change happened at three levels.
Publishing: Da Vinci moved from developer-mediated deploys to direct content-team publishing.
Architecture: Both products moved to shared categories and task-based navigation while keeping their own sections and terminology.
Governance: Contributors gained common templates, named owners and a predictable intake instead of making structural decisions article by article.
BEFORE
Search matched article titles only
No breadcrumbs, screen-based navigation
Every fix went through a GitHub deploy
Moving an article broke inbound links
All content visible to everyone
No analytics
AFTER
Predictive and full-text search
Breadcrumbs and task-based navigation
Updates take seconds
Links update automatically
Content permissioned by user segment
GA4 and Zendesk Explore reporting
06
the outcome
Faster publishing. More helpful content. Less rework.
For Da Vinci, removing developers from routine updates cut publishing time for minor changes by 90%.
After the shared architecture and restructured articles went live, article helpfulness rose 20% and time spent reworking content after publication fell by 50%.
The content side also finished ahead of the platform. The new Da Vinci help center was content-ready about two months before launch. The June 2024 launch waited on an engineering-owned authentication migration, and I used the gap to keep auditing articles and tightening the standards.
The real test came later. When I built a measurement framework for both help centers, it confirmed the IA and templates were doing their job.
"Moving to Zendesk, cleaning up the architecture and content standards, drastically changed how clients and internal stakeholders use our help center content."
— Director of Product Enablement & Customer Education.
07
What I Actually Designed
The migration was the mechanism. The content system was the work.
The visible change was moving Da Vinci to Zendesk and restructuring both help centers. The work underneath was the system that made the change hold.
I designed the information architecture for both help centers: shared categories where the products overlap, distinct sections where they don't.
I adapted and built the content model and templates: eight topic types, each with a clear purpose and structure.
I established the editorial standards that aligned voice, terminology and quality.
I designed the governance model: ownership, intake, response targets and a quarterly verification cadence.
I led the Da Vinci migration, moving documentation from GitHub to Zendesk Guide and rebuilding it on the new structure.
Together, those decisions turned two disconnected content operations into one maintainable system.
08
THE BIGGER IDEA
A strong foundation supports everything.
It's tempting to read consistency as sameness. But Studio and Da Vinci served different products, with different features, terminology and users.
Making them identical would have simplified things for the people maintaining them at the expense of the people using them. The useful move was to separate what needed to be shared from what needed to stay specific.
Shared standards made content easier to create and maintain. Product-specific structure made it easier to find and understand.
The foundation could be consistent without making the experiences interchangeable.
09
Reflection
Systems pay off in places you didn't plan for.
The hardest decision was what to standardize and what to leave alone. Standardize too little and Studio's drift would have spread to Da Vinci. Standardize too much and both products would have lost the navigation their users actually needed.
The other lesson was about who a system is really for. I chose a multi-author framework because I expected PMs and CX to start drafting articles. That never happened. But the structure I built for them became the foundation for InkLoom, where AI now drafts inside the same topic types a human contributor would have used. Designing for contributors who didn't arrive is what made the system ready for one that did.
Want to know how the ownership and intake process actually works, or what nearly broke during the Da Vinci migration? Reach out and I can go into the details!