Research
I needed to move beyond anecdotal complaints to understand the true scope and nature of the organizational problem. Working with the support team, I analyzed tickets mentioning metafields, organization, and pinning. The pattern was unmistakable: "Can't group metafields by product type," "impossible to pin more than 20 items," "can't sort or reorder." These weren't feature requests—they were descriptions of a broken system.
I targeted Plus merchants specifically because they represented the scaling edge case—the users who would hit system limits first. Working with Merchant Success Managers, I screened approximately 2,000 merchant invitations to find participants managing 30-50+ metafield definitions across complex product catalogs.
"I have 50+ metafields and can only organize 20 of them. The rest are just... there. I can't even search for them. I keep a spreadsheet with what each field does because the admin doesn't tell me."
— Plus Merchant Interview, December 2024
Interviews revealed merchants maintained external spreadsheets to track field purposes. They created elaborate naming conventions to simulate grouping: "web_featured_image," "web_gallery," "internal_sku_mapping." Many avoided metaobjects entirely despite them being the right solution. Role-based needs emerged clearly—web designers needed different field subsets than merchandisers or operations staff.
Usage data validated the interviews. Most merchants had fewer than 20 fields, but Plus merchants consistently had 30-100+ definitions where the system broke down. Merchants who hit the 20-pin limit kept repinning fields as tasks changed—they needed contextual organization, not permanent favorites. Namespace patterns ("product." vs "internal." vs "storefront.") showed merchants trying to impose organization the system didn't support.
Looking at competitive platforms revealed opportunities. WordPress prescribed rigid hierarchies. Contentful required upfront architecture decisions. Airtable's database-first mental model didn't translate to e-commerce workflows. None had solved flexible organization serving multiple personas looking at the same data. We could leapfrog them by focusing on focus over hierarchy.
Understanding User Needs
Research revealed four distinct personas with different organizational needs. Merchandisers (40%) organized by purpose—product data, pricing, inventory—needing to see "what needs filling in." Web designers and developers (30%) organized by visibility—customer-facing versus internal fields. Operations staff (20%) organized by workflow—daily tasks versus seasonal updates. Technical users (10% but high impact) organized by source—app-created versus manual fields.
The strategic insight: The system needed to serve all four personas without prescribing one "correct" model. This pointed toward flexible custom groups as the foundational architecture.
Challenging Existing Assumptions
The initial project brief asked me to "improve metafield organization" with an implicit assumption: increase the pin limit from 20 to something higher. But I pushed back on this framing during early stakeholder meetings.
I challenged the team: Why do merchants want to "pin" fields in the first place? Research showed they weren't creating permanent favorites—they were trying to focus on relevant subsets for specific tasks. A merchandiser didn't want their 20 most important fields visible all the time. They wanted to see "product data fields" when working on product pages, then switch to "pricing fields" when running promotions. Same merchant, different contexts. Rather than increasing the pin limit to 40 or 100, we needed contextual grouping that let merchants create multiple lenses on the same data.
The existing pin system assumed metafield management was an individual task. But Plus merchant interviews revealed most custom data work involved multiple roles touching different subsets of fields. A web designer needed to see storefront fields. A merchandiser needed product data fields. An operations manager needed fulfillment fields. They were all working in the same admin, on the same products, but needed completely different views. Custom groups needed to support role-based workflows, not just personal preferences.
Contentful required upfront content modeling decisions. WordPress required manual field group creation. Both imposed configuration burden before merchants could benefit from organization. I advocated for auto-generated groups that provided value immediately without configuration: "Filled" (fields with values), "Apps" (app-created fields), namespace-based groups (emerge automatically from naming conventions). The system should work well with zero configuration while enabling power users to create sophisticated custom organizations.
Ideation and Design
I drove design exploration through rapid prototyping, testing multiple organizational paradigms to understand their trade-offs before committing to one approach.
During the first week, I prototyped folders, tags, and groups. Folders (hierarchical organization with nesting) failed because metafields don't naturally nest—a field can be both "storefront" and "product data" simultaneously. Tags (freeform labels similar to Gmail) were too flexible—merchants would create inconsistent taxonomies and organizational chaos would re-emerge at scale. Groups (named collections with explicit membership) provided structure without rigid hierarchy. Fields could belong to multiple groups. Groups balanced flexibility and structure, matching how merchants talked about organization ("my storefront fields," "product data fields") without imposing technical mental models.
Week two explored manual versus auto-generated groups. I prototyped two extremes: fully manual (merchants create all groups from scratch—maximum flexibility but high setup cost) and fully automatic (system infers groups from naming patterns and usage—lower setup cost but couldn't adapt to unique merchant needs). The solution was a hybrid approach: auto-generate useful defaults (Filled, Apps, Namespaces) that work immediately, while enabling merchants to create custom groups that match their specific workflows.
Testing group UI patterns in week three revealed important insights. Tabs were a familiar pattern but implied mutually exclusive membership—a field in "Storefront" couldn't also be in "Product Data." Collapsible sections allowed seeing multiple groups simultaneously but created visual clutter when merchants had many groups. A segmented control with list kept the interface clean, showing one group at a time but making context switching easy. It matched the merchant mental model of "show me this subset."
If merchants needed to manually add 50 fields to groups one by one, the feature would fail. I designed bulk operations into the foundation during week four: multi-select with checkbox pattern (familiar from products/collections), "Add to group" action that shows available groups, ability to create new groups during bulk action, and search that works across all fields regardless of current group view. This made group creation practical at scale rather than a nice-to-have feature only useful for small catalogs.
Three Core Design Principles
Through prototyping and iteration, three architectural principles emerged that would guide all design decisions.
Traditional file systems use hierarchical folders where every item lives in exactly one place. This creates artificial constraints: Is a field "product data" or "storefront"? Both? Neither? Groups solve this by letting fields exist in multiple groups simultaneously. A "featured_image" metafield belongs to both the "Storefront" group (it renders on product pages) and the "Product Data" group (it's core product information). Groups aren't containers—they're lenses. Switching groups doesn't move fields; it changes what you're looking at. This principle of organization being about focus, not hierarchybecame foundational.
The system should provide value immediately without configuration while enabling merchants to create sophisticated organizations as their needs grow. At level one with zero configuration, auto-generated groups show everything ("All"), highlight fields with values ("Filled"), and segregate app-created fields ("Apps"). At level two with light customization, merchants create 2-3 custom groups for common workflows ("Storefront," "Internal"). At level three with power usage, merchants maintain role-specific groups, project-based groups, seasonal groups—the system scales to their sophistication. Every merchant sees value on day one. Advanced usage is possible but never required. This smart defaults enable progressive sophistication principle rejected the false choice between "simple for beginners" and "powerful for experts."
The existing flat list treated all metafields identically. This failed because not all fields are equally important at any given moment. I designed stronger visual distinction to help merchants instantly assess field status: filled fields with values appear visually distinct from empty fields (what needs attention), pinned fields remain accessible even when viewing groups (persistent favorites), app-created fields show app icons (audit data provenance), and category-restricted fields show category badges (understand field availability). Merchants can scan a list and immediately understand field status, source, and relevance without reading every label. Visual hierarchy reduces cognitive load by making information scannable rather than forcing merchants to read and process every detail.
Cross-Team Collaboration and Influence
Custom grouping didn't exist in isolation. It was part of a broader metafield creation flow redesign that touched multiple teams and required strategic alignment.
During the a team sync I discovered another team was solving adjacent problems. They were redesigning how attributes appear on product pages while I was redesigning metafield organization. Key alignment discussion: Should category-restricted metafields appear in the "Attributes" section or "Metafields" section? I advocated for keeping them in metafields to maintain semantic accuracy—attributes are Shopify-generated (ML-inferred), metafields are merchant-created (even when category-restricted). We aligned on progressive disclosure patterns that would work consistently across both attributes and metafields. Expanded/collapsed states, search patterns, and bulk operations would feel familiar regardless of section.
Working closely with the designated Front End Developer throughout exploration ensured technical constraints informed design decisions early. Key conversations shaped the solution: Should groups be server-side (persisted to database) or client-side (browser local storage)? We chose server-side for cross-device consistency, even though it required more backend work. How would "Filled" group update as merchants add values? We decided on computed on page load rather than cached to ensure accuracy. Would search across 100+ fields create latency? Client-side filtering was fast enough—we didn't need backend search infrastructure. Design decisions were technically feasible from day one. No late-stage "we can't build this" surprises because engineering was involved throughout exploration.
Final Designs
I maintained pixel-level quality throughout, ensuring every interaction state was documented for implementation.
The group management interface uses a segmented control at the top that lets merchants switch between groups. Auto-generated groups (All, Filled, Apps) appear first, followed by custom groups in merchant-defined order. The field list shows current group members with enhanced visual hierarchy—filled fields appear with subtle visual distinction, source indicators show app-created fields, category badges show scope restrictions. Bulk actions enable multi-select with checkbox pattern, and the "Add to group" action shows a modal with existing groups and "Create new group" option.
The modal pattern maintains context during group creation. Merchants name the group ("Storefront," "Product Data," "Merchandising") and select member fields in one flow. Search works across all fields, not just the currently selected group, enabling merchants to quickly find fields by name regardless of current context.
Stronger visual design helps merchants quickly assess field status: filled fields show value preview or count, empty fields appear muted until interaction, app-created fields show app icon for provenance, category-restricted fields show category badge, and pinned fields maintain pin icon across all groups. This visual language reduces cognitive load—merchants scan and understand without reading every label.
Solution
The custom grouping system addressed the scaling problem through four integrated features that work together seamlessly.
Merchants create named groups that adapt to their workflows. A web designer creates a "Storefront" group containing only customer-facing fields. A merchandiser creates a "Product Data" group for inventory and pricing fields. The same field can exist in multiple groups—"featured_image" appears in both "Storefront" and "Product Data" because it serves both purposes. Groups are lenses, not containers. Switching groups changes what you're looking at, not where fields live.
Multi-select enables adding 20+ fields to groups in one action through bulk operations. Search works across all fields regardless of current grouping. Merchants can create new groups during bulk actions without interrupting their workflow. Organization at scale had to be practical in minutes, not hours—otherwise merchants would avoid the feature.
Enhanced visual hierarchy helps merchants instantly assess field status. Filled fields show value preview or count, empty fields appear muted until interaction, app-created fields display app icon for provenance, category-restricted fields show category badge, and pinned fields maintain pin icon across all groups. This reduces cognitive load by making field status, source, and relevance scannable without reading labels.
Outcome and Reflections
The custom grouping system transformed metafield organization from a rigid 20-pin limitation into a flexible, scalable architecture that adapts to merchant workflows.
The direct merchant value was immediate: eliminated the 20-pin scaling cliff entirely so merchants now organize 100+ fields effectively, zero configuration required to see value as auto-generated groups work immediately, search across all fields regardless of grouping eliminated scrolling to find fields, and bulk operations enable organizing 50+ fields in minutes, not hours.
System-level impact extended beyond the immediate feature. We unblocked the Markets team to ship complex features requiring sophisticated custom data management. Product Create team referenced grouping patterns for attributes organization. "Can't find my metafield" support tickets reduced significantly (quantified post-launch). We established reusable progressive disclosure patterns for other admin areas.
Platform health improvements positioned Shopify for growth. Clearer organization improves developer confidence when building with custom data, enabling app ecosystem growth. We positioned Shopify to support even more complex use cases as merchants grow. The work demonstrated that "simplification" doesn't mean removal—it means smart defaults with progressive sophistication.
Leadership feedback captured the strategic value: "This is the kind of thinking we need—solving the immediate problem while establishing patterns that improve the entire platform."
Key Lessons
The initial ask was to raise the 20-pin limit to something higher (40? 100?). But research revealed pinning was the wrong mental model entirely. Merchants needed contextual focus, not permanent favorites. By questioning the brief, I designed a solution that served more use cases better than simply extending a broken pattern. The lesson: "Increase the pin limit" wasn't the right problem.
I targeted Plus merchants with 50-100+ fields because they represented the system's breaking point. But the patterns that solved their problems (auto-generated groups, search, visual hierarchy) improved the experience for all merchants, even those with just 10 fields. Designing for the scaling edge case benefited everyone. Solving for the hardest case often reveals universal truths.
I built interactive prototypes for folders, tags, and groups not to show stakeholders polished options but to experience their trade-offs myself. Prototyping is a thinking tool, not just a communication tool. The act of building reveals problems that static mocks never surface. I learned more from 4 hours with React than from 2 days of Figma exploration.
I provided comprehensive interaction specs covering all states, responsive behaviors, animation timing, keyboard navigation, and accessibility requirements. This investment upfront eliminated ambiguity during implementation and reduced back-and-forth with engineering. Documentation accelerates implementation and reduces thrash. Well-documented designs ship faster and more accurately.
