Trading uncertainty for structure
A system-first redesign of HKEX’s digital ecosystem—built to handle content variability at scale.
Background
A revamp of the group website for Hong Kong Exchanges and Clearing Limited (HKEX) — focused on refreshing its structure, usability, and visual language across a content-heavy digital ecosystem spanning the homepage and core corporate pages, each owned by different departments, catering to distinct audiences, and subject to frequent updates.
Role
Experience Designer — part of a design team building modular page systems and shaping interaction patterns within an evolving design system.
Timeline
March 2026 – Present
Core challenge
How might we design a system that can move forward without creating a bottleneck—where waiting for finalised content delays delivery, but moving ahead without it risks constant rework, and may vary across different audiences and intents?
Impact (In progress)
Enabled parallel progress by decoupling design from content readiness
Translated content audits into tangible, reviewable page structures
Established a reusable, component-driven system across multiple page types
Reduced ambiguity for stakeholders by visualising content within structured layouts
Context & Stakes
The HKEX group website isn’t your typical marketing site. As one of the world’s leading exchange groups, HKEX operates financial markets and connects capital with opportunities across global investors and businesses.
The revamp was driven by a shift towards more engaging, informative, and functional storytelling, alongside an updated visual aesthetic — while maintaining HKEX’s clean, corporate identity.
At the same time, the site operates as a content-heavy ecosystem, where different pages are owned by different departments and serve distinct audiences — from investors and regulators to job seekers and the general public.
Content is updated at different cadences, structured in different ways, and designed to support different intents. As a result, consistency isn’t just a design goal — it’s an operational challenge.
The challenge wasn’t just about designing pages, but designing a system that could support different intents under constant change.
*This work sits within a broader engagement that included art direction exploration and a full content audit. This case study focuses specifically on the design of modular page systems.
The Real Problem
The initial plan followed a typical, linear process — audit content, get approvals, then design.
In practice, this quickly broke down. Content required input from multiple departments, making approvals slow, iterative, and often subject to change. At the same time, content wasn’t just delayed — it varied in structure, depth, and purpose across sections.
This created a circular dependency. Design needed approved content to move forward, while content needed design to be properly reviewed.
Waiting for content to be finalised would delay delivery. Moving ahead without it meant designing against assumptions that could quickly change.
Reframing the problem
Instead of asking:
“When will the content be ready so we can design?”
The question became:
“How might we design a system that can move forward without creating a bottleneck — where waiting for finalised content delays delivery, but moving ahead without it risks constant rework, and may vary across different audiences and intents?”
This shifted the focus from designing individual pages to designing a system that could absorb uncertainty and variation.
Key Challenges & Constraints
Content dependency across departments
Content required input and approval from multiple stakeholders, each with their own timelines and priorities. This created a bottleneck where design couldn’t progress without content, while content couldn’t be meaningfully reviewed without design.
Evolving and inconsistent content
Content was not only delayed, but also varied in structure, depth, and purpose across sections. This made it unreliable to design against fixed or finalised content.
Multiple audiences, different intents
Different sections served distinct user groups with different goals and expectations. This meant patterns couldn’t be one-size-fits-all — they needed to adapt to context while remaining consistent.
Scalability across the ecosystem
The system needed to work across multiple pages, departments, and future updates. Design decisions couldn’t be one-off — they had to scale.
Minimising new components
The existing design system needed to be extended — not expanded unnecessarily — while keeping any additions consistent with the overall design language. Flexibility had to come from how components were used — not how many were created.
Decision 1 —
Designing for completeness as a system blueprint
Decision 1
What I was facing
Content was not finalised and varied significantly across pages — in structure, depth, and purpose. Designing for an “average” case risked breaking once real content was introduced, while waiting for final content wasn’t an option.
Decision 1
What I chose to do
We designed the system around the most complete possible scenario, using completeness as a shared blueprint across components and modules.
This was informed by a combination of content audit patterns and stakeholder input — where different teams surfaced the types of content they needed to showcase across their respective pages. Rather than creating separate components for each case, I consolidated these needs into a standardised structure that could be adapted across contexts.
This established a simple rule: design for the maximum state, then scale down based on context — not the other way around.
Decision 1
Component level
Cards were designed with all potential elements upfront — including optional imagery, metadata such as category and date, titles, descriptive text, and primary actions like CTAs. Variations were then created by removing or toggling elements, depending on context.
Decision 1
Module level
This same principle extended to modules. Sections were structured to include a header, supporting description, CTA, and a flexible card grid — designed to accommodate different content volumes (e.g. 2, 3, 4, or more items) without breaking the layout.
Before
After
Decision 1
Managing trade-offs
Designing for completeness introduced the risk of visual heaviness. To manage this, I established clear typography hierarchy and set constraints such as maximum word counts for titles and descriptions — ensuring the system remained readable even in its most complete state.
Decision 1
Why it mattered
It’s easier to remove than it is to add.
Designing for completeness meant the system could accommodate different content without redesign, remain stable as content evolved, and reduce rework caused by missing or unexpected elements.
It also aligned with HKEX’s existing design system — extending current components rather than introducing entirely new ones — while setting a foundation that could support future implementation within a flexible CMS or page builder.
Instead of reacting to content, the system was built to anticipate it — across both components and modules.
Decision 2 —
Structuring for intent and flexibility
Decision 2
What I was facing
While Decision 1 established a complete structural baseline, the same components and modules now needed to work across different sections — each serving distinct audiences with different goals.
Even when content appeared similar, its intent varied significantly. An event listing, a press release, and a job posting could all use the same structure — but what users needed from each was different. Treating them the same risked either overloading users with unnecessary information or removing context that was important.
Decision 2
What I chose to do
I adapted the system based on intent, not just structure — ensuring both components and modules remained relevant to the context in which they were used.
This built on the complete blueprint from Decision 1, where elements could be selectively included or removed depending on purpose — not through rigid rules, but by translating content variability into flexible, structured options that stakeholders could apply based on their needs.
Decision 2
Component level
At the component level, cards were designed to support different intents by allowing elements to be prioritised or removed as needed.
Event-based content surfaced time-sensitive metadata such as dates
Content or media-focused cards retained contextual metadata
Utility-focused content such as job listings removed non-essential elements like imagery
Decision 2
Module level
This same principle extended to modules.
Sections were designed as flexible compositions where stakeholders could adjust:
content density (how many items to show)
supporting context (whether descriptions were needed)
actions (whether a CTA was required)
Rather than enforcing fixed templates, the system provided a consistent structure that allowed teams to configure sections based on what they needed to communicate.
Before
After
Decision 2
Managing trade-offs
Allowing this level of flexibility introduced the risk of inconsistency. To manage this, all variations were grounded within a shared structure — ensuring that even as content changed, the system remained coherent.
Decision 2
Why it mattered
Flexibility wasn’t just about reuse — it was about enabling meaningful choice.
Designing this way allowed the system to:
give stakeholders control without requiring new components
reduce reliance on design for every content change, by giving stakeholders a structured way to configure content themselves
support different audiences without fragmenting into separate patterns
remain consistent while adapting to context
The system didn’t dictate decisions — it enabled them within a structured framework.
Decision 3 —
Encoding intent through usage patterns
Decision 3
What I was facing
While components and modules could now adapt to different content and intents, there was still a gap at the layout level.
Content didn’t just vary in type — it also varied in volume. Some sections needed to present a small, curated set of items, while others needed to accommodate larger or continuously updated content.
Without clear patterns, layouts risked becoming either:
too rigid to scale
or too loose, leaving users unclear on how to engage with the content
Decision 3
What I chose to do
I introduced usage patterns at the module level, allowing layout behaviour to adapt based on content volume and intent.
Rather than treating modules as static layouts, I defined patterns that signalled how content should be consumed — whether it was fixed, curated, or exploratory — based on how much content needed to be presented.
These patterns were grounded in observed content behaviours, ensuring they weren’t arbitrary but reflective of how content naturally appeared across the system.
Decision 3
Fixed / curated patterns
For smaller sets of content (e.g. 2–4 items), modules were designed as static layouts.
This signalled:
a deliberate, curated selection
content that users were expected to view in full
CTAs could be optional or removed entirely if the content was self-contained.
Decision 3
Expandable / exploratory patterns
For larger or dynamic content sets, modules transitioned into horizontally scrollable layouts with navigation controls.
This signalled:
additional content beyond what was immediately visible
a more exploratory interaction
CTAs could be replaced with navigation patterns depending on the use case, allowing users to browse content freely rather than being directed immediately away from the page.
Before
After
Decision 3
Managing trade-offs
Introducing different behaviours risked inconsistency across the system. To manage this, patterns were defined within clear thresholds, ensuring behaviour remained predictable and consistent.
This ensured that variations in layout were intentional and repeatable, rather than ad hoc decisions.
Decision 3
Why it mattered
Layouts weren’t just containers — they communicated how content should be used.
By encoding behaviour into patterns, the system could:
guide users on what to focus on versus what to explore
adapt to different content volumes without redesign
maintain consistency while supporting different interaction models
The way content was structured directly shaped how it was understood and used.
Decision 4 —
Composing modular systems, not fixed pages
Decision 4
What I was facing
While components, modules, and patterns were now defined, the final challenge was how these would come together at the page level.
Traditionally, pages would be designed as fixed templates. But given the variability in content, stakeholders, and use cases, fixed pages would quickly become restrictive and require frequent redesign.
Decision 4
What I chose to do
I shifted the approach from designing pages to designing modular page systems — where pages were composed of reusable sections that could be arranged, adapted, and scaled based on need.
Each module — built from components and guided by usage patterns — acted as a self-contained building block with its own structure, behaviour, and flexibility.
Rather than defining rigid page templates, I focused on creating a system where:
modules could be reordered or removed
sections could scale based on content
new pages could be assembled without introducing new patterns
[Page composed of stacked modules (different sections)]
Decision 4
How it came together
Because modules already encoded:
completeness (Decision 1)
intent (Decision 2)
behaviour (Decision 3)
they could be combined seamlessly to form pages that were:
flexible
consistent
scalable
The system wasn’t built at the page level — it emerged from how modules were combined.
Decision 4
Managing trade-offs
Designing at a system level introduced the risk of pages becoming inconsistent or overly fragmented. To manage this, all modules adhered to shared structures and patterns — ensuring that even when rearranged, pages remained cohesive.
Decision 4
Why it mattered
This shift fundamentally changed how stakeholders interacted with the design.
Previously, feedback was abstract — based on content lists or isolated components. Once modules were composed into full page templates, stakeholders could see content in context.
This made feedback more actionable:
it became easier to identify what was missing or unnecessary
stakeholders could make clearer decisions on content
back-and-forth was reduced
Seeing the system at the page level turned uncertainty into clarity.
Impact & Outcomes
Enabling Parallel Progress
Decoupling design from content readiness allowed work to move forward without waiting for approvals.
Instead of blocking progress, design and content could evolve in parallel — reducing delays caused by cross-department dependencies.
Making Content Review Tangible
Translating the content audit into structured page modules made abstract information easier for stakeholders to understand and evaluate.
Rather than reviewing content in isolation, teams could see how it would exist within a page — improving clarity and speeding up feedback.
Establishing a Reusable System
Designing components, layouts, and sections as part of a cohesive system created a foundation that could be reused across multiple pages and contexts.
This reduced the need for one-off solutions and ensured consistency across the ecosystem.
Reducing Ambiguity Through Structure
By defining clear patterns for how content is structured and presented, the system reduced ambiguity for both stakeholders and future implementation.
Content decisions became easier to make when framed within an existing structure, rather than starting from scratch.
While still evolving, the system has shifted the project from reacting to content changes to absorbing them by design.
Reflection & Learnings
Designing without certainty
Designing this system reinforced that design doesn’t always have the luxury of stable inputs.
In environments where content is incomplete, inconsistent, and constantly changing, waiting for clarity isn’t always viable. Progress often depends on designing systems that can move forward without it.
Beyond reusability
It also shifted how I think about design systems.
It’s not just about creating reusable components, but about defining how those components adapt — to different content, different intents, and different contexts — without losing coherence.
Restraint over expansion
Finally, it highlighted the importance of restraint.
Scalability isn’t achieved by creating more components, but by making better use of fewer. Flexibility came from how elements were structured and combined, not from expanding the system itself.
In the end, the challenge wasn’t designing for what was known — but designing for everything that wasn’t.
Credits
Senior Manager, Experience
For introducing the idea of designing for completeness, and for the constant support and guidance through thoughtful design reviews and 1:1s.
Senior UI Designer
For the strong visual craft, the reliability of always stepping in when needed, and the steady calm that kept the team grounded under pressure.
UX Designer
For leading the content audit and early wireframes that grounded the work, and for always stepping in to support the team and keep things moving.
HKEX Senior UI/UX Designer
For the trust in our process, and for the ongoing collaboration, feedback, and direction that kept the team aligned and moving in the right direction.
© 2026 Nigel Lim. All Rights Reserved.
Made with Framer, and the eventual peace that came from a truce between my perfectionism and procrastination.