I specialize in turning complex operational problems into measurable design outcomes. My work spans service design, AI-native product strategy, and measurement frameworks. Most recently at McKinsey, I led design for enterprise tools serving 45,000 users. I'm now focused on applying that work to energy and climate.
Contact: herskowitz.daniel@gmail.com
McKinsey provisions laptops to ~45,000 colleagues worldwide. Every hardware refresh cycle, thousands of employees needed hands-on IT support to migrate from their old machine to a new one, such as transferring files, reinstalling software, and configuring settings. Employees had to book three days ahead and then sit through four hours of downtime while their device was migrated. Each migration required 128 minutes of dedicated tech support time. The biggest complaints were work disruptions and downtime. People were losing half a day to what felt like it should be simple.
This was 2020. COVID had made the process even more painful. Coordinating in-person IT support during a pandemic added logistical friction on top of an already slow system.
I owned this end-to-end: design strategy, service design, and UI design. I worked alongside a PM, engineers, provisioning ops, and security. I was brought in specifically to solve the migration problem.
The obvious approach was to make IT faster at doing migrations. In a workshop with the balanced team, we landed on a different question: the underlying technology was mature enough that IT staff didn't need to touch the process at all, if employees were willing to do it themselves.
The question that mattered was whether people would actually self-serve.
We didn't assume the answer. We framed it as a testable hypothesis and agreed with stakeholders to only move forward if we were getting high satisfaction and low effort scores. There was real skepticism from stakeholders who believed employees would push back against doing their own migrations. Turning that disagreement into a measurable experiment rather than a political argument is what let the project proceed.
Not everyone was going to be comfortable self-migrating on day one. We targeted younger new joiners first: more tech-savvy, more flexible, less attached to "the way things have always been done." We interviewed them and confirmed they were comfortable with the concept in theory. This gave us a forgiving user base to learn with before broadening.
We started with an MVP that put more onus on the end user. There were several manual steps on both the old and new computer, guided by a chat interface. It worked, but there were many steps and room for user error.
From there, we iterated. We figured out what to fix through three inputs: watching users fail in real time, analyzing support ticket data, and running exit interviews after completed migrations. Each round told us which steps to automate and which to simplify.
Over 13 months, the experience evolved from a clunky guided process into a highly polished, very low-effort consumer-grade flow. The chat interface remained the primary interface throughout, but the final version was dramatically shorter. Fewer steps, less room for error, less time.
As we perfected the process, we expanded beyond early adopters to the broader employee population. The fallback was always there. Anyone who couldn't or wouldn't self-serve could go to their local office IT. But as the experience improved, fewer people needed that fallback.
Employee requests new laptop → Books IT appointment (3-day wait) → 4 hours of downtime → IT staff spends 128 min on manual transfer, reinstallation, configuration → Employee verifies → IT closes ticket
Employee receives new laptop → Opens chat-based self-migration tool → Guided, mostly automated process → Employee verifies → Done (fallback: local office IT for edge cases)
40% increase in customer satisfaction
~$1M in annual savings
Migration went from a 4-hour disruption with a 3-day wait to a streamlined self-service process
128 minutes of IT staff time per migration largely eliminated
I was too finicky about the details of the early MVP. I should have put out features faster to speed up the test-and-learn cycle. When you're running an experiment, the point is to learn quickly. Perfectionism slowed down my iteration speed in the early phases. The insight only matters if you act on it fast enough.
McKinsey's internal tech support serves ~45,000 colleagues worldwide. Like most large organizations, the firm had a self-serve support website with knowledge articles, how-to guides, and troubleshooting steps. Usage was fine but resolution was low. Colleagues would search, not find what they needed, and call the helpdesk anyway.
The initial goal was tightly scoped: resolve the easiest 30% of help desk calls across 8 use cases, while maintaining a 4/5 customer satisfaction score.
I owned this end-to-end across multiple phases: design strategy, service design, UX, visual design, and conversational design (tone, avatar, interaction model). I designed the avatar and brand identity from scratch, running stakeholder workshops and user focus groups to land on a personality that felt caring and efficient across an international audience. I worked alongside the service support team, technicians, engineers, PMs, and security.
The first move was straightforward. Put a chatbot in front of the existing knowledge base. Instead of searching the support site, colleagues could ask a question conversationally and get a link to the relevant article. This was primitive AI, pattern matching rather than language understanding. It worked as a better front door to existing content, but it didn't fundamentally change resolution rates.
The next phase was more ambitious. We integrated LLM capabilities so the bot could give direct inline answers instead of linking to articles. The expectation was that this would be the breakthrough.
It wasn't. We hit two barriers:
Cognitive load. When the bot could give step-by-step instructions, those instructions were often too long and too complex for our audience. People dropped off mid-flow. The bot was technically correct but practically useless.
Structurally unresolvable issues. Many of the problems colleagues brought to the bot were, by design, unsolvable through a chat interface. They required elevated permissions, backend system changes, or manual intervention by a technician. No amount of bot intelligence could fix a Windows biometrics glitch that locked someone out of their account.
This was the turning point. There was strong stakeholder pressure to keep making the bot smarter. Find a better LLM. Fine-tune the model. The assumption was that a third-party AI would do all the heavy lifting and our team wouldn't need to solve the many "last mile" problems.
I pushed back. The underlying issues simply weren't designed to be resolvable. Intelligence couldn't compensate for missing infrastructure. No chat interface, no matter how smart, can fix what the backend systems won't allow.
I created a customer service roadmap built from the bottom up. We analyzed the top 20 support issues, which accounted for roughly 25% of all calls. For each one, we asked: what would it actually take to resolve this without a human?
The solution was designing automated resolution paths that the bot could trigger. These fell into two categories:
Proactive fixes detect a signal that a problem exists and resolve it silently before the user even notices. Example: Windows running unusually slow. The system detects performance degradation and runs remediation automatically.
"Do it for me" hooks let the user trigger an automated sequence that handles the steps they can't or won't do manually. Example: a crashed Office app with a corrupted file. The user clicks one button and the system finds and repairs it. Or an account locked out due to a biometrics glitch. The system handles the elevated permissions and unlocks it.
This required coordination across multiple teams to build the hooks and proactive monitoring. It was no longer a design project. It was an organizational alignment problem.
First-contact resolution rose from 42% to 60%
The system grew to handle over 1,000 conversations per month across more than 1,000 user intents. The chatbot went from a slightly better search bar to an interface that could actually resolve problems. The difference was what sat behind the interface.
We should have brought the highest-level decision makers into alignment much earlier. Building the resolution hooks and proactive fixes required buy-in and effort from many teams, and that was only possible once a director was aligned with the bottom-up approach. We lost time because the philosophical shift happened too slowly at the leadership level. The leadership needed to accept that no LLM would magically fix everything, and that the gains were in the weeds of why stuff was actually failing. I'd front-load that alignment work next time.
McKinsey's Code Beyond program provides a catalog of AI skills, LLM-based tools designed to make PMs and designers more productive. The catalog exists. The skills exist. But only about 20% of the target users are actually using them.
Worse, there's no verification layer. Nobody knows whether the skills that are being used are actually effective at achieving user goals. There's no data on breadth, depth, or frequency of usage. No way to tell which skills are working and which are shelf-ware.
I own this end-to-end: design strategy and prototyping. Working alongside Petr Mares, Director of Product Management.
The prevailing assumption was that if you create an open marketplace of skills, the best ones will rise to the top. Build it and they will come.
I challenged that. An open marketplace leaves users with too many options and no way to know which ones actually work. Skills are tools that need iteration loops, just like any product. Without measurement, you can't improve them. Without improvement, adoption stalls. The 20% usage rate meant the skills weren't solving real problems well enough, not that people didn't know about them.
I built a prototype that establishes the foundation for test-and-learn iteration on skills. It has two parts:
Measurement infrastructure. A standardized way to track breadth, depth, and frequency of usage, such as who is using each skill, how often, and how effective they are at achieving user goals. This includes telemetry and integrated feedback mechanisms.
Version control and syndication. A system for checking skill versions and auto-updating so that when we iterate, new versions are pushed to users automatically. Without this, improvements die in a repo somewhere.
The prototype is implemented. The telemetry is live.
Now we can parse out which skills are being used by whom, which ones should be used and aren't, why not, and where the friction points are. Each answer feeds the next iteration cycle. It's the same test-and-learn loop that any product requires, applied to AI skills.
This is an ongoing experiment. The hypothesis is that treating skills like products, with measurement, iteration, and active management, will move adoption well past 20%. The infrastructure to test that hypothesis is now in place.
Most-downloaded skill set in the firm
Through iterative improvement informed by the telemetry infrastructure, we developed a design and research skill set that became the most-downloaded in the firm, averaging 450 downloads per month.
Articles
Side Projects
Product Design Strategist
I specialize in establishing North Star frameworks that connect design decisions to measurable outcomes. I design solutions and build the measurement infrastructure that tells you whether they're working. At McKinsey, this meant turning internal service design into a discipline with quantifiable customer impact such as satisfaction scores, cost savings, and adoption rates.
I led the Code Beyond program at McKinsey, creating 12 AI skills to embed LLM-based tools into the product design process for PMs and designers. I also developed the MDS design skill for building brand-adhering interfaces on Cursor and Claude, building AI tools for the organization to scale impact and spur adoption.
I've spent nearly a decade designing internal products at McKinsey that serve 45,000+ colleagues globally: device provisioning, tech support automation, identity management. These are high-constraint environments where every workflow has to survive contact with real operations at scale.
From the firm's first AI customer support chatbot to the CASEE automation strategy, I consistently reframe technical initiatives through a customer-centric lens. This means evaluating vendors, mapping journeys, and prioritizing based on actual pain points.
| What | So What |
|---|---|
| AI tech support chatbot | FCR from 42% to 60% |
| DIY laptop migration service | 40% increase in customer satisfaction, ~$1M annual savings |
| Code Beyond AI skills program | 12 skills created, measurement infrastructure implemented |
| CASEE chatbot strategy | Evaluated 3rd-party vendors, designed workflows for top 10 escalation sources |
| Digital risk customer research | Established best practices and prioritization for identity management |
| Device provisioning service (45K users) | Automated configuration and registration workflows at firm-wide scale |
I've developed and delivered workshops on North Star goal-setting, quantifying design impact, and structured problem-solving for new service and product designers. This is central to how I work: building shared measurement language so teams can align on what success looks like before they start designing.
The philosophy degree is practical. Training in how to decompose arguments, identify assumptions, and construct frameworks is exactly what product-market fit measurement requires, applied to a different domain.