The problem

OutSystems was scaling its developer cloud platform, ODC, across multiple product teams. While there was a design system, it was a bit like the wild west. Components weren't optimized for content which created a very unique set of problems across the UI. On top of that, designers and engineers were making language decisions in isolation. Content design had fragmented and incomplete guidance. UI concepts had three different names depending on which team built it. And nobody could agree on whether something was a "configuration" or a "setting."

The design system had a visual layer, but it had no content layer. My job was to build one. Three years later, 90% of the design org was using it in their daily workflows.

My role

For three years, I owned the content layer of the ODC design system end-to-end — not as a content strategist handing documents to designers, but as the designer building the layer myself. That meant defining concepts, building frameworks, writing guidelines, designing components, and getting teams to actually use them.

The process

I started where most systems problems start: definitions. Working with other designers, I triaged the most commonly inconsistent concepts, then met with multiple stakeholders to create an agreed-upon word and definition list. For stickier terms like "IT user" vs "end-user" I ran testing and included that data in the word list.

For some terms like the difference between "configuration" and "setting," I ran data scrapes on the terms in our community forums, analyzed them with AI, as well as ran cross-team definition sessions, then synthesized it all into a single precise definition everyone could use:

A configuration is global in scope and often requires additional user action. A setting is scoped to a single object or user preference and typically requires only toggling.

From there I used competitor benchmarking, SME knowledge, and testing data to write tone, voice, and syntax-specific guidelines. This included things like approved date and relative time formats, how to write file extensions, and so on. After this, I did in-depth audits on our existing components and defined content guidance for each one.

From there I built frameworks, patterns, and guidelines that designers and engineers could use to make content decisions without needing to ask:

  • Jobs of content: Six things content can do in a product: Notify, Inform, Educate, Sell, Ask, Represent. This became the lens for evaluating every alert, tooltip, and empty state. I also adapted this for some of our components. For example, a table's main job is to represent data. It shouldn't be to sell or to educate. This gave clear guidelines on when to use one component over another.

  • Content component hierarchy: A six-level framework (System, Page, Section, Group, Component, Element) defining where, what, and how each level of the UI should communicate to users.

  • Exit CTA decision tree: A flowchart that answered "should I use Cancel, Close, or Done?" once and for all.

  • Icon placement guidelines: Rules for when an icon goes left vs. right of text values, based on whether they represent type or state.

  • Link behavior audit and guidelines: A systematic audit identifying four distinct link behavior patterns in the portal, with clear rules and recipes for each.

I used the component audits to make cases for component changes and updates across our Figma and code libraries. I didn't just serve as the flagger, but the designer. I specced out component changes for engineering teams that included min/max widths, design tokens, states, and responsive breakpoints. I designed net-new components including the Canvas Control and Context Footer from the ground up.

At the end of my time at OutSystems, I was working with an engineer to build an AI-driven design system tool trained on all of our design system docs and frameworks that would make design system guidance conversational. It would also act as a "design review." Designers would upload Figma flows and it would lint them against design system token values, behavior, content, and motion guidelines.

Impact

  • 400% increase in usage of content style and component guidelines over four years. I turned a fragmented resource teams hadn't heard of into one many considered a pillar in daily design decisions.

  • ~68 of 75 designers (90%) actively used the content layer guidelines at peak adoption. An additional 10-25 engineers, PMs, and technical writers used them as a secondary reference.

  • 40 components documented with content guidelines covering the full range of patterns teams needed to make consistent decisions.

  • Reduced decision friction across 6 teams. Terminology disputes that previously required multiple alignment meetings moved to Slack messages: "I checked the word list and wanted to confirm this was the right word to use."

  • Established shared language. Defining "Configuration" vs. "Settings" impacted how we redesigned multiple parts of the navigation, reducing terminology conflicts in wireframes and how the product was visually organized.

  • Alert hierarchy referenced beyond design systems. Teams outside the design system used the framework for product-level communication decisions, showing organizational reach beyond its original scope.

  • External validation. The Jobs of Content framework was published as a blog post after being requested by an external publication.

  • Adopted as AI infrastructure. Multiple teams included the content guidelines in their AI prototyping rules, using them as source-of-truth input for AI-assisted design work.

  • ~$712k estimated annual savings in designer time. Based on annual survey data measuring time spent on terminology decisions, content matching, and design review tasks across 19 designers, extrapolated across the team at a $75k average salary. At $100k average salary the figure approaches $1M.

What I'd do differently

The hardest part of this work wasn't building the frameworks, it was adoption. In a large organization with strong existing patterns, introducing new design resources requires a lot of change management and alignment. I started calling this sort of work "building in public." I learned that the path to adoption is through the people who are already making decisions, not around them. I'd invest earlier in co-creating frameworks with engineering and product leads rather than presenting finished work for buy-in.