Kelly O'Brien - Surprise! You're a designer now.

Content design is a product discipline focused on structuring and presenting information—and its real value shows up when teams involve it early, before “roof-level” copy work starts. Kelly O’Brien, who works on Intercom’s content design team, argues that most of the heavy, high-impact thinking in content design happens beneath the surface: defining concepts, mapping relationships, and building information architecture. The visible output—UI copy and written words—often takes only a small slice of time, yet it’s what teams react to last, when decisions are already locked in.

That mismatch creates predictable friction. When product work is “ready to ship” but copy hasn’t been planned, content designers (and documentarians, UX writers, and others responsible for language) get pulled in at the last minute. They then face deep questions—what is this thing, how does it relate to other concepts, what are the names in the code, and how do we keep similar ideas distinct. If those questions weren’t answered earlier, simple communication becomes impossible, leading to frustration on both sides: designers can’t do their job well without context, while engineers and others resent rework that forces them to revisit weeks of decisions.

To fix that pattern, O’Brien offers a metaphor: building a product like building a house. The “roof” is the surface-level writing; the “foundation” is the system model where objects and relationships are defined; the “walls and windows” are information architecture and interaction points; and the “roof” is where copy goes. The central claim is that content design should be involved at each stage, not just when words are needed. When content design participates from the foundation upward, the product’s structure supports consistent terminology, coherent narratives, and copy that matches the system’s definitions.

O’Brien breaks down the risks at each level using a help-center example. At the system-model stage, the risk is unclear or inconsistent object definitions—such as how frequently asked questions should be represented. Teams might choose between creating a dedicated “FAQ” content object (with its own properties like question/answer and potentially tagging) or treating FAQs as a type of article with a lighter-weight distinction. Early clarity matters because later layers—information architecture, editing workflows, and user navigation—must build on the same shared understanding.

At the information-architecture stage, the risk is a “floor plan” that can’t support the intended experience. If FAQs are distinct objects, the management and navigation structures may need separate sections; if FAQs are just article types, everything can remain within the existing category and editing model.

At the interaction-design stage, the risk is mismatched UI behavior—such as editing experiences that don’t reinforce the underlying system choices. Distinct content objects can justify distinct editing fields and shorter answer-focused input patterns, while article-type FAQs may only require a checkbox or dropdown.

Finally, at the roof level, the risk is “copy that doesn’t do its job.” O’Brien argues that early foundation work makes roof-level writing easier and more successful because the system model supplies nouns and definitions, information architecture supplies narrative structure, and interaction design supplies verbs and task flows.

The practical takeaway is not to treat content design as extra work, but to advocate for earlier involvement. O’Brien recommends building relationships with product teams, securing a seat at one key meeting per project, and communicating the content-design perspective through quick diagrams (she cites Whimsical) that make the “foundation-to-roof” logic easier to act on. The payoff: fewer last-minute rewrites, better quality, and a smoother path from structure to language.