design-ecommerce
Skill3 starsChanged 49 days agoMITView on GitHub
Ecommerce / product site lens. Use when the site's purpose is to sell physical or digital products — online stores, product detail pages, catalogues, shopping cart flows. Load after design-core has established why the site exists and confirmed the goal is purchase. Does not replace design-core; adds subtype-specific priorities, typical failures, and layer-by-layer guidance.
In this repository5 other files it gives its agents.
- design-coreSkill
- design-infoSkill
- design-portfolioSkill
- design-promoSkill
- design-saasSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Indistinguishable cards: Every card looks the same, so no card is remembered.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design Ecommerce — Stores & Product Pages
A subtype lens for design-core. Load this after design-core has run its three entry steps and confirmed the goal is purchase.
This file does not redefine the eight elements, the four layers, the two modes, or the two phases. It only adds what is specific to ecommerce sites.
Focus
Usability beats beauty, but a product card can be a piece. The purchase path runs without friction — every step the visitor must take is one step too many. Trust is visible early: shipping, returns, guarantees, reviews appear before the visitor has to wonder. Comparison between products is easy, not hidden behind a filter maze.
Marketing leads by default. The floor is non-negotiable: contrast, click zones, focus, body size.
Typical failures
- Indistinguishable cards. Every card looks the same, so no card is remembered. Fix: let the product dictate the card's hierarchy — image, name, price, not a uniform template.
- Price or availability buried. The two facts a buyer needs first are the two facts hidden last. Fix: price and availability are visible on the card, not only on the detail page.
- Heavy filters. Ten filter dimensions, none applied by default, all distracting. Fix: filters reduce results, not attention.
- Checkout that suddenly complicates. The cart works, then step 2 asks for a phone number, then step 3 requires an account. Fix: every step past "add to cart" must justify its existence.
Layer-by-layer
Frame (composition, space). The card grid is stable — one rhythm, even gaps, no surprises. Space between cards is consistent so the eye can scan, not re-orient per row. Navigation (categories, search) is a working tool, not a hero.
Body (form, color). Color serves the product. The palette recedes — the products provide the color. Button forms are unambiguous: "add to cart" is a distinct shape, "add to wishlist" is visibly secondary. Radius system is one token, applied consistently.
Surface (texture, typography). Price and product name are typographically clear — the two things that must be readable at a glance. Description text is readable at body size, not shrunk to make room. Product images are treated as surfaces, not just thumbnails.
Accent (point, line). The primary action is obvious everywhere it appears. Icons (cart, search, wishlist) are consistent in weight. Dividers and rules stay out of the way unless they separate distinct sections.
Reading order
The ecommerce flow has three distinct reading orders, and each is optimized for its own step:
- Browse — categories are scannable, products are distinguishable, price/availability visible.
- Decide — detail page answers the buyer's real questions (material, size, delivery, returns) in the order they arise.
- Buy — checkout confirms, doesn't interrogate. Every field has a visible reason.
Audit specifics
Beyond the common grid, these are the ecommerce breakages to hunt:
- Typography → Surface → price and availability not readable on the card → the two facts a buyer needs first are on the card, not only on the detail page.
- Form → Body → "add to cart" reads as decoration on the product image → shape and contrast distinct from the rest of the card.
- Point → Accent → cart/wishlist/search icons differ in weight → one icon system, aligned to the type baseline.
- Line → Frame → filters demand attention before they reduce results → filters cut results, not attention; sensible defaults applied.
- Space → Frame → checkout compresses every step into one nervous screen → each step past "add to cart" justifies its existence, with air between decisions.
Return to core
For the method, see design-core/SKILL.md. For the marketing filter (which runs here), see design-core/references/marketing.md. For the words on the page — which sell at least as hard as the visuals — see design-core/references/copy.md. For the layers protocol, see design-core/references/layers.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

