01
Multi-store
Business visibility across stores and teams.
SCash: Designing the operating system behind everyday commerce
SCash
Designing the operating system behind everyday commerce.
0-to-1 SaaS / Singapore / 2021
01
Project overview
A commercial platform built from zero to one.
I joined an eight-person cross-functional team as the sole Product Designer. Over four months, I owned the experience from product structure and user flows through high-fidelity UI, prototyping, and developer handoff.
- Product
- SCash Merchant Operations Platform
- Users
- Singapore SME owners and store managers
- Timeline
- April 7, 2021 / 4 months
- Role
- Sole Product Designer
- Team
- 8 people across product, engineering, QA, and business
- Platform
- Mobile SaaS
- Tools
- Sketch, Figma, Photoshop, and Illustrator
- Responsibilities
- IA, flows, interaction, UI, system, and handoff
This case study documents the version I designed at Shenzhen TD Cloud Co., Ltd. SCash subsequently launched and continued to evolve after I left the company; later product changes are not presented as my work.
02
Business context
One online business.
Too many disconnected workflows.
Small and medium-sized merchants often managed payments, orders, products, customers, employees, and financial reconciliation through separate tools or manual processes. SCash was created to connect those activities in one mobile operating platform.
- Orders
- Payments
- Inventory
03
The challenge
Make an enterprise-scale system usable from a phone.
Design a scalable platform that supported multiple merchant roles and interconnected workflows without making everyday work feel like system administration.
02
Orders
Online and offline workflows with clear next actions.
03
Products
Catalog, categories, variants, and stock availability.
04
Customers
Profiles, membership, points, and coupons.
05
Payments
Multiple channels, transactions, refunds, and receipts.
06
Finance
Wallet, cards, settlement, and reconciliation.
Product and inventory decisions move with every online order.
SCash had to keep catalog, stock, order, customer, and financial states synchronized as the storefront changed in real time.
THE ONLINE OPERATING ENVIRONMENT04
Research and definition
Turning a broad business vision into merchant workflows.
The product began as an interconnected set of business capabilities rather than a defined user experience. Discovery focused on identifying actors, business objects, system states, and operational dependencies.
Research inputs
- Stakeholder discussions01
- Business requirement workshops02
- Workflow and state mapping03
- Competitive analysis04
- Engineering feasibility reviews05
- QA workflow reviews06
The original research artifacts were not retained. This case study distinguishes stakeholder and QA validation from formal external usability testing.
05
Key insights
Operational pain appears in moments, not abstract feature lists.
01
Cross-store visibility
Owners needed business-level information while store managers needed a focused view of daily work.
Design implication
Adapt dashboards and controls to each role.
02
Time-sensitive orders
Managers needed to distinguish orders waiting for processing, payment, delivery, or collection without opening each record.
Design implication
Expose status and the next action at list level.
03
Settlement confidence
A successful payment did not automatically tell a merchant whether the money had been recorded and settled.
Design implication
Connect payment, transaction, wallet, and settlement states.
04
Product availability
Stock changes affected both in-store sales and online orders.
Design implication
Make availability visible in product lists and exception states.
06
User persona / journey
Design around responsibility, not demographics.
The retained files did not include formal persona research. These role profiles reconstruct the product model used to separate business oversight from store execution.
Reconstructed from business requirements and production screens; it is not presented as a surviving research artifact.
ROLE 01
Company Creator
- Context
- Runs one or more stores and needs a business-level view.
- Goals
- Monitor sales, configure services, manage stores and staff, and reconcile funds.
- Friction
- Important information was fragmented across operational and financial tools.
ROLE 02
Store Manager
- Context
- Owns day-to-day execution for a specific store.
- Goals
- Process orders, manage products, support customers, and resolve exceptions quickly.
- Friction
- Business-wide settings and irrelevant controls slowed down daily tasks.
ROLE-BASED JOURNEY
From joining the platform to growing the business.
01
Join
Merchant task
Create an account and verify identity
Tension
Too many forms before value is visible
Design opportunity
Show progress and explain why information is required
02
Set up
Merchant task
Create a store and activate payment services
Tension
Business, store, and compliance data depend on one another
Design opportunity
Sequence dependencies and support recovery
03
Operate
Merchant task
Manage orders, products, stock, and staff
Tension
Urgent work competes with administrative tasks
Design opportunity
Prioritize the next action by role and status
04
Reconcile
Merchant task
Trace transactions, wallet movement, and settlement
Tension
Payment success does not equal settlement confidence
Design opportunity
Connect the complete financial lifecycle
05
Grow
Merchant task
Understand customers and run loyalty programs
Tension
Customer tools can become disconnected add-ons
Design opportunity
Use one customer model across points and coupons
07
Design goals
Five criteria guided every design decision.
- 01Reduce
operational complexity
- 02Support
role-based workflows
- 03Increase
transaction efficiency
- 04Clarify
financial traceability
- 05Scale
navigation and UI patterns
08
Ideation and prioritization
Sequence the operating system before designing its screens.
Before designing individual screens, I defined what merchants needed to run their business successfully and organized capabilities into a scalable system.
Product system layers
Launch critical
Essential to start and transact
Account & Store Setup
Orders & Checkout
Payments & Transactions
Settlement & Wallet
Operational scale
Run and manage at scale
Products & Inventory
Multi-store & Staff
Customer Management
Analytics & Reports
Growth layer
Engage and expand
Membership & Points
Coupons & Promotions
Online Store Sharing
Notifications & Alerts
Platform architecture
SCash Platform
Commerce
- Checkout
- Orders
- Returns
- Wallet
Inventory
- Products
- Stock
- SKU
- Suppliers
Payments
- Transactions
- Payouts
- Settlement
- Reconciliation
Customers
- Customers
- Profiles
- Segmentation
- Support
Marketing
- Membership
- Coupons
- Campaigns
- Notifications
Analytics
- Dashboards
- Reports
- Insights
- Exports
Design decision
One universal dashboard
- Advantage
- Lower design and implementation complexity.
- Risk
- Owners and managers would see irrelevant information and controls.
Role-aware dashboards
- Advantage
- Priorities and permissions align with responsibility.
- Trade-off
- More states to design, implement, and maintain.
Selected
09
Information architecture
Organized around merchant work, not internal feature teams.
Daily actions remained accessible from the dashboard and primary navigation. Detailed management tools lived deeper in the structure, while role-aware entry points supported owners and store managers inside one product.
ROLE-AWARE DASHBOARD
ORDERSPAYMENTSPRODUCTS
CUSTOMERSANALYTICSSTORES
STAFFWALLETSETTINGS
Company Creator
Cross-store performance, products, finance, staff, and configuration.
Store Manager
Store-level orders, products, customers, and daily performance.
10
User flows
SCASH MERCHANT OPERATIONS
Two journeys connect setup, daily commerce, and money movement.
Rather than presenting the product as a list of screens, the flow shows how merchants enter the platform, activate their business, process an order, and trace the funds through settlement.
END-TO-END WORKFLOW
Merchant activation → Order to settlement
Merchant activation
Account to payment-ready store
- 01Create account
- 02Verify mobile
- 03Add business details
- 04Create first store
- 05Apply for NIUM
- More information
- Rejected
- Approved
- 06Activate services
Order to settlement
Customer action to reconciliation
- 01Receive order
- 02Process items
- 03Collect payment
- Cash
- QR payment
- Card
- 04Record transaction
- 05Review settlement
- 06Reconcile funds
DESIGN OUTCOME
The same status language and navigation patterns carry merchants from activation through financial reconciliation.
11
Design decisions
The system was shaped by four connected decisions.
01
Role-aware dashboards
- Problem
- One universal home could not serve business owners and store managers equally well.
- Options
- Universal dashboard; fully customizable dashboard; role-aware variants
- Trade-off
- More design and implementation states in exchange for less irrelevant information and safer access.
- Decision
- Use a shared visual structure with different content and controls for Company Creators and Store Managers.
- Impact
- Business oversight and store execution could live in one product without becoming generic.
02
A limited bottom navigation
- Problem
- SCash contained more major modules than a mobile navigation bar could support.
- Options
- All modules in navigation; one menu; stable navigation with contextual entry points
- Trade-off
- Some management features require an extra step, but the primary structure remains predictable and extensible.
- Decision
- Keep frequent destinations persistent and use role-aware dashboard shortcuts for the broader scope.
- Impact
- New capabilities could be added without repeatedly restructuring the app.
03
One financial lifecycle
- Problem
- Checkout alone did not explain whether a payment had been recorded, transferred, or settled.
- Options
- Independent histories; generic transaction list; connected financial views
- Trade-off
- A connected model required more status definitions but created stronger traceability.
- Decision
- Link payment methods, transactions, wallet activity, and settlement through consistent status and detail patterns.
- Impact
- Merchants could move from sale to reconciliation with clearer context.
04
Edge states as product states
- Problem
- Pending orders, failed applications, refunds, and empty records were normal operating conditions.
- Options
- Generic errors; module-specific messages; reusable state and recovery patterns
- Trade-off
- More initial design scope reduced ambiguity in high-risk moments.
- Decision
- Define explicit pending, successful, rejected, failed, empty, warning, and recovery states.
- Impact
- Users could understand what happened and what to do next.
12
Usability testing and validation
Validate the workflow before polishing the screen.
Task walkthroughs and prototype reviews focused on whether core workflows were understandable, feasible, and complete. Validation involved product, business, engineering, and QA.
Formal external usability-test records were not retained, so no participant count, task-success rate, or quote is invented here.
01
Create the first store
Success questionCan a new merchant complete business and store setup without assistance?
What we reviewedRequired fields, terminology, form length, and recovery.
02
Add a product
Success questionCan a manager set up a product, category, variation, and stock availability?
What we reviewedCategory selection, SKU understanding, stock states, and confirmation.
03
Process and reconcile
Success questionCan a manager complete an order and later find its financial record?
What we reviewedStatus recognition, payment selection, transaction history, and settlement.
CROSS-FUNCTIONAL VALIDATION
Every workflow was reviewed as a business, technical, and QA contract.
As the sole designer, I connected requirement decisions to interaction detail and release readiness.13
Iterations
Design the transition, not only the ideal screen.
The production file captures how the experience responds as services activate, information is requested, and operational records become available.
01 · ACTIVATION
Make unavailable services explainable.
Merchants see what is inactive, why it matters, and what completion unlocks.
02 · RECOVERY
Turn compliance uncertainty into a next step.
Requested information, review, success, rejection, and error states receive distinct guidance.
03 · PRODUCT SETUP
Connect classification to sellable inventory.
Category selection feeds product setup, variations, price, and stock status.
14
Final UI
Five outcomes. One connected merchant experience.
SET UP
From registration to a payment-ready store.
Progressive setup connects account creation, store details, financial services, and recovery states.
OPERATE
Role-aware tools keep daily work focused.
Owners and managers can move between orders, products, availability, and store operations without confronting the entire system at once.
THE MOMENT OF ONLINE PURCHASE
Simple for the shopper. Traceable for the merchant.
The experience connects online checkout, order status, payment history, wallet activity, and settlement.GROW
Customer activity becomes part of operations.
Profiles, membership, points, and coupons share a connected model instead of living in separate marketing tools.
SETTLE
Money stays traceable after checkout.
Analytics, transactions, wallet, cards, and settlement connect sales activity to financial reconciliation.
OPERATIONAL RELIABILITY
Edge states were part of the primary experience.
Pending, rejected, empty, failed, and recovery states explain what happened and what the merchant can do next.
15
Design system and components
A system designed around roles, states, and reusable decisions.
SCash needed more than visual consistency. I organized foundations, interaction primitives, components, and workflow patterns so merchants could transfer what they learned between commerce, customer, and finance modules while engineering and QA worked from shared rules.
- 01Audit
Inventory retained production UI and identify repeated decisions
- 02Define
Set foundations, component anatomy, variants, and states
- 03Compose
Combine components into views and operational patterns
- 04Document
Capture rationale, usage guidance, and implementation rules
- 05Evolve
Review with product, engineering, and QA as the product grows
Basic elements
Colour, typography, sizing, spacing, and iconography
Components
Forms, buttons, tabs, status, navigation, and list rows
Views
Dashboard, setup, overview, and detail compositions
Patterns
Creation, filtering, recovery, and financial tracing
Foundations translated brand into implementation rules.
Representative documentation reconstructed from retained production screens.
Semantic colour
Brand / Action#D1202A
Primary Ink#151719
Surface#FFFFFF
Subtle Surface#F2F3F5
Type hierarchy
Page titleMerchant operations
Section titleSettlement details
Body / Data
S$3,535.62 · Completed
LabelTRANSACTION AMOUNT
Spacing and shape
- 4–8
- Inline relationships
- 12–16
- Component padding
- 24–32
- Section grouping
FieldCardStatus
Components document anatomy, variants, and behaviour.
The same interaction grammar supports different objects without forcing every module into an identical screen.
COMPOSITE COMPONENT
Financial record row
Settlement / AlipayS$3,535.62Completed
123- 1Identity
Object and payment channel
- 2Primary data
Tabular amount aligned for scanning
- 3State
Text label plus semantic colour
ACTION
Button anatomy and hierarchy
FEEDBACK
Semantic status
PendingCompletedRejected
INPUT
Required label · persistent value · clear boundaryForm anatomy
NAVIGATION
Stateful tabs
ActiveScheduledInactiveOut of Stock
One component model, reused across operational contexts.
Reuse was defined by shared behaviour and anatomy, not visual similarity alone.
ComponentApplied inVariantsState rule
Action buttonStore setup, checkout, service activationPrimary / SecondaryDefault / Pressed / Disabled
Status tagOrders, products, applications, settlementPending / Completed / RejectedText and semantic colour
Form fieldOnboarding, store, product, complianceRequired / Optional / Read-onlyDefault / Focus / Error
List rowOrders, customers, transactions, settlementEntity / Summary / FinancialStatus visible before drill-down
Original product assets
Iconography remained recognizable while components carried interaction logic.
Documentation turns a component library into a shared language.
Each reusable decision was prepared for discussion with product, engineering, and QA. The system records what a component is for, how it changes, and how teams know it is implemented correctly.
- Rationale
- Why the pattern exists and which user problem it solves
- Usage
- When to use it, when not to use it, and content guidance
- Specification
- Anatomy, spacing, variants, states, and accessibility behaviour
- Delivery
- Engineering review, QA acceptance criteria, and ongoing updates
16
Collaboration
One designer. Continuous cross-functional decisions.
I owned the end-to-end experience while product, engineering, QA, project leadership, and the client-facing lead contributed business, technical, and delivery perspectives.
- Business requirements
- Product definition
- User flows and IA
- Engineering review
- Design and prototype
- Handoff and QA
- Release
17
Results and impact
0-to-1Commercial product
Production launch
DELIVERED OUTCOME
From a broad business vision to a production-ready merchant platform.
SCash connected commerce, customer operations, payment services, and financial records into one role-aware mobile system.
- Separate owner and store-manager experiences
- End-to-end workflows from activation through settlement
- Multiple payment-channel and financial-service states
- Shared UI patterns and developer handoff
DELIVERY IN NUMBERS
Evidence of scope, ownership, and execution.
Only figures that can be supported by the retained source file and project record are shown.
Documented screens and product states remaining after source-file cleanup.
From product definition through design, handoff, QA, and launch preparation.
Sole ownership of user flows, IA, interaction design, UI, and developer handoff.
Cross-functional collaboration across product, engineering, QA, leadership, and client coordination.
No unverified adoption, revenue, task-time, or satisfaction metrics are included.
18
Challenges
Complexity was not one problem. It was a set of connected constraints.
The design had to stay understandable while roles, store scope, payment services, product states, and financial records changed around it.
01
Feature breadth
Balance everyday speed with a platform covering commerce, finance, customer, and administration.
02
Role safety
Expose the right level of information and control to Company Creators and Store Managers.
03
Financial states
Represent activation, payment, refund, transaction, wallet, and settlement without ambiguity.
04
Delivery pace
Build a coherent system in four months as the sole designer within an eight-person team.
20
Reflection
The most important design was the model connecting the screens.
Validated
Role and task state mattered more than a flat feature hierarchy.
Owners and managers required different priorities, information, and controls.
Not fully validated
External merchant evidence was not retained.
The published case study separates stakeholder and QA validation from formal user testing.
Constraints
Four months, one designer, and a large interconnected scope.
Financial dependencies and edge states increased the need for systematic decisions.
Next
Formalize roles, components, and analytics earlier.
Future work would add milestone-based merchant validation and success measurement.
21
Behind the scenes
From a broad platform vision to production-ready workflows.
The work progressed through four connected stages. Each stage below uses large screens from the cleaned Sketch file so the interface, state changes, and design decisions remain readable.
- 01StructureDefine roles and product scope
- 02ExploreSequence core workflows
- 03ValidateReview states and recovery
- 04DeliverPrepare implementation and QA
STRUCTURE
Separate business oversight from store execution.
I translated the platform scope into two role-aware home experiences. The structure stays familiar, while information and controls change with responsibility.
Business visibility
Revenue, orders, stores, products, and financial services in one overview.
Role-aware access
Company-level tools remain distinct from daily store operations.
Stable navigation
Frequent destinations remain predictable as the product expands.
Action hierarchy
Primary work appears before lower-frequency administration.
EXPLORE
Make every dependency visible before polishing the UI.
The activation journey connects account creation, store setup, payment-service application, and recovery. Numbered screens make the sequence explicit.
Establish identity and access.
Connect business and operating details.
Collect the information required for payment readiness.
VALIDATE
Review the non-ideal paths as carefully as the happy path.
Prototype and QA reviews examined what merchants would see when a service was unavailable, more information was required, or an application reached a final state.
Before activationExplain why the service is unavailable and how to proceed.
Needs attentionTurn compliance uncertainty into a specific next action.
ResolvedConfirm completion and return the merchant to operations.
DELIVER
Connect the implementation handoff to the complete financial story.
Final review linked order state, transaction history, and settlement detail. Shared patterns and explicit states gave engineering and QA a common source of truth.
Recognize status and take the next action.
Find the recorded payment and refund state.
Verify amount, method, date, and settlement time.
226 artboards → 223 unique screens
Every mobile screen was re-exported from the cleaned Sketch source. Three small icon artboards were excluded from the screen archive; visually distinct interaction and system states were preserved even when their source names were similar.
COMPLETE PRODUCT RECORD
The full system, organized by merchant workflow.
223 unique mobile screens are grouped below by product area. The gallery keeps each interface large enough to inspect while preserving the full breadth of the 0-to-1 platform.
Access & setup
22 distinct screens and states
Dashboards & analytics
4 distinct screens and states
Financial services
16 distinct screens and states
Online store & sharing
11 distinct screens and states
Customers & loyalty
22 distinct screens and states
Products & inventory
38 distinct screens and states
Orders & checkout
35 distinct screens and states
Payments & settlement
22 distinct screens and states
Stores & staff
25 distinct screens and states
Settings, support & notifications
15 distinct screens and states
Additional product states
13 distinct screens and states
