Enterprise omnichannel UX is harder than it gets credit for. A customer who sees a product on Instagram, checks availability on the mobile site, completes the purchase on a desktop browser, picks the order up at a store kiosk, and later browses a B2B portal under their employer account is encountering five different surfaces. If those surfaces feel like five different brands, the experience fragments and the conversion math degrades quickly. Designing UX that holds together across all of those touchpoints, while respecting that each surface has its own constraints and conventions, is the actual job of the omnichannel UX team.
This guide covers what the design and engineering disciplines need to do together to keep the experience coherent without forcing a single template onto surfaces that need to behave differently.
The Design System Is the Cross-Channel Anchor
The foundation of consistent omnichannel UX is a design system that is treated as engineering infrastructure rather than a Figma library. The distinction matters: a design system that lives only in design tooling produces visual consistency by accident. A design system that is implemented as code, with versioned tokens, components, and governance, produces consistency by construction.
The three layers that need to be in place are tokens, components, and governance.
Tokens are the smallest unit: color values, spacing scales, typography sizes, border radii, motion durations, breakpoint definitions. They live in a single source of truth (often a JSON or YAML file in a shared repository) and are consumed by every channel: the web storefront’s CSS, the mobile app’s design language, the in-store kiosk’s UI framework, the marketplace listing templates, and the B2B portal. When the brand decides to shift the primary color or tighten the spacing scale, the change happens in one place and propagates.
Components sit on top of tokens: buttons, form fields, product cards, navigation patterns, cart line items. Each component has a documented API (the props it accepts), accessibility expectations, and visual variants. Components are not surface-specific; the same component definition is rendered by web, kiosk, and B2B with surface-appropriate adaptations.
Governance is the discipline that keeps the system from rotting. Who is allowed to add a new component, what review process new tokens go through, how versioning works when a component changes, how older surfaces are migrated. Without governance, the design system fragments back into per-surface drift within eighteen months.
Bemeir’s Hyva theme engagements on Adobe Commerce typically use the design system layer as the bridge between brand-level design decisions and the storefront’s component library, which means the storefront inherits brand changes the same week they are approved rather than the next quarterly release.
Unified Content and PIM Strategy
UX consistency is not just visual. It is also content. The product description, the imagery, the technical specifications, and the supporting content (size guides, fit advice, regulatory language) need to read the same on the web storefront and on the marketplace listing.
The pattern that works is content authored once, in the PIM, and distributed to every surface through structured rendering rules. The PIM becomes the system of record for product content; each surface (web, marketplace, mobile, B2B portal, in-store screen) consumes the content with surface-specific formatting rules.
This is harder than it sounds because surfaces have different constraints. Amazon truncates product titles at a different length than the web storefront. Mobile carousels show fewer attributes than desktop product pages. B2B portals need additional fields (HTS codes, country of origin, contract pricing visibility). The PIM strategy needs to capture all of those variants without forcing the merchandiser to re-author content per channel.
Shared Cart Experiences for BOPIS, ROPIS, and Ship-from-Store
The cart is where omnichannel UX gets tested in the most concrete way. A customer adding an item to their cart on the web and continuing in the mobile app expects the cart to be there. A customer choosing buy-online-pick-up-in-store (BOPIS) expects the storefront to know which store has the item and to communicate that clearly. A customer reserving online and picking up in store (ROPIS) needs a different reservation flow with different timing. Ship-from-store inventory needs to be visible to the customer without exposing the operational complexity of which warehouse or store actually fulfills the order.
The architecture that supports these patterns is the same OMS-as-broker pattern covered in integration design, but the UX layer needs to expose the right level of detail to the customer. Showing every store’s inventory in real time creates noise. Hiding it entirely creates frustration when the customer drives to the wrong location. The right pattern is to show available pickup options for the customer’s selected location with realistic prep-time estimates, surface ship-from-store as a regular shipping method without making it the customer’s problem, and let the OMS do the routing.
Progressive Disclosure for B2B Versus B2C Variants
A storefront that serves both B2C consumers and B2B buyers cannot use the same density of information for both. B2B buyers need contract pricing, bulk-quantity entry, recurring-order management, approval workflows, and tax-exempt purchasing. B2C consumers need none of those things and are confused by them.
Progressive disclosure is the design pattern that handles this. The B2C view is the default: clean, conversion-optimized, single-quantity-focused. The B2B view is unlocked by authentication or an explicit B2B portal entry, and adds the additional capabilities through sections that simply do not render for B2C accounts.
For implementations on Adobe Commerce, this is supported through customer groups, store views, and conditional theme logic. For Shopify Plus, the Shopify B2B documentation covers the customer-context model that drives progressive disclosure. Bemeir has shipped progressive-disclosure B2B portals for clients where the same storefront serves both audiences without forcing the B2B users into a separate domain.
Accessibility as Baseline, Not Afterthought
WCAG 2.2 is the baseline for any modern enterprise eCommerce surface. Accessibility cannot be a Phase 2 deliverable; it has to be embedded in the design system itself. The pattern is to make every component accessible by construction: focus indicators on every interactive element, semantic HTML in the underlying markup, color contrast ratios that pass at the token level rather than being audited per page, keyboard navigation as a first-class interaction, and screen-reader announcements for state changes.
The cost of retrofitting accessibility into an enterprise storefront is significantly higher than the cost of building it correctly from the start. The legal exposure (the U.S. has seen a steady increase in ADA-related eCommerce lawsuits) and the user-base impact (roughly one in four U.S. adults lives with some form of disability, per public CDC data) make this an executive-level concern, not a design-team concern.
The omnichannel angle adds complexity. Accessibility on a desktop web surface is not the same as accessibility on a kiosk or a mobile app. Each surface needs its own accessibility audit because the assistive technologies are different: VoiceOver on iOS, TalkBack on Android, NVDA and JAWS on Windows, and the kiosk-specific stack on whatever in-store hardware is deployed. References from Forrester consistently flag accessibility as one of the highest-ROI UX investments enterprise commerce teams underweight.
UX Surface Consistency Reference Table
| UX Surface | Consistency Requirement | Common Drift Cause | Mitigation |
|---|---|---|---|
| Web storefront (desktop) | Design system tokens, component library, content from PIM | Per-page custom CSS, override styles | Strict component governance, lint rules |
| Web storefront (mobile) | Same tokens, surface-appropriate density | Separate mobile codebase | Responsive components, no per-device code branches |
| Native mobile app | Token-equivalent values, native conventions | Hand-built app diverging from web | Shared design tokens consumed by iOS and Android |
| In-store kiosk | Tokens, larger touch targets, simplified flows | Kiosk vendor lock-in styling | Token-driven kiosk theme, no vendor template |
| Marketplace listings | Brand voice, content from PIM | Marketplace-specific fields hand-edited | PIM-driven content with marketplace adapters |
| B2B portal | Same component library, B2B disclosures unlocked | Separate B2B codebase | Single storefront, customer-context disclosure |
| Email and transactional | Tokens, brand voice, accessibility | Email vendor templates with custom styling | Token-driven email templates |
| In-store digital signage | Tokens, content from PIM | Standalone vendor design | PIM-fed signage, design-system fonts |
Putting the Pieces Together
The teams that ship coherent omnichannel UX are the ones that treat the design system, the PIM, the OMS, and the storefront as a single architecture rather than four separate procurements. The design system is what holds the visual and interaction layer together; the PIM is what holds the content layer together; the OMS is what holds the cart and inventory experience together; the storefront is the rendering layer that pulls all three into the customer’s hands.
Bemeir’s enterprise commerce work treats the omnichannel UX problem as inseparable from the integration architecture covered in our companion guidance. The surfaces only feel coherent if the data underneath them is coherent. Authoritative reference from the W3C accessibility guidelines and the Adobe Commerce frontend documentation is a starting point, but coherent omnichannel UX is a property of the team’s discipline, not the platform’s feature list. The brands that get this right are the ones who feel the same on every screen, every kiosk, and every marketplace, and the customers reward that coherence with repeat purchases.
