Reframing a search problem and shifting a team’s research culture inside a major engineering refactor.
Role: Senior Digital Product Designer
Team: 1 Designer (me), 1 Lead Engineer, 1 FE Engineer, 1 BE Engineer, 1 QA Engineer, 1 PM
Timeline: 3 months
Product: BrickLink Studio – a Unity-based desktop 3D building tool used by the LEGO fan community to design, render, and share custom models.
A mature tool, a long-standing blind spot
Studio is a powerful desktop tool built on Unity, a game engine commonly associated with 3D game development. Its users range from casual builders to professional LEGO designers who can recall part numbers from memory. When I joined the team, two things were immediately clear:
- Part finding was a recurring pain point in user feedback channels, but it had never been studied in depth.
- Engineering bandwidth for new UI was genuinely limited. The team was deep in a multi-quarter refactor, migrating from a legacy codebase to a modular architecture.
I was also new to the 3D tool space. That outsider perspective turned out to be useful, as I asked questions the team had stopped asking.
The problem: parts exist, but users can’t find them
“Studio users struggle to find parts they need efficiently and confidently, even when those parts exist in the catalog.”
The team had heard the friction anecdotally for years. What we lacked was a structured understanding of why search was failing and for whom.
Shifting how the team learned from users
Before I joined, the team primarily learned from users through panels. These panels were group sessions where the team shared product updates and asked users questions to inform in-progress project work. While the panel discussions surfaced useful information, they were limited for discovery. It’s nearly impossible to surface a mental model in a room of twenty people. Part finding needed something different: deeper, 1:1 conversations where I could observe workflows, probe assumptions, and watch users hit walls in real time. I introduced exploratory user interviews as a research method the team hadn’t been using. It became part of how we now approach ambiguous problems.
Listening to understand user mental models
I ran exploratory interviews with 5 participants spanning novice to expert builders. The script was deliberately open. I wasn’t validating a design, I was building a mental model of how users actually search.
What I heard:
- Experts often left Studio entirely when they encountered difficult finding specific parts. For example, searching the BrickLink.com website to find a part name or number, then returning to Studio to paste it into the search input. Studio frequently left users to navigate away from the app do basic discovery work.
- Novice users often didn’t realize why a search failed. Was it a typo? A palette restriction? Was the part not in Studio at all? The empty state told them nothing.
- Community terminology consistently broke search. Common fan terminology like “cheese slope” or “SNOT”, which are fluent in the LEGO world, returned nothing in Studio.
- Expert and novice needs diverged sharply. Power users wanted speed and accuracy, while newer users wanted guidance and forgiveness. A complete solution would need to flex across both.
How AI accelerated synthesis
With several hours of interview material to parse through, I created a custom GPT, “UXR Copilot” using OpenAI’s GPT-5.5 model to help cluster themes across transcripts. I drafted a synthesis prompt anchored to the research questions I used, provided the cleaned transcripts (anonymized names, removed PII) as context, and used the output as a starting point for my own thematic analysis. Finally, I validated each cluster against the raw quotes to further validate the AI output. The interviews, the framework, and the design judgment were mine, while AI accelerated the synthesis.
Mapping the solution space
I organized the opportunity space into a tiered framework, from lightweight recovery to systemic change. This gave the team shared vocabulary and helped us scope realistically given engineering’s refactor commitments.
This framework let me have honest scoping conversations with engineering. We agreed to ship Levels 0–1 now, and roadmap levels 2 and 4 as future work as they fell outside what engineering could absorb during the refactor. Rather than also dropping level 3, we partnered with the Consumer Engagement team to deliver the recovery and education value through a new help article, getting users to the same outcome through a different surface.
The engineering reality check
Partnering early with the lead engineer reshaped my scope. Studio is built on Unity, which meant standard web/mobile UI patterns and component libraries weren’t always directly available. Every interaction had to be considered against what the engine could render and how engineering had built up Studio’s UI layer over time.
Search at the time was a local filter over the active palette, which split queries by word, ignored case and order, and applied no relevance ranking. There was no event logging in scope, meaning I couldn’t lean on quantitative data to prioritize. That grounded the work, as some ideas, like semantic search and synonym dictionaries, became long-term bets. Other options, like better empty states and clearer guidance, became actionable and, most importantly, achievable within the refactoring constraints.
Search complaints dropped. The research habit stuck.
Inside the constraints of a refactor, we shipped focused search improvements that quieted the loudest user complaints and changed how the team learns from users along the way.
- Reduced user complaints about part finding and missing parts in feedback channels
- No new complaints introduced by the changes, which was a meaningful signal given how sensitive this community is to regressions
- Improved community sentiment around part search and discovery
- Established ongoing 1:1 user interviews as a standard research practice for the team going forward
Hindsight: where I’d push with more time
A few places I’d extend or revisit this work if I weren’t designing inside a major refactor:
- Push for 1:1 interviews even sooner. The panel format was where I confirmed the gap, but I lost a few weeks before I trusted that instinct enough to act on it.
- Close the data loop from day one. Without event logging in scope, I had to rely on qualitative signal and feedback-channel sentiment. Standing up basic search analytics from the start would have sharpened prioritization and made impact much easier to measure.
- Invest in taxonomy and synonyms in absence of capacity constraints tied to refactoring. The community/official terminology gap is foundational. It became a planted flag here, but it’s really the root cause behind a meaningful share of failed searches.
- Explore role-adaptive workflows. Expert and novice needs diverge sharply enough that a single search experience inherently prioritizes one over the other. A mode-aware or progressive experience could resolve that tension rather than just managing it.
When research methods shape what’s possible to design
The shift from group panels to 1:1 interviews didn’t just inform this project. It changed what kinds of problems the team could take on next. You can’t surface a mental model in a room of twenty people. Introducing exploratory interviews opened up a category of ambiguous, foundational problems the team hadn’t investigated before.
A few other insights that shaped our work:
- Expert and novice needs diverge sharply. Designing for one without the other creates regression for the rest. Naming this tension out loud helped the whole team make better trade-offs.
- Scope discipline matters most under constraint. With a major refactor underway, saying no or “not now” to good ideas was an essential part of the job.
Joining a 3D tool team as someone new to the space, mid-refactor was not a small adjustment. The work I’m proudest of here isn’t a specific screen. It’s that I helped shift how the team learns from users, while still shipping meaningful improvements and considering real constraints.