Skip to main content
Brian Williams.

Real commercial work

Designing and building for commerce.

A commercial eCommerce platform I designed and developed, generating more than $3M in annual revenue. This real project complements my representative enterprise product case studies.

Real commercial workCommercial design + development

$3M+

Annual platform revenue

The platform generated more than $3M in annual revenue. This is a platform-level commercial outcome and is not attributed to a single UX change.

Verified project facts

Brian designed and developed a commercial eCommerce platform.

The supplied résumé confirms customer journeys, marketing funnels, product flows, responsive layouts, and custom modules in this role. It also confirms WordPress theme and WooCommerce extension development; it does not identify an exact production screen inventory. This page keeps verified career facts separate from illustrative journey and interface reconstructions.

Product designUX/UIFront-end developmentWordPress themesWooCommerce extensionsHTMLCSS

Design + development · commercial experience

From product discovery to a dependable order.

The commercial platform is real work. The interface studies below are portfolio reconstructions—not archived production screens—and use fictional storefront content to make the customer path and design decisions legible.

Real commercial work
01 / DISCOVERCustomer decision point“Is this relevant to me?”
02 / BROWSECustomer decision point“Can I find the right option?”
03 / EVALUATECustomer decision point“Is this the right product?”
04 / SELECTCustomer decision point“What configuration do I need?”
05 / CARTCustomer decision point“Did I choose correctly?”
06 / CHECKOUTCustomer decision point“Can I complete this clearly?”
07 / CONFIRMCustomer decision point“What happens next?”
Continuity to protectChosen item · selected options · quantity · price · next step
STORE STRUCTURE / REPRESENTATIVE MODELBrowse → evaluate → purchase
Storefront
SearchCollectionProduct detailCartCheckoutConfirmation

Representative commerce structure · generic features only; no platform-specific architecture implied.

01 / Customer path as a decision sequence

Portfolio reconstructionNot production screenshots

Problem: A commerce journey crosses several moments of uncertainty; a polished page alone cannot show how a customer progresses.

Decision: Map each stage to the question a customer needs answered before moving on.

Why: The sequence links discovery, selection, cart, checkout, and confirmation without claiming a verified production information architecture.

Tradeoff: This is a journey model, not a complete site map.

A / Browse-ledMore items in view

Strength: quick scanning and comparison across a collection.

Watch for: product-specific configuration moves to the next step.

B / Detail-ledSelection stays in context

Strength: options, supporting information, and the primary action remain together.

Watch for: less collection context while evaluating one item.

Conceptual exploration · tradeoffs shown for discussion, not a claim about historical project decisions.

02 / Conceptual exploration: where comparison belongs

Portfolio reconstructionNot production screenshots

Problem: A small viewport has limited room for both product choice and supporting detail.

Decision: Compare two plausible patterns: a filter-led browse with cards, and a focused product detail with choices beside the image.

Why: Making the competing jobs visible clarifies where scanability, product context, and selection controls need emphasis.

Tradeoff: These are conceptual alternatives for explaining a design question, not evidence that one direction was historically rejected.

COMMON / OBJECTS
⌕   Search the collection

Explore / collection

Considered forms

08 pieces
Showing 8 objectsSort: Featured⌄
Low form / vessel$48Stoneware · 3 finishes
Soft edge / vase$72Hand-finished · 2 sizes
Arc / table light$116Powder-coated metal

Common Objects collection interface

1 / 1
Illustrative UI · fictional data

03 / Collection view built for quick comparison

Portfolio reconstructionNot production screenshots

Problem: Collection pages ask customers to scan several products while keeping price and useful distinctions easy to locate.

Decision: Pair a compact filter rail with a consistent product grid, visible item count, and concise card-level information.

Why: Repeated image, name, and price placement reduces re-scanning; the grid gives the collection a clear reading rhythm.

Tradeoff: Filter context uses horizontal space on desktop and becomes a condensed row on narrow screens.

Objects / Home / Vessels

Soft edge
vessel

4.8 / 5   ·   26 notes
$72.00

A quiet, rounded form in a tactile finish. Made for everyday use; variations are part of the material.

FinishWarm clay
SizeMedium
SmallMediumLarge
Availability / In stockDelivery / Shown at checkout

Soft edge vessel product detail interface

1 / 1
01 / InspectImage is the first visual anchor.
02 / ChooseSelected finish and size are named.
03 / UnderstandPrice and availability stay in context.
04 / ContinueThe primary action reflects the current choice.
Illustrative UI · fictional data

04 / Product detail keeps choice and confidence together

Portfolio reconstructionNot production screenshots

Problem: A product page must help someone assess the item, make a configuration choice, and understand what follows.

Decision: Give the product image room, then group name, price, option state, supporting details, and the primary next step in one reading column.

Why: The selected option is explicit and adjacent to the action; availability and delivery context remain visible without competing with the product.

Tradeoff: On mobile, the detail hierarchy becomes a vertical sequence rather than preserving the desktop side-by-side composition.

01 / Your bag0 items
Your bag is empty.Choose a finish and add the fictional item above to preview the order flow.Choose a finish ↑
02 / Review orderSecure step
Waiting for a bag item.The selected finish and quantity carry forward from the bag.
03 / Confirmation exampleIllustrative state
Confirmation follows checkout.This is a representative state—not a placed order or conversion claim.
Alternative stock-change state: If an item becomes unavailable, pause checkout and return the customer to the bag with their other selections preserved.
Same product → Same options → Clear total + next step
Illustrative UI · fictional data

05 / Cart, checkout, and confirmation share one order model

Portfolio reconstructionNot production screenshots

Problem: Customers can lose confidence when the item, selected options, quantity, and total appear to change between steps.

Decision: Carry the same fictional item and option summary through cart, checkout, and confirmation; expose a recoverable stock-change message.

Why: The repeated order summary gives a quick continuity check, while the exception state explains what needs attention before continuing.

Tradeoff: Repeating key order details uses space, especially on a compact checkout view.

Product-option & availability states
Available / selected

Option name and current price stay explicit beside the add-to-bag step.

Low availability

Use a text cue, not color alone, before the customer commits.

Option unavailable

Explain the issue and preserve the other valid selections.

Price needs refresh

Pause order submission and show a clear updated total for review.

Design → development handoffRepresentative contract
Reusable pattern / product option
LabelSelected valueAvailabilityPrice context
ResponsiveDesktop: image + detail columns. Narrow screen: image first, then choices and primary action.
BehaviorSelection is visible; unavailable options are explained; changed totals are reviewed before submit.
QA checkKeyboard focus, selected state, long product names, missing option, and narrow viewport.
Product option → state + content + responsive rule

06 / Interface states become an implementation contract

Portfolio reconstructionNot production screenshots

Problem: Responsive commerce patterns need more than their default appearance: selection, availability, error, and narrow-layout behavior all affect the next step.

Decision: Describe reusable product-option, status, and primary-action behavior as explicit states, then carry those rules into design QA.

Why: A shared contract gives design and development a common reference for default, changed, and blocked states without implying a specific framework or platform implementation.

Tradeoff: Defining states adds specification work up front, but makes edge behavior discussable before build.

COMMON / OBJECTSBag 01
COLLECTION / 08 PIECESConsidered
forms
Filter · All objects Sort
Low form / vessel$48
Soft edge / vase$72
01 / BROWSE
‹ ObjectsBag 01
VESSELS / WARM CLAYSoft edge vessel$72.00Medium · selectedAdd to bag · $72.00
02 / PRODUCT
Your bag01 item
Soft edge vesselWarm clay · Medium$72.00
Subtotal$72.00
Continue to checkout03 / BAG
Portfolio reconstruction · fictional storefront content

07 / Mobile browse, product, and bag

Portfolio reconstructionNot production screenshots

Problem: At a narrow width, discovery and purchase details need their own deliberate order—not a desktop canvas squeezed down.

Decision: Compose three compact mobile views with thumb-friendly filters, an image-first detail page, and a bag summary that keeps the next step visible.

Why: Each screen is arranged for a single-column viewport, with product identity and price still legible.

Tradeoff: Supporting details move below the initial view.

COMMON / OBJECTSCOMPONENT STUDY · REPRESENTATIVE
PRODUCT CARD
Soft edge / vase$72 · 2 sizes
BUTTONSAdd to bagView details
INPUT + SELECTEmail addressMedium ⌄
PRICE + QUANTITY$72.00−   1   +
CART ITEM
Soft edge vesselWarm clay · Medium$72.00
NAVIGATIONCOMMON / OBJECTSObjects    Stories    Bag 01

08 / A small, reusable commerce component set

Portfolio reconstructionNot production screenshots

Problem: Product choices and order summaries repeat across browse, detail, and checkout.

Decision: Keep representative controls visually related while letting each component carry its own state and purpose.

Why: The board shows the reusable pieces as rendered UI: navigation, product card, price, option select, quantity, input, and actions.

DESIGN INTENTOne card · one scan
Soft edge / vase$72 · 2 sizes

Image leads; name and price share a stable baseline. A single metadata line carries the useful distinction.

COMPONENT CONTRACTProductCard
01 media / fixed ratio02 title / clamp to 1 line03 price / always visible04 metadata / optional05 link / full card target
ResponsiveDesktop: 3-up gridMobile: 2-up grid; preserve image ratio and readable labels

Intent → component structure → responsive rule → implementation concept.

09 / Product card: design intent becomes buildable detail

Portfolio reconstructionNot production screenshots

Problem: A card can look complete in a mockup while leaving its structure and narrow-screen behavior ambiguous.

Decision: Translate one product card into named content slots, interaction affordances, and a responsive rule.

Why: The handoff connects what a shopper scans to a component contract a developer can implement.

Tradeoff: The code-like view is a representative specification, not source code from a production storefront.

COMMON / OBJECTSObjects　 Stories　 Bag
Considered forms 08 pieces
FILTERS

Type
Material
Availability
Low form$48
Soft edge$72
Arc light$116
DESKTOP / 3-UP + FILTER RAIL
COMMON / OBJECTSBag
Considered forms
Filter　 Type　 Sort
Low form$48
Soft edge$72
TABLET / 2-UP + CONDENSED FILTERS
COMMON / OBJECTSBag
Considered forms
Filter · All objects
Soft edge$72
MOBILE / 2-UP · DETAILS RETAINED
Interface studies: portfolio reconstructions · fictional storefront content

10 / Commerce, composed across screen sizes

Portfolio reconstructionNot production screenshots

Problem: The same assortment must remain scannable as the available width changes.

Decision: Reduce columns and move filters into a compact control row; keep the image, product name, and price in every card.

Why: The comparison makes the responsive transformation inspectable rather than relying on a device label.

02 / Verified design + development work

Customer flows carried into a responsive build.

The supplied résumé documents customer journeys, marketing funnels, product flows, responsive layouts, custom modules, and front-end development within this role.

  1. 01

    Customer journeys

    Created customer journeys, marketing funnels, and product flows aligned to customer needs and business objectives.

  2. 02

    Product experience

    Designed responsive UI layouts and custom modules, carrying product decisions into the implemented experience.

  3. 03

    Front-end development

    Connected design and implementation using front-end development, HTML, and CSS.

  4. 04

    Platform development

    Developed WordPress themes and WooCommerce extensions as part of the documented role.

These describe the verified scope of the work. The product imagery and interface examples earlier on this page remain explicitly illustrative, not historical production screenshots.

03 / What it connects

Commercial thinking with hands-on delivery.

This project connects customer experience decisions to a real commercial platform. Designing and developing the work brought usability, business context, responsive behavior, and production constraints into the same conversation.

The $3M+ figure is the platform’s annual revenue, not a conversion lift or a result attributed to one interface change. No specific conversion improvement or funnel metric is claimed.

The experience reinforced a useful product-design habit: stay close to implementation, understand the consequence of design choices in production, and balance customer clarity with the needs of the business.

Discuss product design

Building a commercial platform or a complex workflow?

Email Brian View résumé All selected work