Creating (and selling) Product Systems

It's possible that design slop is actually incredibly useful

I came across an excellent article by Emmett Shine where he talked about how one of the deliverables that Little Plains were handing off to clients was a folder of different markdown files and HTML components. The folder essentially serves as a brand system that allows a client to hand to an agent, and have that agent generate new assets that feel aligned to the new brand. It’s a similar approach to Design DNA that I wrote about earlier this year, and I think the system-as-a-deliverable is only going to grow in demand, sophistication and value. I wanted to continue to explore what building a system would be for products vs. brands, where interaction and product feel were key components.

System-as-a-Deliverable

In fact the system-as-a-deliverable might just allow us to finally realize a productization of design services. For years and years design services firms have tried and failed to take their thinking and craft, and package it into products with more simple pricing structures that would create predictable revenue. For clients, buying hours of a firm’s time is ambiguous and filled with nuance. For the firm, selling hours makes staffing and maintaining margins a challenge. Allowing firms a way to sell a thing that clients can leverage directly, without an intermediary, would solve a lot of headaches. Clients know what they’re buying and what it does. Firms have a tangible outcome to work against. The product/brand system could very well be that thing.

Why Not Markdown

Now design system are nothing new, but what most design/brand systems aim to achieve is to separate the hard and soft entities of the system. Hard qualities being typography, components, color, etc. These things are easily machine readable and require zero interpretation. HTML and json are the common formats. Soft entities would be things like tone, personality, posture; anything that gives meaning to the hard data. It’s in those facets where markdown is most frequently used. It’s cheap to generate, it’s easily interpreted by both machine and human, and it’s an un-opinionated format that provides designers the surface to record more expressive concepts.

Markdown has a lot of limitations though. While it’s accessible and flexible, it requires an agent to perform a lot of interpretation, which for a probabilistic outcomes means that different agent instances will interpret the markdown differently. It works great for one-time instructions, but for a system, which by nature requires structure, it lacks predictability and consistency.

So how do we create product systems that encapsulate both hard values and soft concepts, without relying on inconsistent interpretation of markdown files.

Slop is Good

I would say we’re about 3 years into the AI era, and AI slop has kind of become a fact of life. For everything designed thing there are a fifty slop versions of it. Sure it’s annoying for designers, but I actually think it’s annoying for consumers as well; it makes an already chaotic marketplace even more noisy. However slop does something useful; it serves as a predictable baseline that agents innately understand. In the design industry we’ve been having the debate about whether AI is a floor raiser or ceiling raiser — and I’m not 100% sold on the idea that’s it’s raised the floor, but I do believe that a design floor has been somewhat calcified as a baseline for “correct” design. Whether you choose to build something on top of that floor, or if you decide the baseline is good enough is a separate debate, but regardless, what we have in this era of design is a mutual understanding between humans and agents of what basic, generic design is — and that’s something we can use.

Now, instead of a collection of markdown files describing every in and out of a product from the ground up, all our product system needs to do is highlight where and how our product separates itself from the baseline; what are the facets of our product unique.

Writing Rules

In a world where LLMs are generating interfaces, our job moves from designing screens that embody or guide a concept, to creating the rules that give a concept shape. Rules-making and screen-designing really aren’t that different — a rule is just a pattern — and the way we create those rules doesn’t need to change, only our canvas does. We can still design screens, but instead of those screens being utilized as executional artifacts, they are instead consumed by agents as rules. What I’ve learned is that the practice of designing is often the best way to think through a problem or a concept. Similar to writing, designing is thinking; the feedback that you get from translating an idea from your brain to a surface is a critical facet of the evaluating and formulating a thought. That’s the part of design that we shouldn’t mess with, even if the canvas we design on changes.

Rubrick

So what does all of this look like in practice? Well I built this into a tool called Rubrick, which an MCP server that reads a designed product and compiles its product system — not a document about the product, but a running schematic of it. You point it at the source and it walks, records and grades the whole thing: the components, the styles, the motion, the way pieces are composed and how they behave. For each facet of a product it works out where the product departs from the generic baseline an LLM would reach for on its own, and those departures — across composition, density, color, elevation, interaction, motion, and material — become the system. Everything the baseline would already do, it discards. What’s left is only what makes the product itself intentional.

The reason to capture it this way is that the result isn’t a description an agent has to interpret such as a markdown document — it’s a set of properties an agent can consume directly, and, more importantly, be measured against. Rubrick doesn’t just hand an agent context and hope that it reads it the way we intended. It understands and makes concrete the characteristics and concepts that make a product’s design intentional. There’s an enormous difference between telling an agent “make it feel like us” and being able to verify, objectively, whether it actually did. That verification is what gives a pile of more qualitative concepts and ideas the consistency of a system, instead of the variance of an instruction. It also helps answer where judgment lives and how it’s codified. The judgment happens when a designer designs a product, and then when a they reviews Rubrick’s read the system. After that the system is concrete; the agent doesn’t get to decide what the brand is; it only gets to be told when it’s wrong.

Rubrick works in two parts: creating a product system and then consuming a product system. To create a product system you simply point Rubrick at a product and it produces and caches the system. You can then looked at learned.json to see what was captured, sharpen the why behind each move, and decide what actually matters.

Building with a product system is pretty simple; any coding agent with Rubrick registered pulls the system as context before it builds, and calls the conformance check on its own work until nothing’s drifting. You can build in one of two ways — reproduce the product’s dispositions (this is the ‘feel’ of the product) and layer on a separate brand or design system; or you can build an aesthetically accurate product with actual typefaces and palette — for instance a sibling product or a new feature that looks like it already shipped inside it.

Getting it running is pretty straghtforward. It installs as a Python package which exposes a rubrick-mcp command you register with your coding agent like any other MCP server, pointed at your Anthropic key and a RUBRICK_HOME where the compiled systems live. After that you’ll have access to three tools:

• compile_product_system to read an existing product and create a system.

• get_product_system to call the system.

• check_conformance to build against it.

Some Examples

To test Rubrick I gave it two distinct products with two very different aesthetics, an NFL stats app and a maritime vessel locator. I created product systems for both apps and then had Claude Code build me two calendar apps, with similar prompts, but with each consuming a different product system.

Here is an example prompt:

  Build a small React page for a **calendar app** — a month grid with events,
  clicking a day or
  > event opens/zooms to a detail — as **a native feature of {Original Product} ** using
  the **{Original Product}** product
  > system from the Rubrick MCP server. This is NATIVE mode: reuse {Original Product}
  ACTUAL faces and DARK
  > palette, not your own.
  >
  > First call `get_product_system("{Original Product}")` and read BOTH:
  > - the **`_checklist`** — every requirement, each with a **WHY** clause.
  Build to the WHY, not just
  >   to pass the check.
  > - the **`_guide`** — build order, how to read the gate, and
  `you_own_these_the_gate_cannot_check`
  >   (motion smoothness, color harmony, type layout, material feel). The gate
  can't verify those; you own them.
  >
  > Also read each style facet's `concrete` **anchors** — {Original Product} REAL faces
  (`Calibre` body,
  > `Karbon` stencil display, `FoundersGroteskMono`, `Metric`, wired in
  `globals.css`) and REAL dark
  > palette. USE them, and keep each face in ITS role (Calibre is the reading
  voice — do not swap it).
  behavior → style → polish.**                                                  
  >                                                                             
  > Then call `check_conformance("{Original Product}", <this repo path>, native=True)`,    
  read the `_formatted`                                                         
  > report, and resolve every FAIL — including `native:typography` (right faces 
  in the right roles) and                                                       
  > `native:color` (real dark palette). Re-check until no FAILs remain.         
  >                                                                             
  > **Conformance is the floor, not the finish.** Green means you didn't        
  violate the grammar — not                                                     
  > that it feels like one designer's hand. Before you call it done, also make  
  the motion smooth                                                             
  > (real easing, ~300ms tactical beats), the palette harmonious (gold marks    
  meaning on a black                                                            
  > ground), and the type layout clean (stencil display, treated mono labels).  
  If a FAIL stays                                                               
  > identical on unchanged code, it's REAL — fix the build; don't re-run hoping 
  it clears. Show me the                                                        
  > conformance report before and after, and a note on the craft you attended   
  to that the gate couldn't check. 

And here are the results:

NFL App Product System

Original app used to create the product system.

Calendar app utilizing the product system.

Maritime Vessel Locator

Original app used to create the product system.

Calendar app utilizing the product system.

This is something I’m going to keep iterating on, but you can see from the tests that while not perfect, the original app and the calendar app feel like they come from the same place despite having different purposes/jobs to be done/functionality, and despite not having access to some of the same assets like fonts. What you can’t see here is interaction and motion, but those things were captured in the product system as well.

Where We Go From Here

What I think is exciting here is two things: one is that Rubrick finds a way to use design slop productively. For as long as we have generated work, we are going to have slop. Rubrick makes slop work for us by using it as a generic baseline to score an intentional design against. Second, is that, for the longest time the business model of consulting firms and agencies has been to package their ideas and sell them as billable hours. This is fraught with all kinds of known issues and because of that agencies have pursued the “productization” of their services. However no method of productization has ever really stuck. With Rubrick, one potential path forwrad toward the productization of design services is to sell product systems. Agencies can package a design or concept or strategy in software, and deliver that software to a client allowing for more predictability in terms or cost, staffing and overall expectations on both sides of the table, because the agreed upon deliverable to a usable product.

You can try out Rubrick for yourself:

pip install git+https://github.com/tylercecchi/rubrick.git