Weedmaps · Regulated marketplace · Compliance design
Making legal limits understandable before checkout
A cart and checkout system for state-specific purchase limits — turning a late-stage order failure into an earlier, more explainable moment of recovery.
Context
This work was for Weedmaps, a regulated marketplace where consumers discover products, compare options, and place orders through local retailers.
In this category, completing an order depends on more than inventory, payment, and fulfillment. State-level rules can determine how much a person is allowed to purchase in a single day, and those limits can vary by product category and user qualification.
When a cart crossed one of those limits, the failure often surfaced too late: after the user had already committed to checkout. The system knew there was a rule. The experience was not making that rule visible soon enough.
The brief
What was asked for
Add order-limit messaging to cart and checkout so users could be warned when their cart appeared to exceed state purchase limits.
What it actually was
A scalable compliance system that could adapt to different jurisdictions, enforcement levels, product taxonomies, data certainty, and recovery paths without turning every legal rule into the same generic error state.
Constraints
Every project has the constraints you negotiate and the ones you live inside. The ones that shaped this work:
- Purchase limits varied by jurisdiction, product category, and user qualification.
- Some states required a warning; others required the platform to prevent checkout when limits were exceeded.
- Integration coverage was uneven, so the system sometimes had to communicate uncertainty rather than a confirmed violation.
- The experience needed to be specific enough to help users fix the cart without overwhelming everyone who was still within limits.
- Blocking checkout carried conversion risk, but letting non-compliant orders proceed carried legal and operational risk.
- The system had to scale beyond one state, one rule, or one product category.
Decisions
Design for enforcement levels, not one generic error state
A single warning pattern would have been easier to build, but it would have flattened meaningful legal differences. I separated the experience into soft warnings, hard blockers, and uncertainty states so the interface could match the actual obligation instead of forcing every condition into the same component.
Make category-level guidance the recovery path
'Your cart exceeds the limit' is accurate, but not actionable. Users need to know which part of the cart is creating the problem. I pushed for category-level feedback so the experience could show where the cart was over, where it was still within range, and what kind of item needed attention.
Use copy to communicate certainty
The system could not always know the user's full purchase history or every downstream condition. That made copy precision important. Softer language was used when the platform could identify risk but not absolute certainty. More direct language was reserved for conditions where enforcement was required and the user's next step needed to be unambiguous.
Preserve momentum even when checkout had to stop
The blocker could not feel like an arbitrary wall. When checkout was unavailable, the next action had to remain obvious: return to the cart, identify the category creating the issue, and remove or adjust items. The goal was not to hide friction. It was to make recovery possible.
Build a configurable pattern instead of a one-state fix
Because rules could vary by state, product taxonomy, user qualification, and integration support, the design needed to scale. I treated the work as a component system with configurable thresholds, copy, and behaviors rather than a one-off banner for a single launch.
Tradeoffs
- Conversion vs. compliance — chose stop checkout when required instead of preserving a cleaner funnel over a streamlined checkout that could produce downstream order failures.
- Simplicity vs. actionability — chose category-level guidance over a shorter generic warning over a minimal warning that did not help users fix the problem.
- Certainty vs. honesty — chose precise copy that reflected what the system could and could not know over overstating compliance certainty to appear more authoritative.
- Universal pattern vs. jurisdiction fit — chose a configurable system that could adapt to different legal requirements over one universal state that would not fit every jurisdiction.
- Progressive disclosure vs. transparency — chose lightweight entry points with deeper explanations available when needed over showing all details upfront and overwhelming users within limits.
Working with the room
Compliance work sits at the intersection of legal interpretation, engineering feasibility, operational risk, and user comprehension. Each group was looking at a different version of the problem: what the law required, what the system could detect, what checkout could block, and what a user would understand in the moment. I used state diagrams, copy variants, annotated flows, and component logic to make those differences visible. Instead of treating the experience as a banner request, I framed the work around the conditions the product needed to support: when to warn, when to block, when to explain uncertainty, and how to help users recover.
Outcome
The final system gave the team a clearer way to handle purchase-limit rules across cart and checkout. It reduced reliance on generic downstream failures, created a more understandable recovery path for users, and gave legal, product, and engineering partners a shared model for future compliance states. More importantly, it treated compliance as part of the user experience rather than an external rule applied at the end. The work did not remove the constraint. It made the constraint visible, specific, and easier to act on.
In hindsight
Good compliance design does not make the rule disappear. It makes the rule usable. The most important insight was that legal requirements are product requirements: the distinction between a warning and a blocker was not a matter of UX preference, but what the product was obligated to enforce. Specificity is what creates recovery — a compliant message is not enough without enough detail to understand what changed and what to do next. And uncertainty needs its own design state: not every condition is a clean yes or no, and designing for partial data is different from designing for confirmed failure. The real value was the logic underneath it: a scalable way to map rules, states, and user actions across a regulated marketplace.
Next case study →
Explaining an unexpected discount at checkout
Weedmaps · Checkout · Pricing trust