Grocery Retail UX Strategy & Research Enterprise Tools

From paper to platform.

Whole Foods Market ran its company-wide employee policy on paper, with no digital source of truth. BrilliantUX designed the platform that replaced it, now serving more than 20,000 Team Members every week.

The Smart GIG policy platform shown on a desktop display

~$1M: Estimated annual legal risk reduced by replacing paper policy workflows.
20,000+: Team Members reaching current policy every week.
7: Features shipped across the authoring and viewing experiences.

Paper workflows, real legal exposure.

Whole Foods managed its company-wide employee policy, the General Information Guide, through mostly paper-based workflows, with no digital source of truth.

Over 20,000 Team Members searched corporate policy every week, yet it lived as a flat list of links with no way to sort, search, or confirm that the right version was ever seen. That exposed the company to significant legal risk.

The existing PDF-based General Information Guide

Our goal was to make Whole Foods employee policies easily accessible for busy Team Members, while enabling the legal team to track employee acknowledgement of these policies in a consolidated manner.

Built for the people writing the policy.

Analysis of authoring pain points emphasized four features centered on policy document authoring, management, and acknowledgement tracking.

Centralized Digital Policy Management

A consolidated, digital solution to streamline authoring, tracking, and distribution, allowing real-time collaboration across all touchpoints.

Acknowledgement Tracking System

Automated acknowledgement tracking, notifications, and compliance escalation to accurately request and log Team Member acknowledgements.

Regional Policy Publishing

The ability to specify region-specific policy elements without creating an entirely separate General Information Guide.

Document Version Control

Robust version control to clearly manage edits, track changes, and publish updates with confidence.

Built for all team member use cases.

Analysis of viewing pain points emphasized three features centered on policy access, viewing, and acknowledgement submissions.

Centralized and Current Policy Access

A centralized, digital repository so Team Members can easily search and view the latest policy versions.

Smart Acknowledgement System

Review and acknowledge the specific changes to a policy without re-acknowledging the entire document.

Enhanced Experience Across Devices

A user-friendly viewing interface optimized for both desktop and mobile.

From whiteboard to build-ready.

Workshops with the Whole Foods legal team and a sample of Team Members mapped the future state on a wall. Weekly reviews turned it into something a developer could build.

01Discover

Everyone who touched policy, in one room.

In-person whiteboarding workshops were run with the Whole Foods legal team and a sample of Team Members. The sessions established how corporate policy was actually written, approved and distributed, rather than how the paper process implied it worked. The output was a wall of open questions grouped by theme.

A whiteboard covered in future-state user flows, policy set sketches and open questions mapped during a workshop — The board at the end of a session. The open questions in orange are the ones the next pass had to answer.

02Define

The future state, settled before it was designed.

Proposed future-state user flows were developed for both the authoring and the viewing experiences. Policy sets, categories and the relationships between them were defined on the wall, which fixed the structure of the platform ahead of any screen.

Early sketches and low fidelity wireframes carried that structure into a design tool. Two audiences, one source of truth: the people writing policy and the 20,000 Team Members reading it.

Future-state user flow for the authoring experience, from creating a policy through drafting, preview and review to publication — **Authoring experience** The authoring flow was mapped from a blank policy to a published one. A policy is created inside its policy set, written in repeatable section blocks and checked in a preview beside the editor. Status, version, active date range and review date are set before it is submitted for review and published to Team Members.

Future-state user flow for the viewing experience, from opening the General Information Guide through finding, reading and acknowledging a policy — **Viewing experience** The viewing flow was mapped from the moment a Team Member opens the General Information Guide. A policy is reached through search or through its policy set, read in its current version, and acknowledged in the same place it is read, which is what gives the company a record of who has seen it.

03Develop

The same screen, drawn four times.

The work climbed one fidelity step at a time: marker sketches, then rough wireframes, then a clickable prototype, then a build-ready specification. Each pass answered a narrower question than the one before it, and deliberately refused to answer the next one early.

Four passes at the policy authoring screen stacked in sequence: a marker sketch, a low-fidelity wireframe, a mid-fidelity layout, and a fully specified interface — Four passes at the same authoring screen, stacked in the order of fidelity in which they were made.

Pass 01 · Rapid sketching

Marker on a board

Minutes per idea, drawn live in the room with the legal team. Sketching this fast is disposable on purpose: it settles what a policy set contains and which sections exist while everyone is still willing to rub it out and start again.

Pass 02 · Low fidelity

Boxes and labels

The first pass in a design tool, and still deliberately rough. Grey boxes and placeholder titles answer one question, how an author finds a policy and attaches it to a category, without inviting anyone to comment on type or colour before the flow is right.

Pass 03 · Interactive prototype

Structure you could click through

Navigation, policy parameters and the editor placed relative to each other, then wired together so reviewers could move through the flow rather than read a picture of it. The weekly sessions tested the arrangement against how authors actually work, which is where the layout stopped moving.

Pass 04 · High fidelity

A build-ready specification

Every field, state and control drawn at production fidelity: statuses, version pickers, active and review date ranges, repeatable section blocks. With the structure already settled, the only decisions left were what goes inside the fields.

03Develop

The screens changed after every session.

Weekly review sessions were conducted in person with end users, project managers and developers. Low fidelity wireframes were walked screen by screen, and what came out of each session was drawn before the next one.

Early feedback from policy authors set the shape of four screens: the policy library, the manage policies table, the create policy form and the dual-pane editor. Running the reviews with developers in the room kept every decision inside what the platform could support.

The Smart GIG home screen: policy sets, expandable policies and a search across all of them — **The policy library, as a Team Member sees it**Policies grouped into sets, each one expanding in place, with a search across every set above them. The paper guide's flat list of links became a structure a reader could scan.

The manage policies table: every policy row with its status, last edited, effective, published and review dates — **Manage policies, as an author sees it**Status, last edited, effective, published and review date on every row, with bulk actions above the table. Authors asked to see the state of the whole library in one view rather than opening policies to find it.

The create policy screen: policy metadata above repeatable text section blocks and an author notes block — **Creating a policy**Name, status, version, active date range and review date sit above repeatable text section blocks, with a separate block for author notes. One long free-text field was replaced by blocks an author can add and reorder.

The dual-pane editor: a live policy preview on the left and the policy editor with its fields and section blocks on the right — **The dual-pane editor**The preview sits beside the editor rather than behind a button, so an author reads what a Team Member will read while writing it. This pane came directly out of a review session.

04Deliver

Tested against the job, then handed to build.

High fidelity prototypes were tested with Team Members and the legal team before development began. Visual design ran through to launch on the internal platform, shipping seven features across the authoring and viewing experiences.

The specification went to development as a walked flow rather than as a set of screens, with every state and every transition between them drawn in place. Smart GIG now serves more than 20,000 Team Members every week.

The final Smart GIG user flow: a Team Member moves from the Innerview home screen into the General Information Guide, opens a policy set, reads a policy, and acknowledges the current version, with every screen state and the transitions between them drawn in sequence — The shipped flow, walked end to end: finding a policy set, reading the current version of a policy, and acknowledging it.

A single source of truth.

One platform to author individual policy documents and nest them within larger policy sets, with control over content, regional targeting, versioning, and navigation.

A live preview editor shows real-time updates alongside the editing interface, cutting errors as authors write. A centralized repository keeps everyone on the latest approved version.

The General Information Guide on a phone, the binder every Team Member was meant to have read, in the device they already carry.
Acknowledgement sits inside the reading flow, so the record of who has seen a policy is made in the same place the policy is read.
The policy set editor. A live preview runs beside the draft, so an author sees the published page as they write it rather than after they publish it.
The design system the platform is built from. Components were drawn once with their states defined, so a new screen is assembled from existing parts rather than designed from scratch.
Regional targeting. A policy set is scoped so a Team Member sees what applies where they actually work, and nothing else.
In the store, on the tablet already on the floor, policy read where the work happens rather than in a back office.

The impact, by the numbers.

Digitizing employee policy management replaced paper workflows with a single source of truth, cutting legal exposure and reaching every Team Member.

~$1M

Estimated annual legal risk reduced by digitizing paper-based policy workflows.

20,000+

Team Members served, accessing policies each week.

1

Digital source of truth, replacing manual paper workflows.

7

Features shipped across the authoring and viewing experiences.