Studio Help Center
Turned recurring support questions into a self-service system and a source of product insight.
Led the initiative across content, design, and engineering for a product with more than a million users, then used its search data to find usability problems in the product itself.
23K+
Article views
9,367
Searches
279
Avg. daily views
Within the first two months after launch. 86 articles mapped, 56 prioritized for launch.
The 30-second story
Challenge
Give a growing 1M+ user product a centralized self-service resource instead of relying on forum posts, support tickets, and canned replies.
Key move
Organized 86 candidate articles around user workflows, prioritized 56 for launch, and created a repeatable content system.
Evidence
Post-launch search patterns exposed recurring friction around rotate, connect, and hinge, turning support content into product insight.
Result
Reached 23K+ article views and 9,367 searches in the first two months, with 279 average daily views.
Problem
As Studio grew beyond one million users, there was no centralized self-service resource. Users relied on the community forum or email support tickets, while the support team repeatedly answered many of the same questions.
Canned replies improved speed and consistency, but the model remained difficult to scale and gave little visibility into where users actually struggled. A dedicated Help Center could give users a direct path to answers while making recurring questions and high-friction topics visible for the first time.
Process
01
Defining the information architecture
Having handled Studio support directly, I had firsthand visibility into recurring questions and user friction. I translated those patterns and key product workflows into a scalable information architecture, mapping 86 potential articles and prioritizing 56 for the initial launch.
I organized the content around key workflows, building, rendering, instruction creation, and sharing, so users could find answers based on what they were trying to accomplish, rather than on how the product was structured internally.
02
Creating a content system
I established a repeatable article format and writing guidelines so the documentation could stay clear and consistent as the Help Center expanded.
The system defined article structure, tone, and review standards, emphasizing short sentences, scannable layouts, plain language, and consistent naming across the product.
03
Building the operating model
I defined how new articles would be written, reviewed, revised, and published, and how existing documentation would stay aligned with product releases.
I hired an experienced Studio community moderator as a contract writer and navigated the internal contracting and payment process to bring them onboard. I then set the launch scope and coordinated the review workflow across content, engineering, and design.
Outcome
23K article views and 9K searches in two months, plus a new signal for finding usability problems.
The Help Center quickly became a widely used self-service resource, reaching 23,000+ article views and 9,367 searches within its first two months, settling at 279 views a day.
More usefully, it started answering a question support tickets never could: where do users actually get stuck? The top search terms were rotate (298), connect (163), and hinge (104), and the second most-read article of all was “Moving and rotating parts.” Not advanced features. The most foundational building interactions in the product.
That pattern pointed to recurring friction around rotating, connecting, and adding parts, and became an additional signal for identifying usability issues across Studio. turning a support resource into a research instrument.
The rotation friction led to a concrete product change: we implemented a rotation gizmo to make the control more discoverable and help beginner users learn the interaction more easily.
