Commerce / Mobile UX / Conversion

Order Portal

Mobile-first ordering experience redesign across BSS/OSS complexity

Redesigned MyRepublic’s mobile order journey to reduce interruption, improve decision clarity, and simplify conversion-critical steps while preserving operational reliability.

Role

Design Strategy, Leadership, Systems Thinking

Impact

UX, CX, product, engineering, and content/brand stakeholders

Timeline

Jun 2020 - Dec 2020

60%

Conversion lift year on year

S$5.2m

first full-year profitability

50.1%

Stake acquired shortly after

Feature Deep Dive

Journey Continuity

Tab 1 of 6

Journey Continuity

Moved Sign Up / Log In earlier so users could customise plans without interruption. This reduced mid-flow breakpoints and kept the order path coherent on mobile.

Problem

MyRepublic's Order Portal was the single most important conversion touchpoint in the customer journey - where user intent either became revenue or dropped off. Despite that, it had gone largely unexamined while the product grew around it. Redesign was driven by an executive mandate to improve mobile conversion, tied directly to growth targets. Here were the problems we found:

  • Order portal was the end-of-funnel conversion surface for mobile and broadband plans
  • Sign Up / Log In appeared mid-order, cold-stopping users after they'd already invested time selecting a plan
  • No path back after authentication - users who changed their mind had to restart entirely
  • Number selection was destructive - "Change Number" wiped the previous selection instantly, with no confirmation
  • Competing CTAs and dense copy created confusion with no clear hierarchy or priority
  • CX team feedback and internal data both flagged drop-offs and support contacts at these exact steps

Constraints

Several forces shaped what was and was not possible - navigating them was as much a design challenge as the interface itself.

Order Portal key constraints diagram
  • Project needed to be completed within 6 months initially just for mobile, but scope was added for broadband halfway into the 6 month timeline.
  • Randomised number pool: deselected numbers could not be guaranteed to reappear; this was a backend limitation we had to design around honestly.
  • Legal and compliance requirements could not be removed: telecom regulations mandated disclosures that had to live somewhere in the flow.
  • Timeline pressure: this was the biggest revamp to date, with mobile and broadband surfaces in scope simultaneously; changes to one affected the other.
  • Cross-team dependencies: the CX team owned key copy decisions, meaning alignment was a prerequisite to any change.
  • Scalability requirement: solutions had to be portable to other portal surfaces, ruling out one-off fixes.

Architecture

Disclaimer: This section provides a high-level overview only. Specific implementation details are intentionally abstracted due to platform security and confidentiality requirements.

Order Portal architecture diagram

The redesign had to work across a tightly coupled technical stack that we had limited ability to change. Understanding what each system could and could not do was foundational to every design decision.

In-house BSS/OSS

Billing and operational support systems were proprietary and internally managed; any changes to order flow logic, plan configuration, or customer data handling had to be scoped against what the BSS/OSS could support, making some "simple" UX changes technically expensive.

IMDA-controlled numbering system

Mobile number allocation in Singapore is regulated by the Infocomm Media Development Authority (IMDA), meaning the number pool was not ours to manage freely; numbers were drawn from a regulated pool, and once released back, could not be held or reserved for a user - this was the hard constraint behind the destructive "Change Number" behaviour we inherited.

Front-end UI layer

The portal UI sat as a relatively thin layer on top of these backend systems; this gave us design flexibility on the surface but meant any stateful behaviour (such as preserving a user's selected number across navigation) required deliberate coordination with backend logic rather than being a pure front-end fix.

Third-Party Delivery integration

SIM card fulfilment was wired directly to delivery's logistics system; the delivery date and time selection step in the order flow was a live handshake with their scheduling API, which meant available slots were dynamic and the copy around delivery delays was not just CX preference - it reflected real operational variability we had to communicate honestly without alarming users mid-checkout.

Decisions

Moving auth forward was the most debated decision

A few calls were harder than they looked from the outside. Conventional wisdom says early login creates bounce risk; we reframed it around funnel recovery, arguing mid-flow abandonment at a high-intent moment was the bigger cost.

Tradeoff

Early login risks losing low-intent users who may not have converted anyway. Mid-funnel abandonment loses high-intent users who had already decided to buy - a significantly higher cost. We accepted the former to protect against the latter.

Exec alignment required conversion framing

Balancing speed/autonomy against trust/buy-in. More explanation and evidence-sharing builds credibility but slows execution. Less explanation keeps pace but fuels doubt.

Tradeoff

Quick wins and visible proof points whilst incorporating skeptic feedback signals respect. Prove before persuading; a small demonstration often does more than a long argument.

Negotiated the CX team's disclosure copy

Their instinct toward transparency was right, but the execution buried it; the compromise was a single plain-language line at the relevant step instead of a pre-emptive text wall.

Tradeoff

Reduced front-loaded detail in favour of contextual disclosure to preserve clarity at decision moments.

Chose system-level thinking over speed

Deliberately built components and copy frameworks that could extend to broadband and future portal surfaces, accepting slower individual decisions to reduce downstream rework.

Tradeoff

Traded short-term delivery speed for long-term scalability and consistency across surfaces.

Outcomes

Journey Continuity

Reduced interruption and unnecessary context switching across the checkout flow.

Improved

Decision Clarity

Improved comprehension with cleaner CTA hierarchy and context-specific communication.

Higher

Mobile Usability

Card-first structure and cleaner information hierarchy supported faster cognitive scanning.

Stronger