Design that earns
trust, not just attention.

The problem, in plain terms

The existing account opening process was built around a physical clipboard. Literally, the first thing a client encountered was a multi-section paper form asking for owner details, SSNs, joint owner information, entity type, trustee data, and corporate registration details, all at once. No sequencing. No context. No indication of what came next.

The process was fragmented and manual, and it lacked transparency. Clients were asked for repetitive data at multiple touchpoints because there was no single system of record. A relationship manager might collect information on one call, only for the ops team to request the same information again via a different form. Trust eroded before the account was even open.

What we set out to do

The approach was to replace fragmented, repetitive steps with a single digital journey. Our core design principles going in: collect data once, show progress clearly, and never ask a user for something the system already knows.

We followed a three-phase process, Discover, Define, Design, with research embedded into each phase rather than front-loaded and forgotten.

The five screens that changed the process

• Dashboard, the control centre, Rather than dropping users into a blank form, we designed a portal homepage that showed everything at once: active requests with real-time status tags (Ready for Funding, Additional Details Needed, Drafted, Awaiting Approval), a contextual FAQ, a helpline number, and a clear "Open an Account" CTA. The status tags were the key decision, clients had previously had no visibility into where their application stood after submission. That opacity created support call volume. Making status visible reduced it.
• Entity Selection, reuse before re-entering, One of the biggest sources of repetitive data entry was that the system didn't recognise existing entities. Every new account required re-entering information the bank already held. We designed an entity selection screen, a searchable table of all existing legal entities (Corporations, Trusts, Individuals), so clients could select and reuse without retyping. "Create New Legal Entity" was there too, but it was the second option, not the first.
• Entity Setup Form, structure as cognitive relief, The single-page paper form became a 6-step horizontal wizard: Legal Entity Details → Add Parties → Upload Documents → Account Details → Add Features & Services → Review & Sign. Each step had one clear job. The contextual "Required Documents" panel, visible at all times in the right rail, meant users always knew what they'd need to upload before they got there, removing the most common source of mid-form abandonment.
• Add Features & Services, progressive disclosure for complex options, Custody account features (Cash Sweep, Tax Accounting Parameters, Reporting Parameters) and add-on services (Performance Reporting & Analytics, Data Feeds) were presented as an accordion, collapsed by default, expanded on demand. Users who needed simple accounts weren't overwhelmed by options. Users who needed complex configurations had them available without hunting.
• Confirmation, closing the loop, The final screen did something the paper process never did: it confirmed. A named success state ("Thank you, John!"), a confirmation number, a clear explanation of next steps (documents sent for e-signature), and two forward paths, Go to Dashboard or Open New Account. Not a dead end. A beginning.

Constraints that shaped the decisions

• Regulatory requirements, Certain data fields, SSNs, entity tax IDs, legal addresses, were mandated at specific points in the flow by compliance and KYC regulations. We couldn't remove or reorder them. We could only frame them better and contextualise why they were needed.
• Existing data architecture, The entity reuse model required the backend to surface existing client records in real time. This was a significant engineering lift that almost got descoped. I made the case that without it, we'd have digitalised the paper form without fixing the core problem, repetitive data entry.
• Multiple user types in one flow, The same portal served individual account holders, corporate treasurers setting up entities, and relationship managers acting on behalf of clients. The UI had to be navigable without role-specific training, which pushed us toward explicit labelling and progressive disclosure over assumed familiarity.

The decision I'm most proud of

The status tags on the dashboard. They seem simple, a coloured label next to a request. But they represented a fundamental shift in how the bank communicated with clients during a process that could take days or weeks.

The original process had no equivalent. A client submitted their paperwork and then waited, with no signal of what was happening on the other side. The tags, "Ready for Funding," "Additional Details Needed," "Awaiting Approval", gave clients agency. They knew what to do next without calling their relationship manager. Transparency reduced anxiety and support volume simultaneously.

What I'd do differently

The "Add Parties" step (step 2 in the wizard) was the one we had the least time to research properly. Adding co-signatories and authorised parties to an account is a genuinely complex operation with a lot of edge cases, joint accounts, trustees, corporate signatories, and I think we oversimplified it in the first release.

I'd also have pushed for a mobile-responsive version earlier. The portal was desktop-first, which was the right priority for the primary use context. But relationship managers sometimes needed to walk clients through the process on-site, on a tablet, and the experience wasn't optimised for that scenario.

What the product actually does

The platform has two core modules. The first, Manage Template Wording, lets engagement leads configure which sections, subsections, and topics are active for a given Financial Due Diligence project. Content is organised in a three-level hierarchy: Section → Subsection → Topic. Each topic contains pre-written template language that populates the eventual report.

The second, Instant Insights, is an AI layer. When client documents are ingested into the platform, the system generates insights mapped to each section of the engagement. Analysts can review, refresh, and export these AI-generated outputs as a starting point for their work.

The problem was not that the features didn't work. It was that the interface didn't match how analysts actually thought during a live engagement. They needed to move quickly, make targeted changes, and trust that the system would confirm exactly what they'd done, not guess.

The flows I was asked to design

• Manage Structure, Discard flow, When an analyst selects a Section and clicks "Discard," the system needs to communicate clearly that all nested subsections and topics will be removed, not just the section label. We designed a confirmation modal that lists every affected item explicitly before the user commits. After confirmation, the tree view clears and a toast notification closes the loop. The empty state ("No selection made") is not a failure state, it's a clean slate. We designed it to feel intentional, not broken.
• Disable/Enable topic flow, Analysts frequently need to exclude specific topics from a report without permanently deleting them, a topic relevant to one client may not be relevant to another. We designed a Disable action at the topic level: the user selects the topic, clicks Disable, confirms via modal (which repeats the full Section → Subsection → Template Name hierarchy so there's no ambiguity), and receives a toast confirmation. The disabled topic gets a closed-eye icon in the tree, visible, scannable, reversible. Clicking Enable restores it instantly.
• Instant Insights, Refresh flow, When client documents are re-ingested, the existing AI insights become stale. The system surfaces this with red tick indicators next to every affected section and a banner prompt: "Documents have been re-ingested. Refresh insights to see the updated results." The analyst clicks "Refresh Insights," reviews a checklist of all sections requiring update, confirms, and the hierarchy updates to a clean refreshed state. Every step is explicit, analysts working on client-facing deliverables cannot afford silent background updates.

The design decisions that mattered

• Show the full hierarchy before every destructive action, Both the Discard and Disable modals repeat the full Section → Subsection → Topic path. This felt redundant in early reviews. It wasn't. Analysts managing large engagement templates often lose track of nesting depth. Showing the full path in the confirmation modal meant they could verify they were acting on the right item, without navigating back to check.
• Visual state for disabled topics, The closed-eye icon was a deliberate choice over a greyed-out label or strikethrough. It communicates "hidden from output" rather than "deleted" or "unavailable", which is exactly the mental model we needed to support. Analysts needed to know disabled topics still existed and could be re-enabled.
• Red tick vs. orange warning, The pending-refresh indicator used red ticks rather than orange warnings. Red ticks were chosen because the staleness wasn't an error, it was expected after a document re-ingestion. Orange would have communicated "something is wrong." Red ticks communicated "something needs your attention." The distinction mattered to how analysts responded to the signal.
• Refresh as a deliberate, confirmable action, We could have made insight refresh automatic. We chose not to. Analysts need to control when AI-generated content changes in a live engagement, refreshing mid-review would invalidate annotations and notes already made against the old output. The manual confirm step wasn't friction. It was respect for the analyst's workflow.

Constraints that shaped the work

• Existing data model was fixed, The three-level hierarchy (Section → Subsection → Topic) was baked into the backend. We couldn't flatten it or restructure it. Every UX decision had to work within that model.
• AI outputs are imperfect by design, The Instant Insights module carries a visible disclaimer: "AI-generated output may contain inaccuracies or errors. Verify output before use." The UI had to convey the utility of the AI layer without overstating its reliability. Analysts are trained to be sceptical, the design had to earn their engagement, not assume it.
• No room for ambiguity, This tool operates on client engagements with legal and financial consequences. A wrong discard, a missed refresh, a misread status indicator, any of these could create problems downstream. Every interaction needed to be explicit, confirmable, and reversible where possible.

What I'd do differently

The Instant Insights module was designed primarily around a single user action, Refresh. But in practice, analysts also needed to understand why a section had a red tick, which document re-ingestion triggered the staleness signal. That context wasn't surfaced. I'd advocate for a change log or ingestion history view that let analysts trace exactly what changed and why, before deciding whether to refresh.

I'd also explore whether the three-level hierarchy is the right default navigation model for large engagements. Once a template has 40+ topics across 8 sections, the tree view becomes unwieldy. A search or filter layer on top of the tree would meaningfully reduce time-to-action for experienced analysts.

Why I did this

I was preparing for a fintech project and wanted to stress-test my own assumptions about what good banking UX actually looks like in practice. The fastest way I know to recalibrate is to pick something acclaimed and look hard for where it fails.

DBS was the obvious subject, consistently ranked Asia's best digital bank, widely cited as a UX benchmark in fintech circles. I expected minor issues at the edges. I found 11 distinct friction points, four of which were significant enough that users had built deliberate workarounds, meaning the problems were chronic, not incidental.

What the audit found

• Navigation frequency mismatch, The homepage surfaced products users opened annually (insurance, investments). Most-used functions, balance check, domestic transfer, were 2–3 taps deep. Frequency and prominence were inverted.
• Confirmation logic applied backwards, Some high-stakes actions (large transfers) had one confirmation step. Some low-stakes actions (downloading a statement) required two. The logic for confirmation depth was inconsistent and unpredictable.
• Error messages that withheld diagnosis, "Invalid input" was the most common error pattern. The system knew why it failed, the API returns error codes, but the UI chose not to surface that information. Users had no recovery path other than trial and error.
• Zero feature discovery surface, Three genuinely useful features were only findable by searching externally. They existed in the app; there was no path to them for a user who didn't already know they were there.
• Onboarding that assumed familiarity, New users received the same home screen as tenured users, with no progressive introduction to the feature set. The learning curve was invisible, and entirely the user's problem to solve.

The discipline I imposed on myself

I produced redesign proposals for three of the eleven issues, specifically those where I had high confidence in the problem diagnosis and low ambiguity about the solution direction. For the remaining eight, I documented the problem clearly and noted what additional research would be needed before proposing anything.

Too many UX audits produce recommendations for problems they haven't fully understood. I'd rather write "needs further research" than ship a plausible-looking solution that misses the actual root cause.

What this project became

The audit directly informed my approach to the banking redesign, particularly around confirmation flow logic, error message architecture, and the decision to treat trust-signal placement as a structural UX problem rather than a copy problem.

Self-initiated work isn't in a portfolio because it's filler. It's there because it shows how a designer thinks when nobody is watching and there's no brief to hide behind.

Why this is a UX project

Physical wayfinding borrows the same frameworks digital UX does: progressive disclosure, consistent nomenclature, error recovery, information hierarchy, and designing for the user's actual cognitive state, not their ideal one. But it adds constraints that digital work rarely faces.

There is no iteration post-installation. A sign commissioned and installed is committed. You cannot push an update to a lightbox at Gate 14. Every decision was a one-shot commit, and that changed how I approached the entire process.

What I brought from digital practice

The biggest contribution I made to this project wasn't visual, it was insisting on a passenger journey map before any design work began. The airport operations team thought in terms of zones and infrastructure. I mapped the experience from the passenger's perspective: landside arrival → check-in → security → departures → gate, with every branching decision marked as a potential failure point.

That map caught three gaps in the initial sign placement plan before a single unit was commissioned, positions where a passenger following correct instructions would have had no visual confirmation they were on the right path.

Key design decisions

• Language hierarchy varied by zone type, Goa's terminal serves domestic and international passengers with different primary languages. We tested three hierarchy configurations. The optimal arrangement differed between arrivals and departures, different audiences, different stress profiles, different navigation needs.
• Capped icon vocabulary at 12, We could have designed bespoke icons for every amenity. We chose not to. Twelve universal symbols, consistently applied, outperforms thirty novel ones users have to decode before they can navigate.
• Recovery paths built in at every node, Every sign cluster included a recovery path for a passenger who missed their turn. The design question wasn't just "where are you going", it was "what happens when someone doesn't follow these instructions."
• Decision-point concentration, not even distribution, Rather than distributing signage evenly across the terminal, we concentrated it at decision nodes, junctions, escalators, split corridors, and reduced it in clear-path sections where confirmation, not direction, was the need.

The collaboration dynamic

Sign positioning required sign-off from structural engineers, lighting designers, and airport operations, all with competing priorities. My job was to keep the passenger's perspective in the room when it wasn't commercially convenient to do so. In physical service design, that advocacy role is as important as the visual craft.