The Problem

Nine Pods. Eighty-Four Percent Lost.

The people building SmartShop were doing it largely blind. Engineers on the team were working on software that managed highly physical, regulated, high-stakes repair work — jet engine components, the kind of things that have to be perfect before an aircraft flies. But most of them had never seen a shop floor, never held a router packet, and had only a vague idea of who they were actually building for.

84% of engineers said they didn’t understand the end users. That’s not a communication problem. That’s a structural problem — and it was affecting everything downstream, from pushback on UX decisions to inconsistent implementations in production.

The team was large, distributed, and split across time zones, languages, and cultures. Nine pods — roughly 70 engineers — spread across the US and Europe. Without a shared understanding of the users, everyone defaulted to their own interpretation of what “good” looked like. Engineers pushed back on UX work they couldn’t evaluate. They avoided a design system they didn’t feel ownership over. And they did the minimum to pass acceptance criteria, because they didn’t see the point of doing more.

Three things were broken:

• User empathy — most engineers couldn’t tell you who a shop floor technician was, what their day looked like, or why a specific interaction needed to work a certain way.
• Design system adoption — the existing system was a shared open-source repo that multiple GE teams had forked into incompatible flavors. SmartShop’s engineers were reluctant to invest in something they didn’t own.
• UX process clarity — engineers didn’t always know when or how to engage with the UX team, leading to last-minute interpretation, rework, and frustration on both sides.

The bigger issue: none of this was the engineers’ fault. The environment hadn’t been designed to help them succeed. That was something we could fix.

The Approach

Start With a Survey. Listen Before You Fix.

The temptation was to jump straight to solutions — redesign the handoff process, run a workshop, build some documentation. We resisted that. Before we could fix anything, we needed to understand how bad each problem actually was and which ones the engineers themselves cared about most.

The UX team designed a simple quarterly survey — 10 questions, 1–6 scale (so responses couldn’t sit comfortably on the fence), with a few open-ended fields for qualitative feedback. The goal was threefold: establish a baseline, prioritize our efforts, and create a tracking mechanism to prove whether our changes were actually working.

We kept the format dead simple on purpose. If it took more than five minutes, engineers would stop taking it. We needed honesty, not completion theater.

The survey covered:

• Wireframe accuracy and handoff quality
• Design system usability and adoption
• UX availability and responsiveness
• Satisfaction with the overall UX process
• Confidence in understanding end users
• How much UX involvement engineers actually wanted

The first results confirmed our suspicions — but the specifics surprised us. Engineers generally liked working with the UX team. Our wireframes were solid. We were reasonably available.

The real problem wasn’t our relationship with engineering. It was that we hadn’t given them the context to care

The Key Decision

This Wasn’t a Process Problem. It Was an Empathy Problem.

After the first survey, there was a fork in the road about where to focus our energy. The path of least resistance was to double down on process improvements — cleaner handoffs, tighter acceptance criteria, more documentation. Measurable, defensible, and within our control.

The harder case to make was that none of that would matter if engineers still didn’t understand why they were building what they were building.

Getting alignment on this required working through engineering managers before it ever went to a formal process. I had informal conversations with pod leads and engineering managers — finding the ones who were already frustrated by the back-and-forth with UX, and reframing that friction as a shared problem we could both benefit from solving. By the time we proposed the ShopTalk series and research trip rotation formally, enough people were already on board that it wasn’t a hard sell.

The Solution

Three Programs. All Running by End of Year One.

We addressed all three problem areas in parallel, but the user empathy work was where we put the most creative energy.

ShopTalk Series. Once a month, the UX team hosted a session at each site — roughly an hour, focused on one aspect of the shop floor process. Sometimes it was a process walkthrough. Sometimes it was a Q&A with someone from the actual repair operations team. Sometimes we brought in physical components so engineers could actually handle the parts they were building software around. Engineers submitted topics they felt they didn’t understand, and we built sessions around those requests. Participation was voluntary, but it filled up quickly once engineers saw the content wasn’t corporate fluff.

Mini Briefs. For every new feature or major user story, the UX team created a one-page brief: what this feature does, who it’s for (with a quick persona snapshot), why it matters to the business, and what pain point it’s directly solving. We reviewed these in sprint planning and attached them to user stories in Jira. This was the most scalable intervention — it meant every engineer who ever touched a story had at least a working context for why it existed.

Research Trip Rotation. We established a standing rule: every future UX research trip to a shop facility would include at least one engineer. The first trip was a turning point. The engineer who came back was visibly different — suddenly asking sharper questions in planning, pushing back more thoughtfully, and sharing what they’d seen with teammates. We encouraged those engineers to document their experience as a short vlog and post it to the team Slack channel. It spread faster than anything we designed.

Design system ownership. We cut the shared open-source model and pulled the design system fully into the SmartShop repo. Engineers could now contribute to it, modify components without fear of breaking changes from other teams, and see how components were actually meant to behave. We implemented Storybook as an interactive component library — which had an unexpected bonus: the UX team could review production-ready code and flag styling issues before they hit production.

UX pod assignments. Each of the five designers was assigned to two specific engineering pods. Engineers knew exactly who to call. Designers attended as many scrum ceremonies as possible — standups, planning, retros. Presence over process.

The Impact

The Numbers Moved. So Did the Culture.

We ran the survey four times between Q4 2018 and Q4 2019. Here’s how the key metrics shifted.

Peak numbers reflect Q1–Q2 2019, when the programs were running at full effectiveness on the team that built them. A late-2019 survey showed a dip — not because the programs stopped working, but because the original team had been replaced by a new Poland-based engineering group that hadn’t yet gone through them. SmartShop was defunded in early 2020 due to COVID-related budget cuts, before that cohort could catch up.