← Highlights

Enterprise Retail Operations · AI · Systems Design

SEDERAN: Turning retail standards into verifiable store-floor execution

A multi-location retail operations platform connecting central standards, daily work, evidence capture, and AI-assisted verification in one operational loop.

Role
Lead Product Designer
Platform
Responsive web application
Scope
Product strategy · Systems architecture · UX/UI · AI workflows · Design system
Status
Live Product

Live Product

01 · SEDERAN in One View

Retail standards are created centrally. Execution happens across stores, departments, shifts, and people working under different conditions. SEDERAN connects those two worlds: Define → Distribute → Execute → Capture → Verify → Improve Head office defines the standard. Relevant teams receive the work. Store employees execute it and submit evidence. AI assists with evaluation, while managers remain responsible for review and follow-up. The goal was not another task manager. It was to preserve the connection between what the business expects and what actually happens on the store floor.

02 · Business Context

Head-office teams can define how stores should operate, but visibility often disappears once those expectations reach the store floor. Instructions become scattered across documents, messages, checklists, and disconnected tools. Different departments interpret them differently. Work gets completed, but proving that it was done correctly creates another layer of coordination. The design opportunity was to turn that fragmented process into a traceable operational system.

03 · Product Model

I designed SEDERAN around the structure of the business rather than around individual features. Locations and departments provide context. Standards define expected execution. Operational work turns those expectations into action. Evidence makes execution observable. Review determines what happens next. People, permissions, AI, and reporting operate across these layers rather than becoming disconnected product areas. This became the structural foundation of SEDERAN.

04 · The Design Challenge

The central design question became: How might one system connect what should happen, who owns it, what actually happened, and what needs to happen next? These requirements shaped the architecture before they shaped individual screens.

Represent the organisation

Represent businesses, locations, and departments without creating separate products for each.

Preserve the source

Keep standards as a persistent source of truth.

Turn intent into action

Translate standards into actionable operational work.

Adapt by responsibility

Adapt information to different roles and responsibilities.

Capture evidence in context

Keep evidence connected to the work being performed.

Keep humans accountable

Use AI to assist verification without removing human accountability.

05 · Information Architecture

As SEDERAN expanded, manager, visual merchandising, stock, cash desk, and assistant-manager workflows began behaving like independent destinations. The navigation was starting to mirror the organization chart rather than the underlying product model. I separated organizational context from operational activity. Departments remain distinct, but they no longer require independent product architectures. This created one operating model capable of adapting to different responsibilities without fragmenting into separate tools.

Operations

Work that needs to be performed and reviewed.

Organization

Locations and departments.

Standards

The source material defining expected execution.

Team & Access

People, permissions, and responsibility.

System

Configuration and product-level settings.

06 · From Standards to Daily Work

One critical product decision was separating persistent standards from temporary operational work. A standard describes an expected state. A task describes something someone needs to do now. Treating them as the same object would duplicate instructions and make standards difficult to maintain across locations. Instead, operational work references a reusable standard: Standard → Assigned work → Execution → Evidence The source of truth can evolve while the work remains connected to why it exists and what successful execution looks like.

07 · AI-Assisted Evidence Review

Collecting evidence is relatively easy. Reviewing it consistently across many locations is not. SEDERAN uses AI to compare submitted evidence with the standard that applies to the work. The model is given bounded context for a specific review task rather than being asked to make a general judgment about a store. Its output supports human judgment rather than replacing it.

AI proposes. People remain accountable.

Standard

Provides the evaluation context.

Evidence

An employee submits the required photo or documentation.

AI analysis

The system surfaces relevant observations, potential mismatches, and uncertainty.

Human review

A responsible reviewer makes the decision.

Action

Approve, request correction, or follow up.

08 · End-to-End Workflow

What begins as a central expectation becomes observable store-floor execution.

Define

Head office creates or updates a standard.

Distribute

It reaches the relevant locations, departments, and responsibilities.

Execute

Store teams receive actionable work.

Capture

Evidence becomes part of completing that work.

Verify

AI assists comparison against the applicable standard.

Review

A responsible person makes the final decision.

Improve

Corrections and recurring issues feed back into operations.

09 · Designing Across Roles

A store manager, visual merchandiser, stock employee, and cash-desk team member do not need the same interface. They also do not need different products. Managers need oversight. Visual merchandisers need standards and evidence. Stock teams need actionable work. Store-floor employees need clarity about what requires attention now. SEDERAN changes what is relevant according to responsibility without changing the fundamental logic of the system. That keeps permissions, standards, evidence, and reporting consistent across the organization.

10 · Designing for Operational Density

SEDERAN needed to support information-heavy management workflows without making everyday operational work feel like traditional enterprise software. The goal was not visual uniformity for its own sake. It was to make a complex operational system feel predictable.

Hierarchy

Make business, location, department, standard, work, and evidence contexts immediately distinguishable.

Status

Communicate operational state through labels, icons, language, and hierarchy rather than colour alone.

Density

Give management views enough information for comparison and oversight while reducing store-floor views to what requires action.

Responsiveness

Support broad oversight on desktop while preserving navigation, context, evidence capture, and immediate actions on smaller screens.

11 · Iteration & Trade-offs

Early versions allowed department-specific areas to grow independently. VM, ASM, stock, cash desk, and manager workflows increasingly appeared as parallel product areas. It worked at small scale, but the architecture was beginning to mirror job titles rather than stable product concepts. I reorganized it around operations, organization, standards, team and access, and system configuration, with departments and roles becoming contextual dimensions inside that structure. This reduced duplication, clarified hierarchy, and gave new capabilities somewhere predictable to belong.

Organizational complexity should not automatically become interface complexity.

12 · Outcome & Reflection

SEDERAN became more than a way to manage store tasks. It created a traceable system connecting business expectations with store-floor execution. Standards → expected execution Operations → responsibility Evidence → observable work AI → bounded evaluation Review → human accountability The project required treating organizational structure, permissions, standards, workflows, evidence, and AI as parts of the same operating system rather than independent features.

Design the system first. Then design the screens that make it usable.