Designing content teams could actually rely on
Designing content so teams could rely on it, not just publish it
The context
Over time at Nulab, content was increasingly expected to behave like a product — even if no one explicitly called it that.
Content was used to:
educate users at scale
support onboarding and adoption
reduce support burden
explain concepts the product UI couldn’t fully carry
persist value over time without constant rewrites
This expectation showed up in small, practical ways:
“Can we just link to something?”
“Do we already explain this somewhere?”
“Can this live outside the product but still support it?”
Content was no longer just serving marketing goals. It was sitting between product, marketing, support, and success.
Where things started to strain
In practice, content was being leaned on by many teams:
marketing for acquisition and evaluation
product for education and context
support and success for reinforcement
sales for clarification and credibility
But there was no single owner of this middle layer.
Expectations weren’t always explicit, and content was often treated as flexible labor rather than a maintained system. Requests were reactive, duplication crept in, and important explanations were rewritten again and again in slightly different ways.
Nothing was “broken” — but the cost of inconsistency and decay was adding up.
How my approach shifted
Rather than producing more one-off assets, I started designing content for reuse.
That meant:
creating pages meant to stay relevant over time
favoring foundational explanations over trend-driven pieces
structuring content so it could be linked from many places
reusing patterns and frameworks across products and formats
This wasn’t framed as “infrastructure” work at the time. It was a response to real friction:
repeated rewrites were inefficient
teams needed a stable source of truth
content decay caused confusion and misalignment
ownership gaps led to quiet performance loss
The goal was to make content dependable enough that other teams could safely rely on it.
What changed in execution
As content became more relied on, structure and consistency mattered more than volume.
In practice, I focused on:
consistent terminology
predictable page patterns
clear scope boundaries (“this page does X, not Y”)
clarity over cleverness
This made content:
easier to maintain
safer for others to reuse
less likely to drift or contradict itself over time
Learn evolved from a traffic-first SEO hub into a more stable reference layer that supported:
onboarding and setup
feature understanding
ongoing usage and reinforcement
At the same time, I put lightweight internal structure in place to reduce friction:
clearer content request and prioritization workflows
shared standards and maintenance practices
internal cheat sheets and libraries for reuse
None of this was flashy. It was meant to make day-to-day work smoother.
What this enabled
Over time, content became a more reliable, shared layer across the organization.
Learn content supported onboarding and setup flows
support, success, and email teams reused content with more confidence
content planning became more predictable
activation paths from discovery into product usage became clearer
Content didn’t replace the product, and it didn’t solve onboarding on its own. But it became stable enough that teams could depend on it without constant oversight.
Why this still matters
Content rarely fails loudly.
Confusion, misalignment, and decay tend to surface slowly — often after trust has already eroded. This work was largely preventative: focused on longevity, maintenance, and reducing the risk of silent failure.
That mindset still shapes how I work:
protect core explanations
avoid unnecessary rewrites that introduce risk
design for reuse before scale
What this shows about how I work
This case study reflects how I approach content in complex organizations:
I pay attention to where content is quietly carrying product load
I design for durability before volume
I think about maintenance cost, not just launch impact
I aim to reduce friction across teams, not just ship assets
Content became more useful not because it was rebranded as “infrastructure,” but because it was treated with the care required for others to rely on it.
Closing
This work wasn’t about redefining content.
It was about making sure the explanations people depended on didn’t quietly fall apart as the organization scaled.