Kohl’s product attribute rules lived across enormous spreadsheets, side documents, and one domain expert’s memory. I led the systems modeling, interaction design, and coded prototyping that turned that hidden logic into a CMS model merchandising could understand and engineering could build.
At a glance
Challenge: Thousands of product attributes were governed by undocumented rules, dependencies, and exceptions. Routine merchandising operations often required engineering support.
My role: Senior Product Designer. I led discovery, domain modeling, product architecture, interaction design, and development of the working prototype in partnership with merchandising and engineering.
Key decision: I built the proposed system in React, TypeScript, and Material UI. A working application could test the model in ways that static Figma screens could not.
Outcome: The prototype gave merchandising, product, and engineering a shared, testable representation of the system. It exposed hidden edge cases and gave engineering real behavior, components, and application structure as a starting point for implementation.
The working category-management experience made the proposed system tangible while its rules and architecture could still be challenged and improved.
The real system lived outside the CMS
Product attributes power search, navigation, merchandising, compliance, and personalization. At Kohl’s, much of the logic behind those attributes had accumulated over years in spreadsheets and supporting documents.
Thousands of attributes were connected through implicit rules and category-specific exceptions. One highly experienced team member understood how everything fit together. Her knowledge had effectively become infrastructure.
This created organizational risk and an engineering bottleneck. The CMS could not accurately represent how the business worked, so merchandisers were blocked on changes they should have been able to manage themselves.
The assignment initially appeared to be an interface redesign. Discovery revealed a deeper issue: the product model itself needed to be made explicit before the interface could become simpler.
Turning institutional knowledge into a product model
I conducted detailed working sessions with the domain expert responsible for maintaining the existing system. We walked through real workflows, category rules, vendor submissions, exceptions, and the reasoning behind years of accumulated decisions.
I used AI to accelerate analysis of the session transcripts and identify recurring entities, dependencies, contradictions, and ambiguous rules. This shortened the synthesis cycle. I then validated the findings with stakeholders and made the product decisions required to turn that knowledge into a coherent system.
The model accounted for:
- Category-specific attribute schemas
- Shared attribute definitions and reusable values
- Dependencies between attributes
- Vendor submission and validation rules
- Internal review, versioning, and exception workflows
For the first time, merchandising, product, and engineering could examine the same representation of the system together.
Complex attribute structures became visible and editable instead of remaining implicit in spreadsheets and institutional knowledge.
Building the specification as working software
Behavior, hierarchy, and validation were central to the design. Static screens could show individual moments, but they could not adequately test how decisions in one part of the system affected another.
I built a high-fidelity application using React, TypeScript, and Material UI. I used an AI coding agent to accelerate implementation, then refined the system structure, interaction logic, workflows, and component behavior myself.
The prototype included category hierarchies, attribute schemas, dependency mapping, vendor submission flows, internal review workflows, validation states, and versioning behavior. Stakeholders could navigate realistic scenarios and respond to the system as software rather than trying to infer its behavior from a presentation.
Working in code also improved the path to implementation. Engineering could begin with real Material UI components, application patterns, and defined behavior instead of reconstructing the intended experience from static design files.
Reusable values replaced duplicated fields and made relationships across the category hierarchy easier to understand.
The prototype became a shared language
The working application changed the quality of the conversation. Stakeholders could point to a workflow, test an assumption, and show where the model matched or contradicted reality.
That interaction surfaced important cases that interviews alone had missed, including seasonal overrides, category exceptions, vendor conflicts, and competing validation rules. Each issue could be addressed while the architecture was still inexpensive to change.
The prototype gave every discipline a useful way into the problem. Merchandising could recognize its operational reality. Product could evaluate the experience as a complete system. Engineering could assess the architecture and implementation implications directly.
After two stakeholder presentations, engineering began implementation using the model and working application as its foundation.
What changed
At the point covered by this case study, the CMS had not yet reached production. The verified impact occurred earlier in the delivery process:
- Undocumented business logic became an explicit, reviewable product model.
- Stakeholders aligned around one interactive system instead of interpreting separate spreadsheets, documents, and design files.
- Important edge cases surfaced before engineering committed to the architecture.
- Engineering started from working components, behaviors, and application structure.
- The prototype demonstrated how category teams could manage routine attribute rules without requiring an engineer in the room.
The project reduced the translation gap between design and engineering while making years of specialized knowledge understandable across the organization.
This is where my design and engineering background is most valuable: turning ambiguity into a product model, then turning that model into software people can evaluate, align around, and build.