Points Mall

01 / BACKGROUND

Background

The points mall combines two different business models: points-based lotteries and points redemption. Although both consume the same points balance, their operational rules differ significantly. Lottery flows focus on campaign periods, eligibility, total and daily participation limits, prize inventory, results, winner addresses, and shipping payments. Redemption adds product limits, points-plus-cash payment, shipping fees, inventory reservation, fulfillment, and refunds. Without a unified definition for points, inventory, payments, orders, and states, concurrent requests or failed operations can easily lead to duplicate deductions, overselling, payment inconsistencies, or orders that cannot be traced. The project therefore focused on building a complete business loop rather than simply adding a mall interface.

02 / MY ROLE

My Role

Mapped the complete user journey across the points mall home, lottery lists and details, participation confirmation, results, winner records, redemption product lists and details, checkout, address selection, payment, order tracking, and after-sales flows. Defined activity states such as upcoming, active, ended, disabled, and sold out; established rules for points, cash, shipping, inventory, and purchase limits; designed validation for total attempts, daily attempts, points balance, eligibility, limits, and inventory; specified the winner fulfillment flow, including address selection, shipping payment, retries, and expiration; defined a mixed payment model using points + cash + shipping, where cash or shipping can be zero; designed the admin capabilities for campaign configuration, prizes, redemption rules, participation limits, records, orders, shipping, refunds, and exports; and added exception and QA scenarios covering insufficient points, limit violations, insufficient inventory, duplicate requests, payment failures, refund failures, export failures, and repeated state submissions.

03 / CORE PROBLEMS

Core Problems

First, lotteries and redemption share the same points asset but have different eligibility, inventory, order, and fulfillment logic. Second, lottery participation depends on campaign timing, total attempts, daily attempts, points balance, and prize inventory, while redemption adds purchase limits, cash, shipping, and product inventory. Third, all user and admin interfaces must use the same points and payment definitions. Fourth, winner records and redemption orders move through multiple states and must remain traceable. Fifth, points, inventory, payments, and refunds require consistency and protection against duplicate requests. Finally, admin operations must handle complete success, complete failure, partial failure, and recovery without leaving inconsistent data.

04 / SOLUTION

Solution

Structured the experience around a unified flow: mall entry → lottery/redemption branch → eligibility and inventory validation → record/order creation → payment and fulfillment → admin processing → after-sales tracking. Lottery requests validate activity state, eligibility, total and daily attempts, points balance, and prize inventory before creating a unique lottery record. Winning users then move through fulfillment or shipping-payment states, with retry and expiration rules. Redemption requests validate product state, purchase limits, points balance, cash, shipping, and inventory before creating an order containing a clear breakdown of all components. Both user and admin systems share the same state definitions and amount calculations. Critical write operations use idempotency and transactional or compensating logic so that points, inventory, orders, payments, and refunds remain consistent when failures occur.

05 / PROCESS & RULES

Process & Rules

06 / RESULT & REVIEW

Results & Reflection

Delivered a complete product solution covering points lotteries, points redemption, user and admin experiences, fulfillment, and after-sales operations. The design unified rules for points, participation limits, purchase limits, inventory, cash, shipping, payments, logistics, refunds, and expiration states. It also provided developers with explicit state and data rules and gave QA a structured basis for testing deductions, inventory changes, mixed payments, duplicate requests, payment failures, refunds, and state transitions. The solution emphasized consistency and traceability rather than merely adding interface functionality.

ReflectionThe main complexity of a points mall is not the number of screens but the interaction between multiple assets and states. Once points, inventory, cash, shipping, orders, and fulfillment are connected, a failure in one step can affect the entire chain. Product design therefore needs to define not only what users see after an action, but also what data changes, how failures recover, how duplicate requests are handled, and how every state remains traceable. For complex commerce flows involving points, inventory, payment, and after-sales operations, state machines, idempotency, transaction boundaries, compensation, and operation logs should be defined during the requirements phase.