MHMatt HomcoPrincipal Product Designer

Enterprise Product Design / Complex UX / Frontend Development

Designing an Enterprise Samples Portal

Turning a largely manual promotional-ordering process into a production application spanning product discovery, conditional ordering, administration, and operational management.

Project statusCompleted extensive UAT and entered production.

From a manual request process to a connected product.

The Samples Portal was a new enterprise application for authorized promotional partners and internal operational stakeholders. It digitized a largely manual promotional-samples request process, connecting product discovery and ordering with administration and operational management.

I personally owned the new application’s complete frontend UX/UI design and implementation from discovery through production. It occupied roughly a year or less of an approximately 2.5-year engagement that also included substantial new capabilities within two established enterprise platforms.

Conceptual product map

Three connected areas. One request ecosystem.

Request and shop

Configure requests, browse products, and build orders.

  • Request context
  • Product discovery
  • Cart & order

Process and fulfill

Review incoming requests, coordinate fulfillment, and track progress.

  • Incoming requests
  • Fulfillment coordination
  • Request status

Configure the system

Maintain the regional settings and business rules that determine how requests work.

  • Regional configuration
  • Ordering policies
  • Reference data

Simplified product relationships, not original interface screens. Ordering, operational work, and configuration were connected parts of the portal.

Understanding the work behind a sample request.

I conducted discovery meetings with primary client stakeholders, gathered requirements, and worked through the business processes behind the manual request experience.

Administrators maintained operational and regional configuration affecting requester choices, applicable policies, and how requests were processed. Discovery connected the requester journey with the administrator-managed business rules behind it.

Make the decisions tangible before building.

I designed high-fidelity, interactive Figma prototypes for both the ordering experience and substantial administrative interfaces. I presented them to stakeholders, gathered feedback, and iterated through multiple review cycles to work through complex requirements.

One request flow, different paths.

The request experience adapted to rules influenced by sales center, co-op arrangement, sales channel, and fulfillment method. Depending on the applicable rules, fulfillment options became available or unavailable, and different fields or sections appeared.

The design challenge was to expose relevant questions and explain constraints while keeping the request understandable. Requester-facing behavior had to remain connected to the operational and regional information maintained by administrators.

Interactive / Illustrative reconstruction

A request form that responds to context.

Fictional organizations, details, and invented example rules demonstrate conditional behavior. These are not original client policies. Nothing is ordered, charged, or submitted.

Promotional requestFictional example · Local state only
  1. 01 / Configure
  2. 02 / Review

Request context

All visible fields are required. Example values can be edited.

Fulfillment method

Invented rule: Cedar supports pickup and delivery.

Review your choices next. There is no checkout or order submission.

Example ready. Change the request context to explore the invented rules.

A regional change reached beyond the form.

Expanding from U.S. operations to Canada introduced considerations around currency, regional fees and deposits, geographic qualifiers, and administrative reference data.

The ordering experience had to reflect the relevant regional context, with frontend behavior coordinated with backend calculations. Supporting that expansion also meant accounting for administrative complexity, not simply adding a country choice.

Conceptual regional configuration

U.S. operationsCanada expansion
  1. Regional context

    Currency, geographic qualifiers, and administrative reference data.

  2. Ordering experience

    Relevant choices, fields, and regional information in the frontend.

  3. Backend coordination

    Regional fees, deposits, and calculations coordinated with backend functionality.

Conceptual relationships only. No actual rates, formulas, client policies, or database structures are represented.

Ownership from prototype through production.

The frontend implementation covered both the ordering experience and administrative interfaces. I worked closely with a backend engineer responsible for backend functionality, calculations, and integrations.

I participated in extensive client UAT, resolved issues across request scenarios, and supported production delivery. The portal entered production with an initial U.S. scope and later expanded to Canada.

Extending established enterprise platforms.

Alongside the new Samples Portal, I enhanced two substantial platforms that already existed when I joined: an internal chain-funding platform and a bottler-facing funding platform. My work included enhancements and entirely new administrative capabilities within those products.

Country management and parent-brand management were particularly substantial additions. For both, I collaborated with client stakeholders on requirements and design and personally implemented the frontend.

Established internal platform

Chain funding

  • Chain and call-point management
  • Pricing plans, discounts, promotions, and funding
  • Forecasting and annual reporting
  • Contracts, authorizations, and administrative workflows

Established partner platform

Bottler funding

  • Brand and product operations
  • Ordering and pricing operations
  • Support for an expanding beverage-brand portfolio
Conceptual scope overview, not original product screens. Both platforms predated my involvement; I enhanced them and delivered new frontend capabilities within them.

Designing geographic configuration.

I designed and implemented a country-management experience across the two established platforms. Previously limited geographic configuration became an administrative workflow in which authorized users could manage country records, currency information, effective dates, status, and platform visibility.

This work translated geographic expansion into configurable administrative decisions while keeping the relevant properties and availability understandable.

Conceptual configuration anatomy

Country configurationAdministrator-managed properties

Country identity

  • Country name
  • Abbreviation

Regional properties

  • Currency information
  • Effective dates

Status & visibility

  • Active / inactive
  • Internal platform visibility
  • Partner platform visibility
Original conceptual illustration, not an original product screen or database model. Property categories show the scope of the administrative experience; no client records, logos, brand colors, or assets are reproduced.

Making brand expansion configurable.

I designed and implemented an administrative experience for introducing and managing parent brands. It supported creating and configuring parent brands, uploading multiple logo formats and other assets, and previewing brand-specific presentation across different interface contexts.

Brand-specific colors and assets required careful attention to consistency. The experience supported an expanding brand portfolio through reusable configuration and preview patterns, rather than treating every addition as a separate design problem.

Conceptual configuration anatomy

Parent-brand configurationAdministrator-managed properties

Brand definition

  • Parent-brand configuration
  • Brand presentation

Asset management

  • Multiple logo formats
  • Other brand assets

Contextual preview

  • Brand-specific color treatments
  • Presentation across interface contexts
Original conceptual illustration, not an original product screen or database model. Property categories show the scope of the administrative experience; no client records, logos, brand colors, or assets are reproduced.

Enterprise policies become interaction decisions.

  • Model conditional paths explicitly, including unavailable choices and the reasons behind them.
  • Reveal relevant questions while preserving useful context as inputs change.
  • Connect requester interactions, operational tools, and administrator-managed configuration.
  • Design for geographic and brand expansion within established products, alongside continued engineering and backend collaboration.
  • Carry design intent into implementation and validate the resulting behavior with stakeholders.