How design created impact beyond screens at DBS

TLDR

Insight Direct is DBS’s investment research portal, think something in the same space as MarketWatch or TradingView, but built for both retail investors and institutional clients. The brief came in as a reskin. The product and business team had low UX and product maturity, no clear direction on what to build, and almost no user data to work from.

The screens changed, but that’s not really what this story is about. This is about the decisions behind the screens: how a low-maturity team learned to build differently, and what made an ambiguous, thinly-resourced project survivable in the first place.

The bit nobody puts in a case study

“Just make it look like the new design system, right?”

That was more or less the brief when this project landed. On paper, it was a reskin. In practice, there was no clear direction on what to build, the team had little UX or product maturity, and there wasn’t enough user data to argue from evidence. The kind of project where, if you take the brief literally, you ship a slightly nicer version of the same problems.

A case study can show you the before-and-after screens and the 29% lift in visits. What it can’t show you is that none of that was really about the screens. It was about a handful of unglamorous decisions, made early, about how the team would work together. Here’s what those were.

Teaching UX without calling it UX

The team hadn’t worked with a strong design practice before, and jargon is the fastest way to lose a room that already feels behind. So the goal wasn’t to introduce “the UX process,” it was to get people doing the thinking without naming it. Sketching a flow together instead of presenting one. Asking “what happens if a user gets here with no context” instead of “let’s do a heuristic review.” The label never came up. The practice did.

Turning the PRD into a live conversation

PRDs at this stage tend to be something design writes and product signs off on, then nobody opens again. Instead, we ran the PRD sessions live, with product owners in the room, working through real examples together. That changed what the document was. It stopped being a record of a decision someone else made, and became the place where the decision actually got made. That’s a small shift on paper and a large one in practice, because it’s the difference between a team that owns a plan and a team that’s been handed one.

Framing research as risk reduction, not proof

There wasn’t enough data to prove anything, and waiting for enough data would have meant not shipping. So the framing shifted: research wasn’t there to prove we were right, it was there to reduce the risk of being badly wrong. That gave us permission to move on what we could validate quickly, in small increments, rather than stalling on the things we couldn’t yet know. It’s a subtle reframe, but it’s the difference between “we don’t have enough evidence to proceed” and “here’s what we can check before Friday.”

Bringing leadership in early, on purpose

We kept a rolling product deck and used it to bring leadership into the thinking early, not just at review gates. That did two things: it built trust, because leadership could see the reasoning as it developed instead of a finished decision dropped on their desk. And it sped things up, because disagreements surfaced while they were still cheap to resolve, not after three sprints of work.

Shipping the MVP next to the bigger vision

Alongside the MVP, we put together an ideal-state vision of where the product could go. Shipping the MVP proved the direction worked. Showing the vision next to it gave leadership something to get excited about, which is what actually opened the door to further investment and a second designer on the team.

What this made possible

None of this guarantees a specific number. What it did was turn a project that could easily have stalled, low maturity, no brief, thin data, into one that moved. The information architecture and design system work landed on top of that foundation: a 29% increase in visits, and enough leadership confidence to greenlight MVP 2 and fund another designer. I’d argue the second part is harder to build and easier to overlook than the first.

Why this matters more than it looks like it should

Most enterprise design work happens in exactly this kind of fog: unclear briefs, teams still learning what design even does, and not enough data to lean on. The instinct in that situation is to wait for clarity before moving. What actually works is closer to the opposite: create small, cheap ways to learn, bring people into the thinking early, and let the plan get built by the room instead of handed to it.

If there’s one thing I’d want a reader to take from this, it’s that design impact in ambiguous environments rarely comes from a better research method. It comes from how you lead people through the ambiguity while you’re still in it.