Shapes / Product System framework
A design system for more than the interface.
A Product becomes unavailable. Which interfaces change, which actions are allowed, and what happens to the purchase flow?
I’m building Shapes to connect the definitions, interfaces, and rules a team needs to answer those questions.
- My contribution
- Defined the reference model, the documentation-to-standard boundary, and the authoring workflow.
- Design focus
- A connected Product System for designers and engineers, starting with a retail domain.
- Current stage
- Independent framework in development; conceptual retail workspace
A rule changes.
The team needs the whole picture.
Changing product availability can affect the shopper card, merchant catalog, cart, and purchase flow. A component library explains how the card is built, while availability rules and action conditions may live in separate documents.
I designed Shapes as a connected reference so designers and engineers can follow a rule from its definition through the interfaces and actions it affects.
Define the Product once.
Explain each context.
I separated an object’s definition from its representations. The shopper card, merchant row, and cart summary reference the same Product while exposing the information and actions each audience needs.
A separate definition in every screen document would make each page self-contained. Sharing it gives changes a common reference, with the cost of maintaining those links as the product evolves.
Same Product. Different jobs to do.
Shopper / discover
Everyday mug
$28.00
Lead with image, name, and price.
Merchant / maintain
Everyday mug
MUG-01
- Price
- $28.00
- Availability
- Available
Expose fields and editing controls.
Shopper / review
Everyday mug
$28.00 each
Show quantity and the line total.
Shared identity still needs clear boundaries: current catalog price and recorded cart-line price can follow different rules. Quantity belongs to a Cart Line.
I organized the framework into objects, actions, representations, surfaces, flows, and UI elements. Object-Oriented UX informs the model: understand the meaningful things, their relationships, and the actions people take on them.
Follow the rule.
See what it means for the interface.
The workspace turns those connections into a reading path. Start with Product, open its Product Card representation, and see how availability shapes both the interface and the next action.
I kept one library tree and one focused document. Attributes and connected references use consistent tables, so the reader can move from a definition to its context without reconstructing a new layout.
Start with a shared Product definition.
Product
ObjectAn item offered for sale, independent of where it appears.
Attributes
What defines a Product| Attribute | Type | Definition |
|---|---|---|
| ID | Text | Stable product identity |
| Name | Text | Customer-facing name |
| Price | Money | Current catalog price |
| Availability | State | Available or unavailable |
Connected references
How Product fits into the system| Reference type | Connected to Product |
|---|---|
| Objects | Cart Line ↗ |
| Representations | Product Card ↗Catalog Row ↗Cart Summary ↗ |
| Surfaces | Search Results ↗Merchant Catalog ↗ |
| Actions | Add to cart ↗Edit product ↗ |
| Flows | Purchase ↗ |
From the Product record, follow Product Card to the state and behavior it defines.
See how availability changes the experience.
Product Card
RepresentationA shopper-facing summary of a Product, shaped by its availability.
State mapping
| Product state | Card behavior |
|---|---|
| Available | Show price and Add to cart |
| Unavailable | Show availability; offer another product |
Action contract
- Action
- Add to cart
- Requires
- Product is available
- Changes
- Creates or updates a Cart Line
- When unavailable
- Offer available products
Card / unavailable state
Everyday mug
$28.00
Currently unavailableView other productsPurchase flow
Keep the shopper’s next step clear- Browse products
- Choose an available Product
- Review cart
Document what exists.
Choose what becomes a standard.
I made documentation, reuse, and enforcement separate decisions. An implementation records what exists. A pattern explains an approach that can repeat. A standard records what an organization has chosen to require.
Automatically promoting every documented interface would make consistency easier to enforce, but it would also flatten differences that serve different audiences or tasks. Keeping these levels distinct preserves the context behind a variation. It also asks the team to make an explicit adoption decision.
Sharing is a decision, not an automatic promotion.
- Implementation
What exists
Document one real interface and its context.
- Pattern
What can repeat
Explain the reusable approach and where it fits.
- Standard
What is required
Record a convention the organization has chosen.
Evidence of repetition Review of context Explicit adoption
Review the meaning.
Then add it to the shared model.
I made contributor review part of authoring. A screenshot can reveal a field or control; source code, requirements, or an owner can explain its permissions and effects. Reviewing that interpretation adds effort, but gives shared definitions a source and open questions an owner.
Connect what is visible to what the product does.
Authoring workflow
Review the interpretation
- Product.nameAccepted
Visible title maps to an existing attribute.
- “Buy” → Add to cartEdited
Edit the proposed action name to match the observed control.
- “Clicking creates an Order”Rejected
A screenshot does not establish that effect.
- Who may change the price?Unresolved
Check implementation or confirm with an owner.
The same review supports maintenance. Structured, version-controlled definitions link to implementation and design evidence; changes bring affected references back into review.
Keeping Product.availability current
- Source
- The availability rule and its implementation reference
- Owner
- The contributor responsible for the Product definition
- Review trigger
- A change to the rule, its action contract, or a connected representation
A proposed change brings the affected references into review before the shared definition is updated.
I scoped the first release around one complete authoring path: document an interface, model its meaning, connect its context, and publish the reference. Keeping that path focused gives the team something useful to maintain before adding advanced extraction or visual editing.
Explore the six reference types
Objects
What is this thing?
Product identity, attributes, relationships, and lifecycle.
Product → name, price, availability
Actions
What can change?
Who may act, under which conditions, and what happens afterward.
Add to cart → create or update a cart line
Representations
What matters here?
The information and controls an audience needs in a particular context.
Shopper card → name, image, price, add
Surfaces
Where does it live?
How pages, forms, dialogs, and collections compose an experience.
Search results → collection of Product Cards
Flows
How does someone reach a goal?
The sequence of surfaces, decisions, states, and outcomes.
Purchase → choose, review, checkout
UI elements
How is the interface built?
The components, tokens, and implementation details that give it form.
Card + button + typography + spacing