Context
dbTechnologies, an Italian manufacturer of professional audio systems, had always paired its speaker hardware with third‑party software specifically for venue design and acoustic simulation, never a product of its own. Aurora Predict was the first step toward changing that: a proprietary tool built in‑house, starting with the research and interface foundation the engineering team would build on later.
I led UI/UX on a three‑month discovery engagement, working within a small two‑person product team alongside a product manager, with primary ownership of the UX research, interaction design, and interface direction.
The problem
Live audio technicians were stitching together separate tools for venue design, acoustic simulation, and mechanical analysis, with reporting done by hand because none of the softwares used talked to each other. Interviews and competitor analysis surfaced why that experience had never improved:
- Fragmented tooling: no single tool covered the full workflow, so technicians moved between disconnected software for each stage of a project
- Dated, hard-to-navigate interfaces: competitor tools looked and felt visually obsolete, with unclear paths through core tasks
- A steep learning curve: existing software assumed expert users; average technicians struggled to complete fundamental tasks
- Hardware that couldn't keep up: most technicians work from older laptops on-site (at least in Italy). Software built for high-end machines simply wasn't usable in the field
Process
The engagement followed four phases, moving from why to outcome rather than starting with features.
Learning the domain before designing anything
Before interviews or any design work could start, dbTechnologies handed over a full manual (specs document) covering everything they envisioned for the software. Going through it meant getting genuinely fluent in how acoustic simulation and reporting actually work, not just enough to hold a conversation, but enough to ask informed questions and recognize what mattered in the interviews that followed.
A competitor analysis focused on the experience
Once the domain itself made sense, the next step was looking at how existing tools actually felt to use, downloading and testing the competitor software directly rather than assessing it from marketing pages or spec sheets. The focus stayed on experience: how navigation was structured, how discoverable core actions were, how steep the ramp-up felt for someone new. That gave the research plan something concrete to validate with real users, instead of walking into interviews with only assumptions about where the pain actually lived.
Research built around specific hypotheses
Rather than open-ended discovery, interviews with live technicians and installers were designed to test concrete assumptions; that tool fragmentation, interface complexity, and imprecision were driving frustration. That framing kept the research fast and made every finding directly actionable.
Prioritizing with an Opportunity Solution Tree
Findings were mapped from desired outcomes through opportunities to candidate solutions, then triaged into Now, Next, and Later roadmap. Scoping "Now" to immediate architecture, design, usability and UX flow improvements, rather than trying to solve everything the research surfaced. I was able to kept the interface work grounded in what the development team and engineers could actually validate in this phase.
Working within real constraints
This wasn't an open-ended research project, it was deliberately scoped as a tight, structured discovery sprints with a bounded number of interviews and clearly defined deliverables. That meant making early calls about which questions mattered most and designing a research plan efficient enough to still produce a credible, evidence-backed direction within a short, fixed window.
Designing the system
The discovery and UX & UI design work became the reference for the engineering team used to move into development. The sequential flow, the dedicated menus and sidebars for managing elements, and the standardized set of commands across creation and editing tasks were all aimed at the same goal: cutting the cognitive load of a genuinely complex tool (and also for people already familiar with other softwares), so the platform's power didn't come at the cost of how learnable it was. The next step, flagged going into development, is usability testing with real technicians to validate the flow before it's built out further and confirm the improvements actually land with the people using them daily.
Lesson learned
This project confirmed something that's easy to lose sight of in highly technical products: UX quality can make or break how effective a tool actually is, no matter how powerful it is underneath. When workflows are fragmented and an interface's logic doesn't guide the person using it, even the most capable software risks becoming something people struggle to adopt and use well.
The discovery phase was what made the difference, it kept the focus on real, observed needs, and turned scattered pain points and opportunities into a concrete product direction. That's the part of the process I'd protect first on any similarly technical project: the temptation is always to jump straight to interface work, but the discovery is what gives those decisions a reason to exist.