Two major state adoptions brought denser content, new use cases, and a shared delivery window. The product had to evolve without becoming two separate experiences.
role
Product Designer
team
Product, Engineering, Content, Research
TIMELINE
Approximately 6 months
NDA protected
Details and product visuals have been modified for portfolio use.
01
the challenge
Variation exposed the product's limits.
Two adoption roadmaps. One product that had to support meaningful variation without losing its flagship identity.
Two major state adoptions introduced denser content, new instructional use cases, and requirements beyond what the national product was built to support. Solving for each state independently would have fragmented the flagship experience and made every edition 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.
New state requirements introduced more content and variation than the product was built to handle.
State Adoptions
Flagship Product
02
product strategy
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, translating evolving requirements into consistent product patterns while coordinating work across 2,000+ Jira tickets with product, content, and engineering. This system level view helped me distinguish one off requirements from broader product needs.
Each requirement became a product decision: reuse, extend, or create.
Reuse
Use an existing pattern when it already supported the need.
Extend
Evolve an existing pattern when the core behavior still worked.
Create
Introduce something new when the existing system couldn’t support the need.
03
designing for flexibility
Instead of fitting in more, we changed how the product handled complexity.
The goal wasn’t to design around one state’s content. It was to give the product a better way to handle complexity.
The biggest pressure point was information density. Existing layouts worked for the national product, but began to break as requirements introduced more content and new combinations of information.
Rather than adding everything to the screen at once, I introduced clearer hierarchy and progressive disclosure so users could access additional detail when they needed it.
Before
The existing layout worked with lighter content.
After
Clearer hierarchy made room for more content without disrupting the core experience.
04
designing to scale
A solution wasn't finished until it worked beyond its first use case.
Variation within a consistent structure
Content could change, but the 50:50 layout and placement of interactive elements stayed consistent, creating a predictable experience across both adoptions.
New patterns had to work across both adoptions, not just the requirement that prompted them. As real content exposed edge cases, I worked closely with product, content, and engineering to refine component behavior and rules rather than introduce one-off overrides.
I evaluated each pattern against three questions:
User Value
Does this improve the experience?
Product coherence
Does it strengthen the system?
Cost to scale
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.
05
outcome
Two adoptions shipped. The product stayed cohesive.
We didn't just design for two adoptions. We expanded what the product could support.
Both major state adoptions launched within the shared delivery window while maintaining the identity and interaction logic of the flagship experience.
The work also left the product with more flexible patterns for handling dense information and meaningful variation, giving future teams a stronger foundation instead of a growing collection of 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.