03UX & product designDetailed case study

Making a planning hierarchy feel like one decision

I designed Cortex planning flows that reconcile management goals with store-level plans and trading periods, then connect buying decisions to the later review of what performs in stores.

Retail planning · Sales planning, store lifecycle management and article-level range review
CompanyFynd · Cortex
TimelineDec 2025-Feb 2026
RoleProduct Design
FocusSales Planning · Store Management · Range Review

The starting point

Keep the detail behind the target.

A management goal is only credible when store-level sales, growth and margin plans support it. Openings, closures and months without trading change that contribution. Planners need to reconcile both directions before approval, because the AOP sets the basis for the brand budgets and buying decisions downstream.

The difficulty
Planners had to reconcile leadership targets, store evidence and changing store availability without losing the hierarchy.
What I changed
A target tree and store-level comparison keep last year, the target and editable consensus together.

What informed the design: Planning sheets, hierarchy rules and walkthroughs with PMs and domain experts informed the two views. The tree preserves parent context; the table supports comparison across stores.

Connected systems

From an annual goal to what reaches a store.

Cortex sits inside the wider Impetus journey. A planning decision becomes a budget, a design brief, a costed buy and eventually a store-level assortment.

  1. Plan

    Top-down goals + bottom-up store plans, adjusted for trading periods → approved AOP.

  2. Budget & design

    Brand OTB → Range Architecture → fashion design → Stylezone review.

  3. Buy & allocate

    Buy Plan ↔ vendor costing → final buy → distribution and assortment → Procuro POs.

  4. Review in store

    Manufacturing and store receipt → sales and inventory signals → Range Review.

My cross-functional contribution: I collaborated with stakeholders and functional leads to create the Impetus System Architecture Diagram, contributing to decisions about these connections over several iterations. The sequence here is a simplified view of those handoffs; the screens below focus on my Cortex design work.

AOP creation flow

Two directions.
One agreed sales plan.

Management sets the ambition. Store-level sales, growth and margin plans are reconciled against it to form the Annual Operating Plan (AOP).

THE MODIFIER: WHEN STORES CAN TRADE

An opening, permanent closure or temporary shutdown changes the periods a store contributes to the plan—not just its status in a list.

AOP 01 / Top-down sales planning

Edit the plan where its structure is visible.

Management sets the sales, growth and margin goals. Cascading them through the hierarchy keeps inherited targets, editable branches and locked categories visible together.

01 / 02

Review the plan before entering edit mode.

Trace revenue and margin through the hierarchy in a read-only summary. Edit Plan separates reviewing the plan from changing its targets.

AOP 02 / Bottom-up sales planning

Work from the store up, without flattening the detail.

Define sales, growth and margin for each store, then aggregate store plans and reconcile them with the management goal. Last year, target and consensus stay together while planners resolve the differences.

01 / 03

Keep the comparison in one place.

Compare last year, target year and consensus alongside store identity, seasonality and fashion grade.

The trade-off: one flat table would be consistent, but would hide the parent–child relationships. I used a tree for cascading targets and a table for comparing stores, with explicit review and editing states in both.

AOP modifier / Store trading periods

A store cannot contribute for months it is closed.

Openings, permanent closures and temporary shutdowns change when a store contributes to sales and growth, and how its margin plan feeds the aggregate. Manage Stores puts those dates into the planning context before the AOP is finalised.

01 / 04

Make the planning estate inspectable.

Status, dates and filters distinguish new, active and closed stores. Shown from Top-down; shared with Bottom-up.

The approval checkpoint: top-down goals, aggregated store plans and trading-period changes are reconciled into one AOP. Only once that plan is approved does it become the basis for brand-level OTB budgets.

02 / After AOP approval

Turn the agreed plan into a buying brief.

  1. Give each brand a monthly budget

    The separate Open-to-Buy (OTB) module breaks the approved sales plan into monthly brand budgets. This gives the buyer a spending envelope.

  2. Suggest the range, keep buyer control

    Using that budget and trends, the system suggests a Range Architecture (RA): category × subcategory × quantity × fabric. The buyer can adjust it before sending the brief to fashion designers.

  3. Review designs before buying

    Designers develop styles and colour options against the RA. The buyer approves or rejects designs in Stylezone; approved designs flow into Buy Plan, initially without final vendor costs.

03 / Buy Plan & vendor costing

See the whole buy,
then commit.

Approved designs arrive with product specifications, categories, quantities and fabrics—but not final costs. Styles become RFQs for vendor costing; agreed costs return to Buy Plan.

The buyer can then compare system and buyer quantities and costs across the brand’s RFQs, remove an option, change quantities, drop a style or defer it to the next month before finalising the buy.

Design rationale: keep the brand-level buying decision in view. Closing one RFQ does not mean the whole Buy Plan is ready to purchase.

Buy Plan listing with system and buyer quantities, costing status and delivery dates beneath quantity, selling price, sales, OTB and buy cost summaries.

04 / After Buy Plan is finalised

Decide what each store receives.

Distribution and assortment plans split the final buy across stores, down to category × subcategory × style × option × size. These allocations feed Procuro’s PO engine; purchase orders then lead into manufacturing and delivery to stores.

Illustrative breakdown: at one store, a menswear → topwear → T-shirt style could allocate 100 units to blue / S and 25 to black / M. The decision is not just how many T-shirts to buy—it is which variants belong in which stores.

Vendor quote comparison and cost approvals are covered in the Costing Engine case study.

05 / Once goods are in store

Let actual performance refine the range.

Range Review is the post-arrival decision, not another step in creating the AOP. I connected each article recommendation to its affected stores and reason so reviewers could inspect the scope before approving.

Range Review / Article listing & delisting

From an article recommendation to a reviewable request.

Once goods reach stores, sales, demand, aged inventory and other performance signals inform which articles need listing or delisting, and where. Select articles, inspect their affected-store lists and review the reasons before committing a change.

01 / 05

Keep the recommendation next to the affected articles.

Select articles beside recommendations and affected-store counts, then start delisting without losing the evidence.

Critical screen · article request detail

The decision is an article, a reason and a set of stores.

Once goods are in stores, Range Review responds to sales, demand, aged inventory and other performance signals. Bring article, reason and affected stores together before approving a listing or delisting decision.

Cortex · Range Review design
Pending article delisting request with business scope, article selection, reason, affected-store preview, Edit Selection, Approve and Reject actions.

Primary user momentA reviewer checks the selected article, delisting reason and affected stores before editing, approving or rejecting the request.

Research, contribution and constraints

The work primarily served Reliance Retail’s Fashion & Lifestyle and Grocery teams, moving from spreadsheet-and-email workflows towards a shared platform.

Research & evidence

What informed the work.

01

Artefact analysis

Studied planning sheets, KPIs and hierarchy rules to understand how decisions were represented.

Decision inventory
02

Domain interviews

Walkthroughs with PMs and planning experts exposed terms, handoffs and failure points.

Shared vocabulary map
03

Prototype reviews

Recurring business reviews tested comprehension and missing context in high-fidelity flows.

Revised IA and states
04

Cross-flow modelling

Connected AOP, brand budgets, design review, buying, costing and store allocation through the Impetus System Architecture Diagram, collaborating with stakeholders and functional leads. Range Review sits after goods reach stores.

Cross-functional handoff map

I owned Product Design for AOP creation, store management and Range Review. Research was business-led, using domain walkthroughs and design reviews rather than an extensive standalone generative study.

Impact

Reach consensus with less rework.

shorter planning-to-approval cycle
~50%
About a month → around two weeks
Top-down goals and bottom-up store plans meet in a shared consensus, with store openings, closures and downtime reflected in the numbers.
fewer revision rounds
67%
6 → 2 rounds before approval
Planners compare management targets with store-level evidence and adjust the consensus in place. Buyers get an earlier view of the approved budget.

Strategy and store reality can be reconciled

Top-down goals and aggregated store plans can be compared and reconciled before the AOP is approved.

Store changes have explicit boundaries

Opening, closing and reopening dates make the periods of store contribution explicit when reviewing the plan.

Article decisions remain inspectable

Selection, store scope and reasons travel with the request into review.

What I would validate next

Next validation step

Correctly scoped planning decisions

Representative task
Revise a store-level plan or review a delisting request without losing its hierarchy, reason or affected stores.
What to measure
Check correct scope on the first attempt, approval rework and trips outside the workflow to reconstruct context.

Separate AOP tasks from Range Review. They happen at different stages and need separate baselines.

Next case studyDesigning a network you can read