LifeSG is Singapore’s flagship digital service for citizens — the public face of how residents access government schemes, benefits, and information online. It evolved from an earlier product called Moments of Life, which was built around a life-event framing: services organised by what is happening in a user’s life rather than by which agency runs them.

In this self-initiated case study, I redesigned the information architecture of LifeSG’s logged-out mobile web landing to resolve a specific tension observed in the live product. It is a concept project, not a commissioned redesign. No work was done with the LifeSG team, no formal user research was conducted prior to design, and no analytics data was accessed. Every observation is based on directly using life.gov.sg in April 2026, and every recommendation is positioned as the kind of decision that would be validated with data and testing in a real engagement.

The aim was to demonstrate information architecture thinking — diagnosing structural problems, proposing calibrated solutions, and reasoning through tradeoffs — rather than visual design or interaction polish.

The Problem

Opening LifeSG as a first-time visitor, I observed that four distinct navigation systems coexist on the landing page: a flat, task-based list of Services and tools; thematic category cards under Topics; narrative, life-event-framed cards under Guides; and trending topical pills near the top of the page.

Each navigation system is well-designed in isolation. The problem is that they coexist without hierarchy. No primary entry is declared, and the four systems overlap in what they cover. This is not a flaw — it is a tradeoff problem. The platform is trying to serve two distinct user intents simultaneously: high-intent users who know what they need, and low-intent users navigating a life transition without the vocabulary of government schemes. LifeSG’s current IA biases toward high-intent users. Life-event framing exists — in Topics, in Guides, and in the brand’s heritage as Moments of Life — but it sits below the action-first list. A low-intent user scrolls past the content designed for them before they encounter it.

Users

Three user segments are relevant to service discovery. High-intent users know the specific scheme they need and want to complete a task quickly — they are well-served by the existing search bar and action shortcuts. Low-intent, exploratory users are in a life transition — a new baby, a job loss, caring for an elderly parent — and do not yet have the vocabulary of schemes, agencies, or policy terms. Accessibility-first users include elderly users, non-English primary speakers, and infrequent users of government services, who may fall into either intent group but experience higher friction at every choice point.

The redesign targets low-intent users as the primary audience, on the reasoning that high-intent users can navigate any interface with a functional search bar.

I started from a principle that matters more in public-sector design than commercial design: intervene on what is broken, preserve what is working. LifeSG’s content, visual system, and underlying IA pieces are each individually reasonable. The problem is hierarchy and primary-entry ambiguity. So rather than proposing a full redesign, the intervention focused on consolidating the existing life-event framing into the primary entry point, demoting (not removing) action-first shortcuts and search, and preserving the existing Topics, Guides, and content layers — subordinated to the new hierarchy rather than replaced.

The intervention is structural, not visual. The redesign uses the existing SGDS design language — Inter typography, the red-and-white palette, familiar card patterns — so the change reads as evolution of the product’s existing direction, not as a replacement of it.

Before

On the current landing, the user encounters, in order: the hero search bar, trending topical chips, the Services and tools flat list, the Topics cards, the Guides cards, the app download promo, and the news feed. Life-event framing exists at positions 4 and 5 on the page. The flat action list occupies position 3.

After

The new landing promotes a Life events grid to the primary position below the search bar. Actions, Topics, and Guides are not removed — they are accessed through the life event the user selects, rather than competing for attention at the top level. The new content hierarchy becomes: Life event → [curated actions, or stage filter, or personalised dashboard] → Actions.

Designing the destination for each life event, I identified three viable patterns to explore. Each solves the same problem — a single life event like Having a child could have 15+ relevant services, and showing them as a flat list would recreate the original problem — through a different mechanism. These three options were the basis of usability testing with participants.

Option A — Editorial Curation

The platform editorially curates the three to five most commonly used actions for each life event. These appear as an inline expansion when the user taps the life event tile. Sibling life events remain visible, preserving list context and supporting course-correction. For users whose needs fall outside the curated set, a “Browse all services by topic” link leads to a topic-grouped detail page.

Flow: Life events → tap “Having a child” → inline expansion shows curated actions → (optionally) topic-grouped detail page.

Option B — User Self-Segmentation

When the user taps a life event tile, a modal asks: “What best describes your situation?” The user selects their segment and lands on a stage-filtered destination page showing only the actions relevant to that point in their journey.

Flow: Life events → tap “Having a child” → modal asks for situation → stage-filtered destination page.

Option C — Personalised Life Stage Dashboard

Rather than asking the user to select a single life event, Option C asks: “Where are you at in life?” The user selects all situations that currently apply — having a child, looking for work, managing health — and lands on a personalised dashboard surfacing relevant actions across all selected contexts simultaneously. A “Skip for now” option is available for users who prefer not to personalise.

This option addresses a user need that Options A and B do not: the multi-life-event user. In practice, many users are navigating more than one life transition at once. Option C treats this as the norm rather than the exception.

Flow: Landing → “Where are you at in life?” multi-select → personalised dashboard showing relevant actions across all selected life events.

The wireframes below document all three proposed flows in low fidelity. The Figma flows demonstrate the design thinking behind the pattern choices and the reimagined IA hierarchy.

Option A — Editorial Curation

Pros. Fastest path to action: two taps from landing to a relevant action. Low cognitive load. Mirrors LifeSG’s existing patterns, reducing retraining.

Cons. Curation is a platform decision, not a user decision. Does not adapt when user needs genuinely differ across stages of the same life event. Requires usage analytics to justify the curated ranking.

Option B — User Self-Segmentation

Pros. Content is personalised to the user’s declared context. Reduces irrelevant actions. Scales well for life events with meaningfully different content across stages.

Cons. Adds a tap and a decision point. Forces commitment before showing content. Requires more upfront editorial effort per stage.

Option C — Personalised Dashboard

Pros. Directly serves multi-life-event users. Treats the user’s full life context as the primary navigation model. Most flexible and personally relevant for returning users.

Cons. Adds friction on first visit — asking users to set up a context before seeing any content. Requires state persistence (cookie or login) which has privacy implications for a government app. Most architecturally complex of the three options. May add cognitive overhead for users who just want to complete a single task quickly.

Research Goal

To understand whether low-intent users could identify a relevant entry point and navigate to appropriate government support without prior knowledge of scheme names or agency structures — and to identify which of the three proposed IA patterns best supports that behaviour.

Method

Moderated usability testing with 3 Singapore residents currently navigating a life transition. Each session ran approximately 30 minutes. Participants were shown all three options in sequence and asked to complete the same task using each. Sessions were conducted one-on-one with the researcher observing silently during the task phase and asking debrief questions afterwards.

Participants

Participants were recruited to represent the three primary user segments identified in the design phase: a new parent navigating post-birth government schemes, a mid-career professional who recently changed jobs, and a caregiver managing support for an elderly parent. All three are Singapore residents who have used LifeSG or equivalent government apps within the past year. UX designers and tech professionals were excluded to avoid participants who would critique the wireframes rather than use them naturally.

Session Structure

Each session opened with a framing statement to set participant expectations:

“What you’re about to see is a prototype — some parts may not be fully interactive, and that’s expected. I’ll give you a scenario and a task. Try to approach it the way you normally would if you were using the real app on your own. Please think out loud as you go. There are no right or wrong answers — I’m testing the design, not you. If something is confusing, that’s useful information for me. I may not answer questions during the task — if you ask me something I’ll usually say ‘what would you do if I wasn’t here?’”

Task Scenario (Phase 1)

“You are going to have a baby soon. You’ve heard there’s government help available for new parents but you’re not sure what you qualify for. Use this website to find out what’s available to you.”

During Phase 1, the researcher observed silently and noted exactly where participants looked first, what they tapped, where they hesitated, and what they said out loud. Contingency prompts were prepared for common divergences — if a participant went straight to the search bar, the researcher noted it and asked afterwards: “I noticed you went to the search bar first — can you tell me more about why? Is this how you would normally search for things?” If a participant selected a specific action like “Apply for Baby Bonus” before exploring the broader structure, the researcher noted the choice and moved on to the next option without interrupting.

Debrief Questions (Phase 2)

After all three options were completed, the researcher asked the following debrief questions:

1. If this were the real LifeSG website, which would you actually want to use?
2. Was there any moment across any of the options where you felt lost or unsure what to do next?
3. Option A showed you a list of actions after selecting a life event. Option B asked you a question about your situation before showing you content. Option C asked you to select everything that applies to your life right now. Which felt most like how you actually think about your situation?
4. Which option got you to relevant information fastest?
5. How confident were you that you had found the right information?
6. Which option felt like it required the most effort from you?
7. Was there any moment that felt like the app was asking too much from you?
8. Did you feel comfortable with the information each option was asking for?

Note on sample size

With 3 participants this research is directional rather than conclusive. Findings identify patterns worth investigating and inform the design recommendation, but would require validation with a larger and more diverse sample before informing production decisions. All findings are reported with specific participant counts rather than generalised claims.

Key Observation — No Users Used the Search Bar

Across all three options, none of the participants used the search bar as their primary navigation method. This is a significant directional finding — it reinforces the core hypothesis that a life-event-based IA better serves low-intent users than a flat, task-oriented structure or search-first approach.

Table 1 — Happy Flow Summary

Whether each participant followed the intended navigation path through each option, and where they ended up.

Option A — Editorial Curation

Option A produced the most varied behaviour. User 1 went straight to "Apply for Baby Bonus" — a single high-priority task rather than holistic discovery. User 2 deliberately swept through all options under "Having a child" in chronological order, preferring self-directed exploration. User 3 bypassed the life event tiles entirely and selected "Child LifeSG Credits" from the landing page, showing that prominent shortcuts can override the intended IA flow. Option A was described as "general" and requiring "trial and error." It demanded the most effort from two of three users — yet User 2 strongly preferred it for exactly this reason: it gave him freedom to explore without platform direction.

Option B — User Self-Segmentation

Option B produced the most consistent happy flows — all three users reached relevant content. Users 1 and 3 both landed on "Support schemes and subsidies" and "Programmes for first-time parents." User 2 completed the flow but found it "limiting" since it directed him to a single filtered page. Two of three users said Option B got them to relevant information fastest. No user felt the platform asked too much — one noted the questions felt purposeful rather than intrusive.

Option C — Personalised Life Stage Dashboard

Option C produced happy flows for all three users but revealed two notable friction points. User 2 tried to "swipe to the next page" on the modal — importing a native app gesture into a web context — and selected "Child is below 12 months" despite the pre-birth scenario, exposing an IA mismatch at the stage-selection step. He also expressed uncertainty about whether he could navigate back. Despite this, two of three users chose Option C as their overall preference, citing its directness: "just click, click, click." User 2 found the opening question unnecessary given his exploratory style.

Table 2 — User Preferences Summary

Table 3 — Key Debrief Responses

What the Findings Mean for the Recommendation

The findings support the original recommendation against choosing a single pattern globally. Option B consistently guided users to relevant content most efficiently and produced happy flows for all three participants — making it the strongest default for life events with meaningful stage variance. Option A remains valuable for exploratory users and life events with a homogeneous action set. Option C's preference among two of three users suggests strong appeal, but the UI friction at the stage-selection step (swipe gesture assumption) and the IA mismatch (wrong stage selected for the scenario) indicate it requires more design iteration before being recommended as a primary pattern.

Note: With 3 participants this research is directional rather than conclusive. Findings identify patterns worth investigating but would require validation with a larger sample before informing production decisions.

Rather than choosing one pattern globally, the recommendation is to treat the choice as an editorial decision made per life event.

1. Option B for life events where user needs differ sharply by stage:
   • Having a child — pregnancy vs. newborn vs. toddler
   • Caring for an elderly parent — planning, active care, bereavement
   • Preparing for retirement — pre-retirement vs. active retirement
2. Option A for life events where the action set is largely homogeneous:
   • Getting married — register marriage, housing grants, joint tax filing
   • Looking for work — SkillsFuture, Workfare, WSG portal
   • Buying a home — BTO, grants, legal steps
3. Option C as an optional “personalise my view” feature for returning users, rather than the default entry for first-time visitors — where the setup friction is harder to justify before the user has established trust with the platform.

The underlying principle is that IA depth should match content variance. Where user needs genuinely diverge by segment, the extra personalisation step repays its friction cost. Where needs converge, the simpler pattern wins.

1. End-to-end UX ownership. From personal observation that identified the problem, through three design directions, usability testing with real participants, synthesis of findings, and a React prototype currently in development.
2. Diagnostic observation before designing. The problem named is specific to what was observed on the live product. Every wireframe is grounded in an actual LifeSG page.
3. Working within an existing system. The redesign preserves LifeSG’s visual language, Topics, Guides, and search. It restructures rather than replaces.
4. Tradeoff-based reasoning. The case study does not assert that one pattern is universally better. It argues that the right pattern depends on content variance, and makes the argument explicit.
5. Honest scoping. This is concept and research work in progress, not a finished answer. The recommendation is positioned as what would be validated further in a real engagement.