AI-Native eCommerce ERP: 5 Live Features, 250 Production Components

Context & My Role

HikeOn Technologies was building a custom eCommerce ERP — an all-in-one operational platform for mid-market retail businesses. Inventory management, order processing, pricing, customer data, logistics, and reporting in a single product.

I joined as the first and only designer on the product. There was no design system, no prior user research, and no validated information architecture. My mandate was to take it from a requirements backlog and rough wireframes to a shippable, coherent, user-tested product — while building the design infrastructure from scratch alongside delivery.

Team: Product Owner, Engineering Lead, 2 Vue.js Engineers, 3 Retail Domain SMEs.

Discovery & Research

User interviews — 5 participants over 2 weeks

I ran structured 60-minute interviews with retail operations managers and inventory controllers. What I heard, consistently: The highest-friction moment in every participant's day was not within any one tool — it was between tools. Context-switching between an inventory spreadsheet, an order management system, a CRM, and a pricing tool consumed 2–3 hours daily.

• — "6 critical handoff points where data was being manually duplicated between functions."
• — "3 recurring decision moments where users had no real-time signal to act on."
• — "2 complete workflow loops that existed only because connected tools didn't share data."

The Design Problem

How do you design a single coherent product experience across 8 functionally distinct business domains — and make AI feel like a natural part of the daily workflow, not a separate reporting layer?

AI Features in the Product

I facilitated a 3-hour working session with the product owner and engineering lead to map AI opportunities against the workflow audit. I used a 2×2 framework: User Impact vs. Implementation Feasibility. We generated 14 candidate ideas and scored each one. What shipped breaks down as 5 AI features (3 in active development) — the five live features below, plus three more fully designed and in the build pipeline.

The 5 features that shipped and are live with real users:

• — Smart Inventory Reorder Alerts — predicts stockout risk from sales velocity and supplier lead time, surfaces inline on the inventory row
• — Dynamic Pricing Suggestions — margin-aware recommendations with a confidence indicator and data source, shown on the product edit screen
• — Demand Forecasting Dashboard — weekly and monthly demand curves per product category, replacing the manual export-and-pivot workflow
• — Customer Churn Risk Scoring — surfaces at-risk accounts in the CRM view with the contributing signals
• — AI Catalogue Search — natural language search across the product catalogue

3 features fully designed, currently in active development:

• — AI Product Description Generator — first-draft product copy from SKU attributes
• — Order Anomaly Detection — flags unusual order patterns before fulfilment
• — Automated Return Categorisation — classifies return reasons to reduce manual triage

Core design principle

AI should not live in a dedicated dashboard. It should surface at the exact moment a user faces a relevant decision — inline, contextual, immediately actionable.

Design Strategy

Information Architecture Decision

The original requirements backlog reflected the organisation's internal structure — 8 separate functional areas, each specced in isolation. I proposed restructuring into 4 unified domains based on user job-to-be-done:

Catalogue	Products, SKUs, AI descriptions, Pricing
Operations	Inventory, Procurement, Warehousing, Demand Forecasting
Orders	Sales orders, Fulfilment, Returns, AI anomaly alerts
Customers	CRM, Churn scoring, Communication history

I validated this by comparing user task paths in the old vs. new architecture for the 5 most common daily tasks. Old: average 4.2 navigation steps. New: average 1.8. Presented with prototype walkthrough to stakeholders. Approved after two alignment sessions.

How I Worked With the Team

With the Product Owner

Weekly 90-minute design reviews framed as hypothesis tests. I presented the decision, the rationale, the alternatives I rejected, and the outstanding uncertainty. By month two, the product owner was proactively flagging scope and feasibility issues in the session rather than after handoff.

With Engineering

Embedded in engineering standups 3× per week. Engineering adopted the design system from Sprint 1. Component annotation sessions — 30 minutes weekly, walking developers through every new component — eliminated the 'what does this state do?' category of design QA questions entirely.

Results

What I Learned

On AI product design

Users don't resist AI because it's unfamiliar. They resist it because they don't know how much to trust it in a given moment. Designing the trust layer — confidence indicators, data source transparency, one-click dismiss — wasn't a UX nicety. It was the product's adoption mechanism.

On being the only designer

Design authority is earned through evidence, not title. Every time I pushed back — on the IA structure, on a proposed Quick Actions button, on an AI hub proposal — I did it with data from users or a testable prototype. Not once with 'trust me, I'm the designer.' That approach built credibility that made the second and third push-backs easier, not harder.

On design systems

I treated the component library as a shared product, not a designer's output. I ran component reviews in sprint meetings. I asked developers to challenge my naming decisions. The result was a system the engineering team felt ownership over — and used consistently as a result.