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
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.