When I arrived, Design was the missing piece in a newly transformed product organization — and had been for reasons that had nothing to do with the people in it. The team had been navigating years of organizational change: reporting into Engineering, limited infrastructure, and a product org that was itself still finding its footing. Engineering had just gotten its operating model. Product had just gotten its operating model. Design was next.
The symptoms were hard to miss. Work was perceived as slow — and honestly, some of it was. But more of it was just opaque. Quality was inconsistent with no agreed standard for what "good" meant. There was no shared language between Design, Product, and Engineering about what design was supposed to do or when. A rapid prototyping initiative had been bogged down for months — good idea, insufficient resourcing. The component library, started the year before, had the right instincts but had never gotten the focus it needed to make it into production. And Designers — previously embedded within Engineering with no clear path forward — finally had PM and Engineering peers with leveled career architectures, and nothing equivalent of their own.
Nobody was failing. The org had been in motion, and Design was the last piece to land. A lot of the problems that looked like execution problems were actually visibility and infrastructure problems in disguise.
A quick note on how before what: none of this was handed down. I started with a clear mandate from leadership and listening sessions with all the Designers to get the lay of the land. After percolationg, I ran an ideation session with the team. We voted, and I selected initiatives (mostly) from what ranked highest. Each initiative was then led or co-led by a member of the existing team. My experience is that ownership is what makes change durable. A framework someone helped build is one they'll actually use after the consultant leaves, because it's not my baby, it's theirs.
Five areas, more or less simultaneously. (Interim engagements don't have the luxury of sequencing.)
While the client presented with ye olde "design is slow" symptom, what I found (and what we find often) is that part of the issue is that Design is opaque. And opacity comes off as slow even when it isn't, because the team didn't see the 30 versions (or whatever) that the Designer came up with before presenting this one. Three changes addressed this together.
The first was WAYWO — What Are You Working On — a regular habit of sharing work in progress across the team that Rob Hunt documented in 2018. Basically, Slack fires off a message at a random time in the day, and everyone responds with a screen shot of whatever they happen to be doing. This was an old ritual that had fallen off, so the team suggested it and now that I've seen it in action, I'm a huge fan. When stakeholders can see design thinking evolving in real time instead of waiting for a reveal, "slow" stops being the right word for it. Even just within the team, it started to build more safety around sharing before Designers are "ready". My hope is that this will evolve to product teams and not just the design team, although making it more ok to share work in progress will be good regardless. Because transparency doesn't just change the perception of speed, it changes the reality of it... because work that's visible gets feedback earlier, and earlier feedback means fewer late-stage pivots.
The second was a seating model that balanced two real needs that seemed, at first, like they were in tension. Designers were feeling a little beleaguered — a small team, spread thin, navigating a lot of organizational change. They needed the coherence and mutual support of sitting together. But the product teams needed designers present and embedded. The solution: designers moved to sit with their project teams day-to-day, and hoteled in a shared design area once a week on days with design team meetings.
Both of these were supported with encouragement around transparency, which is easier than it sounds, inviting sharing and active management of feedback (after all, sharing something early and getting tons of detailed and unnecessary feedback is a recipe for never sharing early again). I also helped Product and Engineering teams get more comfortable reacting to early and possibly way-off ideas, guiding feedback needs if they didn't get any guidance from the Designers.
Nobody had agreed on what design was for, when it added value, or how to ask for the right kind of help. We weren't going to fix that by handing everyone a design process bible and calling it alignment.
Instead, we introduced a flexible framework for having a conversation about what was appropriate for any given situation — and, just as importantly, what wasn't. Not every project needs a generative research phase, or an ideation workshop. But when a project does need one of those things and nobody thought to ask, that's where opportunities quietly disappear.
A Question-Based Design Brief did a lot of this work. By surfacing what was known, assumed, and still open, it helped teams see the full range of what design could contribute — even when the current project only needed a slice of it. The brief became a way of agreeing with collaborators: "We're not doing a full discovery phase on this one, because it doesn't make sense. But when you have something that needs that, we can help with that too." Expanding what people imagined design could do, one conversation at a time.
A four-tier engagement model let teams right-size design support, from full discovery to office-hours advising, with expectations set up front.
A Figma Project Template did some of the heaviest lifting quietly. Design work had often started without explicit agreement on who the product was for and why — which is a surprisingly effective way to move quickly in the wrong direction, or slowly in several wrong directions. The template put goals, status, and the specific question needing an answer in a given meeting at the top of every project file. Also, the quality of the visual design was top-notch. (I brought in a ringer from DesignMap for this, not because the internal team wasn't capable, but because it's fun to be on the other side of the table every once in a while, seeing how other Designers manage feedback, asking questions, etc.) This document encapsulated quality, focus, speed and transparency, all in a few slides.
We built a shared quality definition — grounded in Peter Merholz's writing on what quality means in UX — that gave the team something closer to an objective bar. Short list of principles, concrete examples.
The dormant component library got activated and is now in active use by Engineering. Consistency isn't just an aesthetic preference — it reduces cognitive load for users and rework for teams, so this addressed both speed and quality.
Critique partner rotations paired designers for six-week stretches of structured work-in-progress reviews, with retros at the end of each cycle to adjust what was working and what wasn't. That put multiple brains on hard problems, normalized showing unfinished work, and had the added benefit of building relationships and shared skills across a geographically distributed team.
One of the less glamorous and more important things we did was give the design team the basic infrastructure to credibly and collaboratively run research themselves.
This meant training sessions for Designers, Engineers and Product Managers on research methods, boilerplate protocols they could use without starting from scratch every time, and shared notetaking and sensemaking templates. The goal was a design team that could lead research in genuine collaboration with product and engineering — not hand it off, or skip it because the process felt too heavy. I'm proud to say that the team ran the company's first research with users outside the company's existing customer base with these tools.
Designers had been asking for this for a long time — and the conditions to do it had only just materialized. They'd been embedded within Engineering without a design-specific path forward, and PM and Engineering had only recently finished their own frameworks by the time I arrived. The moment finally existed to do it right. Building leveled role definitions and competency expectations across individual contributor and management tracks was both table stakes and non-trivial. Within four weeks it was done, all the Designers were leveled, and knew what to focus on next.
We also supported the team's experimentation with and adoption of AI tools across design workflows — not just the obvious applications, but the broader range of possibilities. For a team who just got Figma in 2025, this was a big step, but also perhaps more welcome than for a team who are dug in to existing tools and workflows.
Before the results: a word about the people.
This team had been through a lot of change. Reorgs, shifting leadership, years of operating without the infrastructure or organizational standing their peers had. They would have been completely justified in being defensive, protective, or just exhausted. Instead (and I like to think it's partially because we really listened to them at the start) they did the opposite. They embraced what worked, learned from what didn't, improved every idea I brought, and made the work genuinely their own. The frameworks exist because they built them. The results exist because they delivered them. I mostly just held the flashlight.
The prototyping project is the one I lead with. This project had been stalled for months. Four weeks in, the team had completed three tested iterations with users outside the company's existing customer base — a first.
The component library made it into Engineering's production workflow. Teams are shipping with it.
The bigger outcome was structural. By the end of the engagement, Design had a defined role in the product operating model — not as a service bureau, but as a genuine partner in mitigating risk and sharing ownership of product success. And because the work was built with the team rather than handed to them, there's a reasonable chance it stays that way.
We left a detailed handoff: hiring recommendations for the incoming leader, a research infrastructure plan, training priorities and suggested budget, and active project context for work already in flight. The goal was to make the transition as small a disruption as possible, and to make sure what had been built didn't depend on us to keep standing.
DesignMap brings interim design leadership to organizations where the function exists but hasn't found its footing. We build the operating infrastructure, work alongside your team on real projects, and leave frameworks your people can own.
The goal isn't to make you dependent on us. It's to make us unnecessary.
Which, as business models go, requires a certain amount of faith. We're okay with that.