Scaling One Product for Two Major State Adoptions
New requirements revealed where the core product needed to become more flexible.
Two states, one delivery window, and one product that had to support both without splitting into separate versions.
- Role
- Product Designer
- Team
- Product, Engineering, Content, Research
- Timeline
- Approximately 6 months
NDA protected: details and product visuals have been modified for portfolio use.
Variation exposed the product's limits.
Each state had its own roadmap, and one product had to support both without losing its flagship identity.
Both adoptions brought denser content, new ways of teaching, and requirements the national product wasn't built for. Solving each state separately would have split the flagship into editions that were harder to use, build, and maintain.
Denser content
Existing layouts strained under more complex requirements.
New use cases
New scenarios pushed components beyond their intended range.
One deadline
Both adoptions shared the same delivery window.
More content and more variation than the product was built to handle.
We stopped treating variation as an exception.
State-specific requirements exposed a larger product gap.
At first, the new requirements looked like a long list of state-specific changes. Solving them one by one would have gotten us to launch, but left the product with more exceptions to design, build, and maintain.
I reframed the work around a product question:
What needed to become more flexible in the core experience?
I owned the UX guidelines across both adoptions. I turned changing requirements into consistent product patterns and coordinated 2,000+ Jira tickets with product, content, and engineering. Seeing the whole picture helped me tell one-off requirements from real product needs.
Each requirement became a product decision: reuse, extend, or create.
Yes. An existing pattern already covers the need.
Reuse
Use it as-is; nothing new to build.
Zero cost to scalePartly. The core behavior holds, but the range is too narrow.
Extend
Evolve the existing pattern so both editions share it.
Cost absorbed onceNo. The need falls outside what the system can express.
Create
Introduce a new pattern, designed to be reused.
Highest cost, requires justificationDefaulting to create is what fragments a product. Most requirements resolved in the first two lanes.
We redesigned how the product handles dense content.
The goal was to give the product a better way to handle complexity, whatever each state's content.
The biggest pressure point was information density. Layouts that worked for the national product started to break under more content and new combinations of it.
I added clearer hierarchy and progressive disclosure, so users saw the essentials first and opened more detail when they needed it.
The existing layout worked with lighter content.
Clearer hierarchy made room for more content without disrupting the core experience.
A solution wasn't finished until it worked beyond its first use case.
New patterns had to work across both adoptions, beyond the requirement that prompted them. As real content exposed edge cases, I worked with product, content, and engineering to refine component behavior and rules instead of adding one-off overrides.
I evaluated each pattern against three questions:
Does this improve the experience?
Does it strengthen the system?
What happens when we need this again?
The result was a smaller set of flexible patterns that could solve multiple requirements without fragmenting the product.
Content changed from state to state, but layouts and interactive elements stayed in the same places, so both editions felt familiar.
Two adoptions shipped, and it still felt like one product.
Both adoptions left the product able to support more than it could before.
Both state adoptions launched in the shared delivery window, and the flagship kept its identity and interaction logic.
The product also came away with flexible patterns for dense information and variation, so future teams start with shared patterns and far fewer exceptions.
Scalability doesn't mean making everything the same.
The strongest system preserves consistency where it matters while giving the product enough flexibility to evolve.
Frame it earlier
Next time, I'd start with the reuse, extend, or create question before the first requirements arrived, not after the ticket count grew.
Stress-test with real content first
I'd also test new patterns against the densest real content up front, so edge cases surface before production.