We hosted two Bain designers for a workshop last week, and here’s what we learnt from them.

MS SDM alumni Carlos Salom and Anamika Gopi partnered with the Creative Consulting Club and came back to Parsons to give us the 101 on what it’s like to work as a strategic designer at a top consulting firm. As current consultants on Bain & Company’s AI, Insights & Solutions (AIS) team, they designed a workshop that walked us through team structures, essential skills the role demands, sanitized case studies, as well as an interactive skills tracker for students. More than anything, the two spent time talking honestly about their own transitions from Parsons to Bain – reflecting on the challenges, the successes, and the key lessons they learnt along the way. 

This post covers the case studies they walked us through, what the job actually requires, how AI fits into a consulting team, and the biggest things Carlos and Anamika took away from their first six months at Bain.

THE CASES

To kick off, rather than talking about consulting in the abstract, Carlos and Anamika walked us through real cases, outlining the team setup, the problem they were brought in to solve, and how they got there.

Case 1: AI workflows for a media company

The first case was with a large media and entertainment company where creative producers were overwhelmed by the pace and volume of content — missed deadlines, fragmented workflows, no clear system holding things together.

The case team, built up of designers, engineers, data scientists, and consultants, recognized early on how sensitive the industry was to AI, especially in the wake of writers’ strikes. The core challenge became: how do you introduce AI without threatening creative roles?

“How do you embed AI in a company and make people not freak out about it? That was the real design problem.”

The answer they landed on was to focus on what Carlos called “low-touch workflows” — the repetitive, non-creative tasks that were eating up time anyway, like reformatting trailers, translating title cards, and clipping promos. Automating these with AI cleared bottlenecks without touching the creative work at all.

The process included current-state research, future-state blueprints, prototyping at multiple levels, and beta testing. Something that surprised Carlos is that clients didn’t want the full solution handed to them on day one. Phased delivery — here’s what we can do in six months, here’s the one-year picture, here’s the long-term vision — turned out to be just as important as the design itself.

Lastly, there was also a moment that ended up saying more about the job than any framework could. With senior team members on PTO, Carlos had to run a live user test alone. When the participant couldn’t access the prototype, he had to improvise. He shared his screen and navigated through it based on their verbal instructions, letting the conversation guide him.

“It shows three things: you have to adapt fast, people respond to low-stakes conversations, and you need to show up for your team when it counts.”

What he’d done, it turns out, has a name — Wizard of Oz testing. But he didn’t know that at the time, and in a way that’s the more useful takeaway. This job will ask you to figure things out on the spot, and the best you can do is show up and try.

Case 2: Reimagining the digital experience for a wealth management firm

The second case had a straightforward brief: a wealth management company was losing ground to newer, more digitally native competitors. Their platform felt dated, and they wanted to reach a broader client base than the one they’d historically served.

After digging into NPS data, behavioral data, competitive benchmarking, and interviews with both clients and financial advisors, something emerged that reframed the whole project. The company’s real advantage wasn’t their technology. It was their people. Advisors who knew their clients’ full life context, who flagged things before clients brought them up, who’d sometimes been working with the same families across generations. Anamika and the team knew that wasn’t something you could replace with a better interface or an AI chatbot.

So they designed the solution around the relationships. One concept was an AI tool that would prep advisors before meetings — surfacing relevant context from previous conversations, flagging things worth raising — so they could show up more informed without relying entirely on their own notes and memory. The technology had to serve the human connection; its job was to make the advisors better at what they already did well.

The design work stretched across the full double diamond. That included facilitating service blueprinting workshops — mapping the full client onboarding journey, front-stage and back-stage — with rooms full of stakeholders who had never seen a blueprint before. Each of them owned a narrow slice of the journey and had never really had to think about the whole thing. Getting them to zoom out was one of the harder facilitation challenges of the project.

“We had to get an AI-skeptical client from ‘this conflicts with our values’ to ‘we can’t wait to implement this.’ Seeing that shift happen was huge.”

The deliverables had to exist in multiple versions too. A two-minute summary for the C-suite, focused on what problem this solves and what it costs. A more detailed version for the digital and engineering teams, focused on whether it’s actually buildable. Same project, completely different conversations — and knowing which one you’re in is half the job.

What the Job Actually Requires

So what is consulting actually like, and what shifts should you be prepared for coming out of design school? Anamika and Carlos pointed to a few things that came up again and again.

Speed and iteration over perfection. In consulting, getting an 80% answer down quickly — and then finding out what’s wrong with it and fixing it — is usually worth more than waiting for something complete. Anamika was direct about this: her attachment to quality over speed was “a huge blocker” in her first few months. 

Frameworks as orientation, not instruction. The linear path through design thinking doesn’t always show up in practice. A team might move from research straight to synthesis because they already have what they need. If you can get to point C without doing A and B, you go to C. Getting comfortable with that takes some adjustment.

Hypothesis-first thinking. Parsons training emphasized holding off on conclusions until you’d really tested your assumptions. Consulting asks for you to come in with your best current hypothesis, be transparent about what it’s resting on, and be ready to be wrong. 

Explaining your work to people who aren’t designers. This came up more than anything else. Both Carlos and Anamika said that being able to communicate design value to engineers, financial modelers, and executives is one of the most important things in the job. You must understand what each audience actually needs to know, what they’re worried about, and what they don’t care about at all. The same project has to be told completely differently depending on who’s in the room.

“We take for granted that everyone knows what we’re talking about. You very quickly understand that you’re talking to so many different people, and you need to explain the value of what you’re doing to people who probably don’t understand your world at all.”

What they’ve learned in their first 6 months

One of the clearest things both of them took away from their first six months was becoming the team’s go-to on end-to-end customer research. Building the research approach, writing interview guides, recruiting participants, moderating interviews, synthesizing insights, presenting findings to executives, and translating all of it into something the rest of the team could actually use: journey maps, service blueprints, experience videos.

This matters for a pretty simple reason. On a consulting case team, designers are often the only people who have spent real, sustained time with what customers are actually saying. That’s a position of knowledge that no one else on the team has!

So if you have it, it’s your responsibility to use it — not to wait for someone to ask. They talked about a shift that happened gradually. Both started going into presentations having already thought through the questions the room was likely to ask. Started figuring out in advance what was most important to raise from a design perspective, and bringing it into the conversation himself rather than waiting for an opening. It’s a small change in how you show up, but it’s how you start demonstrating the value of design to people who don’t already know what it is.

AI as a Team Practice, Not Just a Personal Tool

This session wouldn’t have been complete without asking how Carlos and Anamika actually use AI in their own work. One thing that came up specifically is that there’s an appetite at Bain for designers who use AI in their own workflow, but there’s even more appetite for designers who can bring the whole team along with them.

The example was from a brand strategy project for a financial services client. The challenge was communicating brand identity — something inherently emotional — in a case that was otherwise driven by data and financial modeling. Carlos used vibe coding to build a quick visual prototype showing how the brand could actually look in the real world.

But as long as Carlos was the only one working on it, it stayed in a silo. So he opened it up by inviting the team in, teaching them to prompt alongside him, and let what had started as one person’s prototype become something everyone had a hand in. The buy-in followed naturally from there.

“It became most impactful when I included everybody on the team. That’s when the real magic came through.”

The broader point is that in companies skeptical of AI, showing tends to work better than advocating. A working prototype is more persuasive than a slide about potential. And designers who can teach AI workflows to their teammates — not just use AI themselves — become a bridge for the whole team.

A Few Things Worth Carrying Forward

Learn to explain your work to non-designers. Both Anamika and Carlos said this was the skill they most wished they’d started building sooner. Every project involves people who don’t know what you do, and making your work clear to them is part of your job.

Get comfortable with the nonlinear. Frameworks are useful for orientation, but consulting moves fast and skips steps. The ability to work with ambiguity matters more than sticking to the process. If you can get to point C, you don’t always have to do A and B first.

An 80% answer on time is better than a perfect answer late. In a consulting environment, speed and iteration matter more than waiting for something complete. Get something down, find out what’s wrong, fix it, and go again.

Know what you know that others don’t. As a designer on a consulting team, you often have more direct access to the customer voice than anyone else in the room. That’s not a small thing! Surface what you’re learning, and don’t wait to be asked.

Practice the pitch. Context, insight, recommendation, impact. Get a project into that shape and be able to deliver it clearly and concisely, and use every opportunity you get to work on it. Carlos and Anamika shared a framework for pitching projects during the workshop, which we’ve attached below for guidance..