07 / Selected workGovernment services · 0→1 concept

IMDA design assessment

Business owners should not need to understand the Government org chart.

I designed MyBusiness Plan as a goal-led orchestration layer for GoBusiness—helping a first-time owner understand the next safe action, the dependency behind it and the agency that remains responsible.

Service DesignProduct DesignUX Strategy
My role
Lead Product Designer — service framing, evidence synthesis, journey and blueprint design, prioritisation, responsive concept design, pilot strategy and measurement
Scope
Design assessment · Evidence → pilot proposal
Focus
Government services · Cross-agency orchestration · 0→1 concept
Evidence status
This is a hypothesis-led proposal prepared for an IMDA Senior UX Designer assessment—not a shipped Government service. Public figures describe the existing ecosystem or an earlier GoBusiness redesign; pilot thresholds are validation targets, not achieved outcomes.
MyBusiness Plan six-stage journey from planning and entity setup through premises checks, application and operation
Documented context and proposed validation
14historical Government touchpoints for an eatery
12currently documented Food Shop Licence steps
120+Government e-services already on GoBusiness
01 · Project overview

What I owned—and the environment around the work

A concise project brief that makes my individual contribution, collaborators and definition of success clear before the detailed process.

01Assessment context
A hypothesis-led Lead Product Design proposal for the IMDA Senior UX Designer assessment, focused on improving cross-agency business setup without claiming a shipped outcome.
02My ownership
I framed the service problem, synthesised public evidence, prioritised user needs, modelled the journey and operating system, designed representative responsive screens and defined a staged validation plan.
03Core collaborators
I produced the assessment independently. The proposed discovery and pilot would bring together first-time owners, GoBusiness, policy, operations, technology and service teams across the relevant agencies.
04Success definition
Owners complete the right setup tasks in the right order and on time, with less avoidable support—while accuracy, consent and agency decision rights remain protected.
02 · Problem

The decision behind the screens

A first-time F&B owner may cross entity registration, digital authorisation, premises approval, licensing, inspection, tax and employment services before opening. Each transaction can work independently while the owner still carries the hidden work of sequencing tasks, transferring context and recovering from exceptions.

  • The owner thinks ‘Can I open my bakery?’ while the system is organised around agency boundaries.
  • A missed dependency can delay fit-out, licensing, hiring and the first day of revenue.
  • Inconsistent status language and silent waiting make it difficult to know who owns the next move.
  • Delegating work to an employee, agent or family member can create blurred ownership and excessive access.

This is not a search problem. It is a confidence problem: am I doing the right thing, in the right order, with the right evidence?

03 · Discovery evidence

Three signals changed the shape of the problem

I connected behavioural, operational and qualitative evidence before choosing a solution. Each signal created a concrete design implication.

01Historical GoBusiness evidence

A previous Government redesign documented 14 touchpoints, reduced a form from 845 to 90 fields and saved 10–14 days for setting up an eatery.

Design implication

Cross-agency friction has been material and addressable, but those results justify discovery rather than predict this concept's impact.

02Current SFA guidance

The Food Shop Licence journey is documented across 12 steps and includes rejection, resubmission and response deadlines.

Design implication

The experience must clarify dependencies and recovery—not only make the happy path easier to browse.

03Existing platform scale

GoBusiness already brings together more than 120 Government e-services and has supported more than six million transactions.

Design implication

The credible product direction is an orchestration layer on the existing platform, not another destination that fragments the ecosystem.

04 · Service system

The experience only works when the backstage works

The blueprint keeps the customer journey, visible product behaviour and operational responsibilities connected across the same sequence.

StageCustomerFrontstageBackstage
1 · Plan

Answers a short set of questions about the business type, premises and target opening date.

A relevant six-stage plan explains the next safe action and estimated effort.

A rules layer assembles the path while agency-owned guidance remains the source of truth.

2 · Establish

Registers the entity and decides who can act for the business.

Entity and access tasks show ownership, completion and downstream dependencies.

ACRA and CorpPass transactions remain authoritative; the plan records progress and hand-offs.

3 · Check premises

Confirms permitted use before committing to fit-out or licensing work.

The plan explains why the premises check comes first and links to the responsible service.

URA or HDB guidance, rule provenance and last-updated details support the recommendation.

4 · Prepare and apply

Collects documents, submits the licence application and responds to requests.

Tasks expose evidence, blockers, deadlines and what will unlock the next stage.

GoBusiness and SFA own submission and decisions while a status adapter normalises progress language.

5 · Operate and recover

Moves into tax, employment and recurring obligations—or resolves an exception.

One progress view shows owner, due date, next move and a clear assisted path.

Exception routing preserves case context and returns policy-specific decisions to the responsible agency.

Scroll horizontally on smaller screens to follow the complete service.

Open the original interactive MyBusiness Plan proposal
05 · Decision trail

Complexity, compressed into three decisions

The artefacts were useful because they helped the team make choices. This is the evidence-to-decision trail behind the final experience.

01
Question

Create another portal or extend the existing platform?

Evidence

GoBusiness already has broad service coverage and transaction scale. A new destination would add another place for owners to understand and trust.

Decision

Design MyBusiness Plan as a goal-led orchestration layer within GoBusiness, with agency transactions always one step away.

02
Question

Show the entire checklist or emphasise one next move?

Evidence

The core uncertainty is not whether tasks exist; it is what can be done safely now, what must wait and why.

Decision

Make the next safe action dominant while keeping the full plan, dependencies, ownership and status available for context.

03
Question

How much systems integration is justified before validation?

Evidence

Shared status and data reuse create value, but also introduce privacy, accuracy, taxonomy and multi-agency delivery risk.

Decision

Start with a read-only plan and deep links, then earn integration through prototype evidence and a bounded F&B pilot.

06 · Two connected lenses

Service Design and Product Design, deliberately connected

I treated the operating experience and the interface as one system. Each lens solved a different part of the same problem.

Service Design

Shaping the ecosystem, hand-offs and operating model.

  • Mapped the owner journey across ACRA, CorpPass, premises checks, SFA, IRAS and CPF
  • Kept each agency as the source of policy truth while designing one journey-level plan
  • Connected planning, application, status and recovery across frontstage and backstage layers
  • Defined decision rights, content ownership and escalation as part of the service—not an afterthought

Product Design

Turning service decisions into clear, usable product behaviour.

  • Turned an agency catalogue into a goal-led six-stage business setup plan
  • Made one next safe action dominant and explained what unlocks blocked work
  • Created a consistent status grammar with owner, reason, deadline and next move
  • Designed narrow, time-bound task delegation instead of sharing full account access
07 · Process

From ambiguity to a decision the team could act on

01

Reframe the form as a service journey

I moved the problem from page-level simplification to the sequence across entity, access, premises, licensing and operating obligations—the coordination work a small business currently performs itself.

02

Separate evidence from assumption

I used public GovTech, SFA, URA and EnterpriseSG sources to establish scale and known friction, then labelled sequence failures and confidence gains as hypotheses requiring discovery.

03

Prioritise by risk and user value

I ranked the next safe action first, shared progress second, safe delegation third and data reuse fourth because wrong sequencing creates cost sooner than duplicate data entry.

04

Model the journey and operating system

The journey follows a bakery owner from plan to operation. The service blueprint connects owner-visible behaviour with rules, status adapters, exception routing and agency decision ownership.

05

Prototype action hierarchy and trust

Desktop and mobile concepts answer three questions at a glance: what should I do next, why now and who owns it? Provenance, recency and recovery sit beside the moment of doubt.

06

Design delivery as evidence gates

I proposed baseline research, a read-only prototype, a four-week shared-status pilot and only then consented data reuse—with explicit comprehension, rework, accuracy and privacy gates.

08 · Constraints and trade-offs

What made the work difficult—and how I responded

These constraints shaped the solution, the order of work and the compromises I made with the wider team.

01

Strong signal, limited primary evidence

The tension

Public evidence supported the opportunity, but an assessment timeline did not provide primary research or proof of this specific solution.

My response

I labelled every assumption, avoided claiming shipped impact and designed the first delivery phase to baseline failure demand with owners and service officers.

02

Consistency versus agency authority

The tension

A unified experience could accidentally hide policy nuance or imply that GoBusiness owns decisions made by individual agencies.

My response

I standardised task and status language while keeping rule ownership, provenance, source dates and authoritative transactions visible.

03

Personalisation versus privacy

The tension

A useful plan needs context, but data reuse and delegation can expose more information or authority than the task requires.

My response

I limited questions to what changes the path and made future prefill consent-specific, reviewable and reversible, with narrow task-level delegation.

09 · Evidence

Evidence that moved the work forward

14historical touchpoints for setting up an eatery
845 → 90fields in an earlier GoBusiness simplification
10–14 dayshistorical time saving from that redesign
12currently documented Food Shop Licence steps
120+Government e-services on GoBusiness
6M+transactions supported by the existing platform

The first three figures describe an earlier GoBusiness redesign; they demonstrate that the problem has been material and addressable, not that this concept would repeat the result. The remaining figures describe the current service ecosystem. No project outcome is claimed.

Open the original interactive MyBusiness Plan proposal
10 · Outcome

What changed

01

Defined a goal-led GoBusiness extension rather than adding another portal to the ecosystem.

02

Turned a fragmented agency sequence into a six-stage plan from business idea to ongoing operation.

03

Connected interface behaviour to rules, status normalisation, exception routing and agency decision rights.

04

Produced a staged pilot strategy with comprehension, rework, accuracy, accessibility and privacy guardrails.

11 · Reflection

Looking back and ahead

Strongest contribution

My strongest contribution was treating cross-agency UX as an operating-model problem, then making it tangible through one testable product concept, a service blueprint and staged evidence gates.

What I learned

In Government services, simplicity is only trustworthy when provenance, decision ownership and exception handling remain visible.

What I would do next

I would interview 12–15 recent F&B founders, shadow five setup journeys and analyse support themes before testing whether at least 80% can identify the correct next action without critical comprehension errors.

Next case study · BlueSG

Charger-less parking & availability