Back to portfolio Muhd Shaifol muhdshaifol@gmail.com
Case Study: Bluemeg Technologies

From Whitelabel to Console

Redesigning Bluemeg's SaaS platform to replace a costly whitelabel model with a unified console — rebuilding KYC, company onboarding, and access management for a leaner, scalable product. Led a team of 3 designers and 1 front-end developer.

CompanyBluemeg Technologies
My RoleLead Product Designer & Manager
DurationOct 2017 – Jul 2018
PlatformB2B SaaS — Web Dashboard
Lead Product Designer
3 × Product Designers
1 × Front-end Developer
Product Manager (dual role)
Domain
B2B SaaS / FinTech
Focus
KYC & Company Onboarding
Model Shift
Whitelabel → Console
Burn Rate Impact
–30% within one quarter
01
Context & Strategic Shift

The business model problem hiding inside a UX problem

Bluemeg Technologies operated a B2B SaaS platform serving corporate clients with digital secretarial and compliance tooling. Under the original whitelabel model, every new client received their own isolated environment — a separate deployment, a separate database, branded to their organisation. It looked great on paper. In practice it was unsustainable.

Each whitelabel deployment cost engineering time, infrastructure spend, and ongoing maintenance overhead. Onboarding a new client took weeks. Pushing product updates required coordinated releases across every client environment. The operational burn rate was quietly eating the company's runway.

The strategic decision was made to switch from a whitelabel model to a console model — a single shared platform where clients are tenants, managed through a centralised console with configurable access controls and permissions. This wasn't just an infrastructure decision. It required a complete rethink of the product's UX: how companies are onboarded, how KYC is handled, how access and roles are managed, and how the platform communicates across organisational boundaries.

Before — Whitelabel Model
✕Each client = separate environment + separate DB
✕New client onboarding took 2–4 weeks of eng work
✕Product updates deployed separately per client
✕KYC handled via email and manual review
✕No unified view of all clients for internal ops
✕High infrastructure cost at every growth step
After — Console Model
✓Single shared platform — clients as tenants
✓Self-serve onboarding with guided KYC flow
✓Single deployment — updates roll out to all clients
✓Digital KYC with document upload and review console
✓Centralised console for access, roles, permissions
✓Infrastructure cost scales with users, not client count
–30%
Reduction in operational burn rate within first quarter post-launch
2–4wks
Client onboarding time reduced to hours via self-serve KYC flow
1 → ∞
From one-deployment-per-client to unlimited tenants on a single codebase
02
Design Challenges

Four hard problems in one redesign

KYC as UX
Know Your Customer verification is inherently friction-heavy — documents, declarations, review steps. The challenge was designing a KYC flow that felt like a product onboarding, not a compliance form. Every drop-off in the KYC funnel was a lost client.
Multi-tenancy mental model
Users had to understand they were now operating in a shared console, not their own branded environment. Designing clear organisational boundaries — your company, your team, your data — within a shared system required careful information architecture and role-based UI.
Access & permission complexity
The console needed to handle nested permission structures: platform admins managing client companies, client admins managing their teams, and team members with varying access levels. Translating this into a UI that was both secure and comprehensible was a significant design challenge.
Team coordination at speed
Leading a team of 3 designers on an accelerated timeline meant establishing clear design ownership, a shared component system, and critique rhythms that kept work aligned without creating bottlenecks. Design system discipline was non-negotiable from week one.
03
UX Process

A different process for a different kind of problem

Unlike a zero-to-one product, this was a redesign of an existing, live platform with real clients. The UX process was shaped by that constraint — we couldn't afford to break what was working while rebuilding what wasn't. The approach prioritised understanding the current system's failures before proposing anything new.

Phase 1 — Audit
Heuristic Evaluation of the Existing Platform
Before any research or ideation, the design team conducted a structured heuristic evaluation of the current whitelabel product — mapping usability violations against Nielsen's 10 heuristics. This produced a prioritised issues register that became the backbone of the redesign scope. 23 issues were identified; 9 rated high severity, directly related to onboarding and KYC flows.
Heuristic evaluationNielsen's 10 heuristicsIssues registerSeverity rating
Phase 2 — Discovery
Stakeholder Workshops & Client Interviews
Ran two structured stakeholder workshops — one with Bluemeg's internal operations team (who managed client onboarding manually), one with three existing client companies. Objective: map the current onboarding journey end-to-end and surface the moments of highest friction. Client interviews revealed that KYC abandonment was primarily caused by unclear document requirements and lack of progress visibility, not the document submission itself.
2 stakeholder workshops3 client interviewsCurrent-state journey mapFriction mapping
Phase 3 — Definition
Job Stories & Permission Matrix
Rather than traditional personas (the user types here were well understood), the team used Job Stories to frame design requirements around specific situations and motivations — particularly useful for the access and permission design where context-of-use matters more than user type. Separately, a permission matrix was built mapping every user role (platform admin, client admin, team member) to every system action — this became a shared reference across design and engineering throughout the project.
Job storiesPermission matrixRole mappingSystem action audit
Phase 4 — Design
Component-led Design & Team Critique Cycles
Design began with the component library — establishing the shared UI foundation before any screen was built. Each designer owned a distinct module (KYC flow, console management, dashboard/reporting) with weekly cross-team critique sessions to maintain consistency. Three iteration rounds on the KYC flow alone, driven by internal review and early client feedback sessions, before the prototype was considered ready for development handoff.
Component-first approachModule ownershipWeekly design critique3 KYC iteration rounds
Phase 5 — Validation
Moderated Testing & Acceptance Criteria Review
Moderated usability testing with 8 participants — 4 from client companies (simulating the onboarding experience) and 4 internal Bluemeg operations staff (simulating console management). Test outputs were mapped back to the original heuristic issues register to confirm resolution. Each design change required a documented acceptance criterion before being cleared for development.
8 test participantsModerated usability testingHeuristic resolution mappingAcceptance criteria
04
Heuristic Evaluation

Finding the cracks before building the fix

The heuristic evaluation gave the team a shared, evidence-based view of the platform's existing failure points — preventing the common trap of redesigning based on opinion rather than observed problems. Below are the nine high-severity issues that directly shaped the redesign scope.

Issue identified Severity Design response
No progress indicator during KYC — users couldn't tell how many steps remained
High
Stepped progress bar with labelled stages added to all KYC screens
Document requirements listed only at the start — not surfaced at the relevant step
High
Contextual requirements panel shown inline at each document upload step
Error messages on form rejection were generic ("Submission failed") with no recovery path
High
Field-level validation with specific error copy and inline correction guidance
No way to save KYC progress — abandonment lost all entered data
High
Auto-save with draft state — users can return and resume at any point
Access management UI mixed admin controls with operational data — high cognitive load
High
Console redesigned with clear separation: Company settings vs Team management vs Data access
No confirmation or audit trail for permission changes — actions felt irreversible
Medium
Confirmation modals + activity log panel showing all permission changes with timestamps
Onboarding used inconsistent terminology ("Register", "Enrol", "Sign up") across screens
Medium
Terminology audit and standardisation across all onboarding and console copy
Dashboard showed the same data to all roles — no role-based content prioritisation
Medium
Role-aware dashboard: platform admins see company health metrics; client users see their own data
Help content only accessible from a separate help centre link — not contextual
Low
Inline tooltips and contextual help panels added to complex fields and decision points
05
User Personas

Three roles, one platform

The console model introduced a layered user structure that didn't exist in the whitelabel model. Two primary personas represent the most critical design targets — the company admin completing KYC and managing their organisation, and the Bluemeg ops team member managing the console.

SC
Sandra Chen
Head of Operations, SME Client Company
Age 38 · Singapore
Role on platformCompany Admin (Client-side)
Tech comfortModerate — familiar with SaaS
Primary taskKYC completion & team setup
FrequencyOnboarding (once) + periodic admin
Goals
  • Complete company KYC quickly so her team can start using the platform
  • Understand exactly what documents are needed and why, upfront
  • Set up team access levels without needing to contact Bluemeg support
Pain Points
  • Previous KYC process required emailing documents with no visibility on status
  • Had to re-enter all company data when a submission was rejected — no partial save
  • Couldn't delegate KYC tasks to colleagues; everything had to go through her

"We spent two weeks going back and forth on document submission. I just want to see what's needed, upload it, and get started."

RJ
Raj Johari
Client Success Manager, Bluemeg
Age 31 · Singapore
Role on platformPlatform Admin (Internal)
Tech comfortHigh — power user
Primary taskReview KYC submissions, manage access
FrequencyDaily — manages 20–40 client companies
Goals
  • Review and approve KYC submissions without leaving the console
  • See a clear status of all client onboarding in one view
  • Adjust client access levels and permissions quickly when business needs change
Pain Points
  • Currently manages client status across a spreadsheet and email threads
  • No audit trail for permission changes — has to rely on memory for who changed what
  • Every new client requires manual environment setup by the engineering team

"I want to see all my clients, their KYC status, and be able to take action from one place — not chase emails."

06
Job Stories

Designing around situations, not assumptions

Job Stories — "When [situation], I want to [motivation], so I can [outcome]" — were used instead of traditional user stories for the access and permission design, where context of use determines the right interface behaviour far more than user type alone. Below are the six Job Stories that directly drove the most significant design decisions.

1
When a company admin first logs into the platform after registration, I want to see a clear, step-by-step KYC checklist with my current progress, so I can understand exactly what's left to complete without contacting support.
2
When I need to upload a specific compliance document, I want to see the exact format, size, and content requirements for that document before I upload it, so I can prepare the right file and avoid a rejection.
3
When my KYC submission is rejected or needs amendment, I want to see exactly which field or document was the issue and why, so I can fix just that part without restarting the whole submission.
4
When a Bluemeg admin reviews a client's KYC submission, I want to approve, reject, or request amendment with structured feedback from a single screen, so I can process multiple clients without switching between tools.
5
When a company admin needs to add a new team member with a specific access level, I want to select from clearly labelled role templates rather than configure individual permissions, so I can set up access correctly without needing to understand the full permission system.
6
When a Bluemeg platform admin changes access permissions for a client company, I want to see a confirmation summary and have the change logged with a timestamp, so I can maintain an auditable record of all access decisions.
07
Information Architecture

Structuring the console around role clarity

The IA was built from the permission matrix and Job Stories outputs — two distinct navigation structures for platform admins (Bluemeg internal) and client company users, accessed through a role-aware login. The console model required a clear "you are here" architecture at all times: which company context you're in, what your role allows, and how to move between scopes.

Platform Admin View (Bluemeg Internal)
Root
Bluemeg Console
Nav L1
Dashboard
Companies
KYC Review
Access Management
Reports
L2 Pages
All companies
Company profile
KYC queue
Submission review
Request amendment
Role management
Permission templates
Activity log
Onboarding report
Client Company View
Nav L1
Dashboard
Onboarding & KYC
Team Management
Company Settings
L2 Pages
KYC progress
Document upload
KYC status & history
Invite team member
Roles & permissions
Company profile
Billing & plan
Notification settings
08
Final Designs

The platform in action

Seven screens spanning the full console and KYC experience — from the platform admin's sub-console management view through to the client-side KYC submission form and the admin review panel. Together they tell the complete story of the whitelabel-to-console model shift.

Console Management Listing
Platform Admin — Console
Manage Sub-Consoles listing
The top-level console view showing all sub-consoles (tenants) — name, status, number of companies, and user count. Each row is a client environment that previously required a separate deployment. The "Create new Sub-Console" CTA replaced a weeks-long engineering provisioning process.
Create New Sub-Console
Platform Admin — Console
Create new sub-console / tenant
The side panel for provisioning a new client tenant — naming the sub-console, adding a first administrative user, assigning console access, setting the permission group, and sending an invitation email. What previously took an engineering sprint now takes minutes in a structured form.
Company Dashboard with KYC prompt
Client View — Dashboard
Company dashboard with KYC onboarding prompt
The client-side dashboard on first login — a contextual KYC call-to-action ("Please submit your KYC!") with an Upload Documents button surfaced prominently. The todo list below shows active processes with clear next-step CTAs. A notifications panel on the right keeps the user informed of actions taken by other parties. This directly addresses the heuristic finding that KYC was invisible at the dashboard level in the old product.
Console Settings
Client Admin — Settings
Console settings — jurisdiction defaults & onboarding options
The console settings page shows the depth of configurability in the new model — jurisdiction-level defaults (registered address, company secretary), company positions, bulk onboarding via CSV, ACRA integration for Singapore UEN-based onboarding, and company permission group management. All configurable per sub-console without engineering involvement.
Add New Permission Group
Client Admin — Permissions
Add new permission group — granular access matrix
The permission group creation screen — a capability matrix mapping 8 data categories (Company Information, Dates, Shares, Documents, Positions, Integrations, Corporate Actions, Registers) against 4 action types (View, Make Changes, Remove, Add New). This is the power-user layer behind the role templates, for clients who need custom access configurations.
KYC Submission Form
Client View — KYC
KYC submission form — identity, address & compliance declarations
The KYC submission screen for an individual user — covering identity information (HKID), address information, PEP status, UBO declaration, Tax Identification Number, source of funds, and a declaration agreement. Inline contextual explanations for each compliance field (e.g. PEP and UBO definitions) directly address the heuristic finding that complex regulatory terms were previously unexplained.
Admin KYC Review Panel
Platform Admin — KYC Review
Admin KYC review with structured request panel
The admin-side KYC review screen — showing a submitted user's full identity information, uploaded documents, and address details on the left. The "Request KYC" side panel on the right lets admins configure exactly what to re-request: identity documents, address documents, additional compliance information, specific documents, and a message to the user. Replaced the previous freeform email process entirely.
Figma View the full prototype: Bluemeg Dashboard — Figma
09
Key Design Decisions

Translating strategy into interface

◎
KYC as a guided onboarding experience, not a form
The KYC flow was redesigned as a stepped wizard — 6 clearly labelled stages with a persistent progress bar, a left-nav showing all stages at once, and contextual document requirement panels at each upload step. Auto-save was implemented at every stage so partial completion could be resumed. The result: KYC felt like product onboarding, not a compliance burden.
◈
Console with explicit company context switching
Platform admins managing multiple client companies needed absolute clarity about which company context they were operating in. Designed a persistent company context banner at the top of every console screen — always visible, always showing the active company, always one click from switching. No ambiguity about whose data you're looking at or acting on.
◐
Role templates over raw permission configuration
Rather than exposing the full permission matrix to client admins (which produced confusion in testing), we designed a role template system: 4 pre-configured role types (Owner, Admin, Editor, Viewer) with a clear capability comparison table. Power users could still configure custom permissions, but the template path covered 90% of use cases with a fraction of the cognitive load.
◇
Structured amendment requests in the KYC review console
When a Bluemeg admin needed to reject or request changes to a KYC submission, the old process was a freeform email. The redesign replaced this with a structured amendment panel: select the specific field or document, choose a reason from a validated list, add optional notes. The structured format ensured clients received actionable, unambiguous feedback — and created a machine-readable audit trail.
▣
Shared component system across the 4-person design team
With 3 designers working in parallel on distinct modules, component drift was the biggest quality risk. Established a shared Figma component library as the first deliverable — before any screen work began. Weekly critique sessions with a "component health" check ensured nothing diverged. By the time screens were in development, the UI was already consistent — the FE developer never had to resolve design conflicts.
10
Research Findings

What testing confirmed — and what it changed

9/9
High-severity issues resolved
All 9 high-severity issues from the heuristic evaluation were resolved and confirmed by the post-design usability test. The issues register was used as a direct test script.
83%
KYC completion rate
In testing, 83% of participants completed the full KYC flow in a single session — compared to the multi-week, multi-email process in the old model that had significant abandonment.
4/4
Role template adoption
All 4 client admin participants used the role template system rather than custom permission configuration — validating the design decision to lead with templates over raw permission controls.
–30%
Burn rate reduction
Post-launch business metric: operational burn rate reduced by 30% within the first quarter — driven primarily by the elimination of per-client environment setup and manual KYC processing.
6/8
Context switch clarity
6 out of 8 participants correctly identified which company context they were in during a multi-company admin scenario — a task that was impossible to complete correctly in the old whitelabel model.
100%
Amendment action clarity
All Bluemeg internal participants successfully submitted a structured KYC amendment request without guidance — the structured panel replaced what had been a freeform email process with no consistency.
11
Outcomes & Impact

A leaner product and a healthier business

The console model redesign delivered measurable impact on both the product experience and the business fundamentals. Onboarding a new client shifted from a weeks-long engineering project to a self-serve flow completable in hours. The centralised KYC review console eliminated the email-based review process entirely. And the shared component system gave the engineering team a stable, predictable UI foundation to build on.

–30%
Reduction in operational burn rate within Q1 post-launch
83%
KYC completion rate in a single session during usability testing
9/9
High-severity heuristic issues confirmed resolved post-redesign

Beyond the metrics, the redesign proved the business case for the console model — demonstrating that the right product architecture, paired with good UX, could reduce operational costs while improving the client experience simultaneously. The console became the foundation all subsequent Bluemeg product development was built on.

12
Reflections & Learnings

What leading a team taught me that solo work couldn't

→
Start with the heuristic audit, not the redesign. The single most valuable thing we did was spend the first week documenting what was already broken before proposing anything new. It gave the team a shared understanding of the problem, gave the business a concrete list of what the redesign needed to fix, and gave testing a clear success criteria from day one.
→
Job Stories outperformed user stories for permission design. User stories ("As an admin, I want to manage permissions") were too abstract for the nuanced decisions around access control. Job Stories — anchored in specific situations — produced much more actionable design requirements and prevented a lot of edge case oversights that would have surfaced in development.
→
The component library is team infrastructure, not a design nice-to-have. Delaying component work to move faster on screens is a false economy with a 3-person design team. Every day we spent without a shared component system was a day creating future inconsistency debt. Building it first — even though it felt slow — was the reason the final product felt coherent.
→
Design critique requires structure at team scale. Informal feedback ("looks good") doesn't scale beyond one designer. We introduced a structured critique format — each designer presents against the Job Story and heuristic criteria, not personal preference — which dramatically improved the quality of feedback and reduced the revision cycles on handoff screens.
→
If I were to revisit: I'd invest more research time into the console mental model for first-time platform admins. The multi-tenancy concept — managing clients as tenants within a shared environment — was genuinely novel for our internal ops team, and more structured onboarding for the admin console itself would have reduced the support load in the weeks after launch.
Trazzeo — AI Travel Planner
All work Bikemess — LBS Directory