Vrinda Bhagat

Designing for how teams think and work

Category: Design Thinking

  • Case Story: Day One Was Fine. Day Thirty Was the Problem.

    Client: Prime Quadrant, a Canadian wealth management firm

    Role: Design Thinking Consultant

    Timeline: April 2026 – May 2026

    Scope: Redesigning end-to-end onboarding experience across a 90-day (new) employee journey

    Firm Scale: ~200+ employees | Privately-owned | High-net-worth client base

    ,

    The Spreadsheet Dressed Up as an Experience

    A Canadian wealth management firm managing private financial data for high-net-worth families was growing fast. New people were joining every month across different teams, and the L&D team was keeping up the only way they knew how — manually, one new joiner at a time.

    The onboarding process lived in Asana. Not as a journey, not as a learning experience — as a task list organized by week. Every new employee was assigned to the same project and expected to work through it. Some tasks linked out to a website. Some pointed to long PDFs. Some were buried in SharePoint folders that were hard to find. Some didn’t explain why they mattered. There was no logic about what you needed to know first, or what could wait until week three, or what was only relevant to you if you worked in finance versus technology. It was a checklist. Finish the list, you’re done.

    The problem was that completing the tasks didn’t mean you were equipped to be successful in your new role. Employees were working through the list and still not knowing how departments connected, what tools they were actually supposed to use, or where to find answers when something came up on the job. And when they didn’t know, they asked the L&D manager. Every time.

    The firm had grown to a point where that wasn’t sustainable. Hiring hadn’t slowed down. The L&D team was drowning in operational work — not designing experiences, not improving them, just managing the churn of assigning the same task list to the next person who showed up.

    That’s when they brought me in.


    Starting With the Journey, Not the Content

    When I came on as an external consultant, the first thing I did was resist the pull toward content. The easier path would have been to start reorganizing what already existed — tidying up the task list, shortening the documents. That’s not where I started.

    The right starting point was the journey itself. Working closely with the L&D manager, I set out to understand what onboarding actually needed to look like — how people, processes, and technology were interacting for someone new to the firm. What did employees need to know on day one? What could wait until day seven, day thirty, day ninety? What was critical to feel oriented versus what was just noise?

    The onboarding had been designed around what the L&D team needed to deliver, not around what the employee needed to receive. Those are different problems. One is a compliance and operations problem. The other is an experience problem. I was there to solve the second one — which meant mapping the journey before touching a single piece of content.


    Common Sense Isn’t Always Common

    The discovery process involved employee surveys, one-on-one interviews, and a need gap analysis — mapping what employees were encountering against what the onboarding was providing.

    The finding that stuck with me most was about mental models. Things that seemed obvious to someone who’d been at the firm for two years were genuine blockers for someone in their first week. Not because those people weren’t capable — but because nobody had made the implicit explicit.

    Three things kept coming up. First, the onboarding wasn’t self-serve — employees depended on the L&D manager to answer questions, which meant any spike in hiring or a day she was unavailable created a real bottleneck. Second, not everyone was familiar with Asana. Training formatted as a project management task list made sense to some people and none at all to others. And third, several tasks in the list were literally raw email copies — an email thread pasted into a task description, with no explanation of what the employee was supposed to do with it. Read it? Action it? Sign something? Nobody knew.

    The training wasn’t scattered because anyone was careless. It was scattered because it had grown organically across tools, and nobody had ever stepped back to look at it as an experience end to end.

    That shaped a lot of what came after. Good UX writing, clear signage, and directional cues throughout — not as decoration, but as orientation. The onboarding had to do the work of saying: here’s where you are, here’s what matters right now, here’s what comes next.


    Fifty Tools and No Map

    One of the more concrete problems the discovery surfaced was around technology. The firm used over 50 software tools. Nobody had defined which ones were relevant to which roles.

    That meant a new employee joining as a project manager was looking at the same tool list as someone joining as a financial analyst — without any indication of which five tools they needed to start using on Monday.

    I used card sorting to build the information architecture from scratch. Rather than presenting a flat list of everything, we organized content into logical buckets: HR and employee benefits, IT and tools, department functions, compliance and mandatory training. From there, we created role-based technology pathways — so employees only encountered the tools relevant to their function, introduced at a point in the journey where they had enough context to actually use them.

    One decision that came out of that session shaped the whole technology section: we agreed that only org-wide tools belonged in the onboarding experience. The full list of 50-plus tools was real, but it wasn’t everyone’s problem on day one. Team-specific and role-specific tools would come later, introduced through their own channels once employees had enough context to use them. Starting with what was universal kept the experience grounded without making it feel incomplete.

    It sounds straightforward in hindsight. But it required working closely with the L&D manager throughout — because I wasn’t a subject matter expert on this firm’s compliance requirements or internal culture. She knew which information was genuinely mandatory versus historically accumulated. Getting that right together was one of the more careful parts of the work.


    Building the Journey in Phases

    The structural centerpiece of the redesigned experience was the phased journey. Day one. Day thirty. Day sixty. End of the three-month probation period.

    Each phase had a different purpose. Day one was about orientation — not overwhelming the employee, but giving them enough to feel grounded. By day thirty, they should know how the organization works and be starting to deliver in their role. By day sixty, their comfort level should be increasing alongside their responsibilities. By the end of probation, they should be self-sufficient — and in a position to become a resource for people who joined after them.

    This was a deliberate departure from the task list model. The old approach expected employees to consume everything as fast as possible. The new one was designed around how people actually learn — progressively, with time to absorb and apply before the next layer comes in.

    One early question was whether to bundle compliance and cybersecurity training into the onboarding experience itself. We decided against it. Compliance is a substantial topic in its own right — it involves legal steps, liability sign-offs, and formal requirements that deserve focused attention, not a slot in week one between “meet the team” and “here’s how expenses work.” On top of that, the firm’s Canadian and US employees had different compliance mandates, which meant any bundled approach would have required branching logic that quickly became unmanageable. Keeping compliance separate wasn’t a workaround — it was the cleaner solution.

    We built the experience in Litmos, a learning management system. Litmos is not the most intuitive tool to work in — it took me about two weeks of tutorials and trial-and-error before I felt comfortable using it. But it gave us what we needed: the ability to sequence content, track completion across the 90-day window, and send automated reminders so employees could see where they were in the journey without the L&D manager having to follow up individually.

    We also developed a simple visual design system within the platform — a consistent color code for call-to-action items, and a separate one for critical information. Nothing elaborate, but it gave employees visual cues about what required action versus what was reference material.


    What Fewer Questions Tells You

    The clearest signal that something had changed was this: the L&D manager stopped fielding as many clarifying questions.

    That might sound like a small thing. It wasn’t. Before the redesign, employees were regularly coming back to her to ask things the onboarding was supposed to answer. Where’s the policy on this? Which tool do I use for that? Who do I talk to about benefits? Those questions were a symptom of an experience that wasn’t doing its job.

    After the rollout, employees could find what they were looking for within the training itself. They knew the journey was structured — that they weren’t expected to know everything on day one, that there was a pathway, and that answers existed somewhere they could access on their own. That shift from dependency to self-sufficiency was exactly what the L&D manager had been hoping for. It also meant she could get back to the work she was hired to do.


    What I Carry Forward

    Most design projects start with content. This one confirmed why that’s often the wrong place to start.

    On this project, the sequence was reversed — information architecture first, then layout, then content. The content itself was never really the problem; it existed, it was specific, and it was largely accurate. The challenge was how to present it so it would actually land. Once the IA defined the flow — what comes first, what comes second, how the stages connect — the layout followed. And the layout shaped how the content sat in the learner’s mind.

    That’s the thing I carry forward: packaging is part of the experience. The same information written as a long paragraph and sent in an email lands very differently than the same information broken into visual blocks, sequenced deliberately, and delivered in chunks sized for how adults actually learn. The way something is delivered determines whether it gets absorbed or ignored. For anyone designing employee learning experiences, that’s not a production detail — it’s a design decision.


    External consultant | ~200-employee Canadian wealth management firm | Redesigned onboarding across a 90-day employee journey

  • The Checklist Was Done. The Employee Wasn’t.

    Client: Prime Quadrant; a Canadian wealth management firm

    Role: Design Thinking Consultant

    Timeline: April 2026 – May 2026

    Scope: Redesigning end-to-end onboarding experience across a 90-day (new) employee journey

    Firm Scale: ~200+ employees | Privately-owned | High-net-worth client base

    ,

    THE PROBLEM

    A Task List Isn’t an Experience

    A Canadian wealth management firm was hiring continuously — new people joining every month across different teams — and their onboarding hadn’t kept up. The process lived in Asana as a task list organized by week. Each new employee was assigned to the same project and expected to work through it: long PDFs, links buried in SharePoint, email threads pasted into task descriptions with no explanation of what to do with them.

    Completing the tasks didn’t mean you were equipped to be successful in your new role. Employees were finishing the list and still not knowing how departments connected, which tools were actually relevant to their function, or where to find answers when something came up on the job. When they didn’t know, they asked the L&D manager. Every time. With hiring showing no signs of slowing, that wasn’t sustainable.


    THE APPROACH

    Journey First. Content Second.

    I came on as an external consultant and started where most L&D projects don’t — with the journey, not the content. Working closely with the L&D manager, I mapped what onboarding actually needed to look like: what employees needed to know on day one, day seven, day thirty, and day ninety. What was critical to feel oriented. What was just noise.

    Discovery involved employee surveys, one-on-one interviews, and a need gap analysis. The finding that shaped everything: the onboarding wasn’t self-serve. Employees depended on the L&D manager for answers, the training was scattered across tools with no integrated experience, and several tasks were literally raw email copies — no instructions, no context, no clear action required.

    From there, I used card sorting to build the information architecture. Content was organized into logical buckets — HR and benefits, IT and tools, department functions, compliance — so employees encountered information in an order that made sense rather than a flat list of everything at once. One key decision: only org-wide tools belonged in the onboarding experience. Role-specific tools would be introduced later, once employees had enough context to use them.

    Compliance and cybersecurity training stayed separate entirely. Bundling them into onboarding would have added significant cognitive load to an already dense first period — and the firm’s Canadian and US employees had different compliance mandates, which made any bundled approach difficult to manage. Cleaner to keep them as their own experience.

    The redesigned journey was structured in phases — day one, day thirty, day sixty, end of the three-month probation period — built in Litmos with a simple visual design system: one color for call-to-action items, another for critical information. Employees weren’t expected to finish everything on day one. The journey told them what mattered now, and what could come later.


    THE OUTCOME

    Fewer Questions. More Self-Sufficiency.

    The clearest signal: the L&D manager stopped fielding as many clarifying questions. Employees could find what they were looking for within the training itself — they knew the journey was structured, that answers existed somewhere they could access on their own, and that they weren’t expected to know everything immediately. The shift from dependency to self-sufficiency was exactly what the organization had been hoping for. It also freed the L&D manager to get back to the work she was hired to do.


    WHAT I CARRY FORWARD

    Packaging Is a Design Decision

    On this project, the sequence was reversed from how most design work runs — information architecture first, then layout, then content. The content itself was never the problem; it existed, it was specific, it was largely accurate. The challenge was how to present it so it would land. The same information written as a paragraph and sent in an email lands very differently than the same content broken into visual blocks, sequenced deliberately, and sized for how adults learn. The way something is delivered determines whether it gets absorbed or ignored. That’s not a production detail. It’s a design decision.


    Read the full case story →

  • Reimagining a $1.1B Public Service From the Inside Out

    Client: Government of Alberta
    Program: Persons with Developmental Disabilities (PDD)
    Role: Service Designer
    Timeline: June 2023 – November 2024
    Program Scale: $1.1B annual funding | ~13,000 Albertans

    , ,

    Caseworkers meeting clients at coffee shops and public spaces, pen and paper in hand — no way to share a form on a screen, no branching logic, the same information collected over and over because the system wasn’t built to remember.

    THE PROBLEM

    The Question Nobody Could Agree On

    That was the reality behind Alberta’s $1.1B PDD program, a service supporting roughly 13,000 people. It wasn’t broken in any dramatic sense — it was doing its job, at real cost to the people running it and the people who needed it most. Early on, a policy question stopped the room cold: should every applicant get the full Assessment of Needs, or should the process screen people out earlier to protect stretched caseworker capacity? Leadership was genuinely split — not posturing, a real disagreement about what the program owed people. It wasn’t a UX debate. It was a values question with real operational consequences, and no wireframe was going to resolve it.

    THE APPROACH

    Building the Mirror

    Service design, done right, doesn’t stop at the end user — it looks at the whole ecosystem, including the people delivering the service. So instead of jumping to a fix, I built a service blueprint mapping the program end-to-end: every touchpoint, every handoff, every place a policy created a downstream problem. It wasn’t a pretty document. It was a mirror — and what it reflected back to leadership was often uncomfortable: processes nobody had questioned, gaps everyone had quietly normalized. That blueprint became the foundation for every conversation after it. When we got to redesigning the Assessment of Needs form itself, we didn’t validate a prototype with caseworkers — we went to them first, to co-create the logic and flow before a form even existed. They carried the edge cases and exceptions no policy document captured. Because they helped build it, they were invested in it — and that matters more than most teams realize.

    THE TURNING POINT

    Five Days, One Real Question

    The clearest turning point was a five-day MVP planning workshop, run across three phases — discovery with caseworkers, planning with the delivery team, alignment with leadership. We came in with a question, not an answer: what problem were we actually solving, and for whom? What came out the other side was alignment — a shared, committed scope, with clear lines around what was in, what was out, and why.

    THE OUTCOME

    What Changed

    The MVP launched within eighteen months. Two foundational tools — a digital, branching Assessment of Needs, and CIMS, a case management system built around how caseworkers actually work — replaced two fragmented legacy systems. The roadmap stopped being a wish list and became a plan.

    WHAT I’D DO AGAIN

    Clarity, Not Speed

    What I’d do differently: co-create earlier, and hold the line on discovery even harder. The builder is rarely the user — skip that step, and you don’t just build the wrong thing, you build it with confidence. Transformation isn’t a technology problem. It’s a clarity problem. That’s exactly what service design, done well, is built to create.


    Facilitated 12+ workshops | Engaged 15+ frontline caseworkers | MVP delivered within 18 months

  • Case Story: Reimagining a $1.1B Public Service From the Inside Out

    Client: Government of Alberta 

    Program: Persons with Developmental Disabilities (PDD) 

    Role: Service Designer

    Timeline: June 2023 – November 2024 

    Program Scale: $1.1B annual funding | ~13,000 Albertans


    Understanding the ecosystem

    Before I could redesign anything, I had to understand what I was dealing with.

    What I found was a service that had grown, layer by layer, over decades — held together by age-old forms, manual data entry, and caseworkers meeting clients at coffee shops and public spaces because there was no other option.

    Caseworkers conducting assessments in person, pen and paper in hand, no way to share a form on a screen, no branching logic to skip irrelevant questions — just the same information, collected over and over, because the system wasn’t built to remember.

    This was the PDD program — a $1.1B annual initiative supporting approximately 13,000 Albertans with developmental disabilities. It wasn’t broken in the dramatic sense. It was doing its job. But it was doing so in a way that put enormous pressure on the people running it and made it even harder for those who needed it most.

    My job was to help change that — not by digitizing what already existed, but by understanding why it existed.

    Before I dive into the project, it’s worth naming something that shaped my approach to it.

    Service design doesn’t stop at the end user. It looks at the whole ecosystem — including the people delivering the service. In this project, those people were the caseworkers — and they weren’t a support function sitting behind the scenes. They were part of creating the experience itself.

    A caseworker’s broken tools aren’t an isolated problem — they show up downstream, in the experience of the person on the other end of that interaction. And when that experience improves, the experience changes for the citizen, too, even if they never see why.

    This is the distinction I keep coming back to. UX design optimizes what someone sees on a screen. Service design looks at the entire landscape — every touchpoint, frontstage and backstage — because they’re connected, whether we design for that connection or not. And for a public service like this one, that connection matters beyond the program itself: trust in government is built, or worn down, by whether services work for the people who depend on them.


    The Question Nobody Could Agree On

    Early in the project, a policy tension surfaced that stopped the room.

    By policy, every person applying for PDD support was entitled to a full Assessment of Needs — a deep, structured questionnaire designed to understand what kind of support they required. The problem? That assessment was adding significant load to already stretched caseworkers.

    Leadership was split. One side argued for a more efficient eligibility filter — screen people out early before committing to a full assessment. The other side held firm: every person deserved the full assessment, regardless.

    This wasn’t a UX debate. It was a values question with real operational consequences — and it couldn’t be resolved with a wireframe. What it needed was clarity about what the policy was actually trying to achieve, who it was designed to protect, and what the downstream impact of each path would look like.

    That’s what service design is for.


    Artifacts Before Answers

    The pressure to move fast was real. The technology team wanted to get building — understandably. But I pushed back — and the service design team held that line. Not to slow things down, but to make sure what was built solved the right problem.

    I’ve learned — sometimes the hard way — that jumping to solutions before a team has a shared understanding of the problem is one of the most expensive mistakes you can make in a transformation project.

    The first thing I built was a service blueprint that mapped the PDD service end-to-end: every touchpoint, every system dependency, every place where a caseworker had to leave one tool and pick up another, every spot where a policy created a downstream operational problem.

    It wasn’t a pretty document. It was a mirror — and what it reflected back to leadership, business teams, and the delivery team was often uncomfortable. Processes that had never been questioned. Gaps that had been normalized. Duplication that everyone assumed someone else was responsible for.

    That blueprint became the foundation for every conversation that followed.


    Co-Designing With the People Who Know

    The Assessment of Needs redesign was where things got concrete.

    The form was a product of its time — fixed, linear, no conditional logic, no way to skip irrelevant sections. Caseworkers were manually re-entering data that had already been collected elsewhere. And until recently, a digital option didn’t exist — the whole thing happened on paper, in person.

    Rather than redesigning it ourselves, we went to the caseworkers — not to validate a prototype, but to co-create the logic, flow, and even contents of the form — before we even had one. We needed to understand how they thought about the questions, what sequence made sense, where the current form created confusion or unnecessary repetition, and what data fields were non-negotiable, the ones that couldn’t be skipped no matter what.

    This was never just about good practice — it was the only way to get it right. Caseworkers carry the realities of this service in their heads — the edge cases, the exceptions, the human complexity that no policy document captures. They were the experts. We were there to structure what they already knew.

    And because they helped build it, they were invested in it. That matters more than most teams realize when it comes to adoption.


    Five Days That Changed the Direction

    One of the clearest turning points was a five-day MVP planning workshop — a structured process designed to build shared understanding before anyone locked in scope.

    We came in with a question rather than an answer: What problem are we actually solving, and for whom?

    The work was carried out in three distinct phases. First, discovery workshops with business units and caseworkers — building a shared understanding of the service landscape, the pain points, and the gaps. Then, a five-day MVP planning workshop with the product and delivery team — working through the problem space, mapping dependencies, and separating foundational requirements from future enhancements. Finally, alignment workshops with executive leadership — confirming policy decisions before the build effort was committed.

    By the end, we had something more valuable than a backlog. We had alignment — a shared reason for building what we were building, a tight scope everyone had committed to, and a clear picture of what was in, what was out, and the effort each piece would take. Scope creep doesn’t happen because teams are careless — it happens because the boundaries were never made explicit.


    Eighteen Months Later

    The MVP launched within 18 months — longer than originally scoped, but grounded in what the service actually needed. Two foundational capabilities replaced two legacy systems that had become fragmented and difficult to maintain: an Assessment of Needs tool — logical, branching, digital — and CIMS, the Case Information Management System, built around how caseworkers actually work rather than how the old system assumed they did.

    That foundation changed how the team operated going forward. The roadmap stopped being a wish list and became a plan — we knew which problems to solve next, who needed to be in the room, and what realistic delivery would look like. That kind of clarity sounds obvious. At the start of this project, it didn’t exist.


    What I’d Do Again

    Co-create earlier. Hold the line on discovery even harder.

    The moments where this project worked best were the moments we slowed down enough to resist the first idea — and instead asked what the people using the service needed, how they thought about it, and what their reality looked like on the ground. The builder is rarely the user. And when you skip that step, you don’t just build the wrong thing — you build it with confidence.

    Transformation isn’t a technology problem. It’s a clarity problem. And that’s exactly what service design, done well, is built to create.


    Facilitated 12+ workshops | Engaged 15+ frontline caseworkers | MVP delivered within 18 months