A Pattern Library Page That Counts Components, Not Repeated Decorations
A pattern library page is meant to show what a website is made of. It often goes wrong in one specific way: a divider, a corner flourish or a background motif appears twenty times on a demo page, and the inventory ends up claiming twenty components. This article proposes a small inventory artifact that keeps the visual richness of the demo while keeping the delivered list honest. Everything below is a proposed example, not a result observed at any client.
Inputs to gather
Start with one public sample page, for example a made up bakery site called Sample Bakery. Collect three things. First, a list of every decorative element visible on the page, written by looking at the page, not by reading its source. Second, a short written purpose for each element, such as separating two sections or framing a heading. Third, the rule your team uses for what counts as a delivered component: something a site owner can reuse, edit or place independently.
Decision branches
For each decorative element, ask whether it has its own settings. If an owner can change its content, size or placement independently of other elements, treat it as a component and give it a row.
If the element is the same artwork repeated with no individual settings, treat it as one component with several instances. Write one row and add an instance count column.
If the element is part of another component, such as a corner flourish that only exists inside a card, record it as a part of that card. It gets no row of its own.
If you cannot tell which branch applies, mark the row as undecided and ask the person who built it. Do not guess in the public copy.
Stop conditions
Stop and resolve before publishing if any row has no written purpose, if two rows describe the same artwork under different names, or if the instance count was typed from memory rather than counted on the page. Also stop if the page headline promises a total number of components that the table does not support.
A worked example
On the Sample Bakery page the looker finds a wheat stalk divider shown six times, a flour dust texture behind two sections, and a ribbon frame around three product cards. The inventory has three component rows: Wheat divider, one component, six instances. Flour texture, one component, two instances. Product card, one component, three instances. The ribbon frame is recorded as a part of Product card, appearing three times inside those cards, and gets no independent row. The page therefore says three components. The demo displays eleven decorative appearances: six dividers, two textures and three ribbons. A footnote explains the difference in plain words: some components appear more than once, and some artwork is only a part of a component.
Presentation on the page
Place the inventory table beside or below the demo. Use the column headings Component, Purpose, Instances on this page and Part of. Keep wording neutral, and avoid saying the library is complete or that it follows any named design standard. If a visitor asks what they receive, the table answers it without extra promises.
An actionable acceptance test
Print or screenshot the demo page and give it to a colleague who has not seen the inventory. Ask them to circle each distinct decorative artwork. Then compare their circled artworks with your table, and their repeated marks with your Instances column.
In the example, the colleague should find three distinct artworks: wheat divider, flour texture and ribbon frame. Your table accounts for them as two component rows (Wheat divider and Flour texture) plus one part (the ribbon frame, listed under Product card). Product card is the third deliverable component row, but it is a container, not a separate decorative artwork, so it does not appear among the circled artworks. The test passes if every circled artwork maps to exactly one component row or one part entry, and every repeated mark maps to exactly one instance count. The number of deliverable components is read from the Component column alone. If the colleague finds an artwork you did not list, add a row or decide it is part of another component. If they merge two things you separated, check whether the two really have independent settings. Repeat the test with a second colleague once the table changes.
Conclusion
The goal is not to make the library look smaller. It is to make the claim match the deliverable. By separating components, instances and parts, you let the demo stay generous with decoration while the list tells buyers precisely what they can reuse. Keep the table with the page, update it whenever an element is added, and run the circling test before each publication.