Creating information architecture that scales

Goal

Create a scalable, future-proof information architecture that fits different testing modules and matches global UI style requirements.

Challenge

Reflect is transforming. Originally a web-automation tool, it's becoming a hub for test automation — available as an API testing feature within the API Hub. Its current information architecture isn't flexible enough to accommodate other testing modules (API, Mobile, Load Testing), and its visual style and UI differ from the SmartBear UI style. We also needed to keep changes minimal so we wouldn't disrupt the experience for current users — making them discover new modules easily, while still narrowing focus to the testing type they came to automate.

My role

• Collaborated with PMs to understand the high-level approach, scope, and limitations
• Research: analysed the current IA, ran a competitor benchmark, and drafted proto-personas
• IA design: mapped the extended IA and framed how it would translate to UI; chose the approach best suited to our ICP
• UI design: produced design proposals for the IA, ran reviews and refinement, and handed off

The solution

I started by zooming out on the current IA — mapping the full application into one diagram to see how complex it is, how it's layered, and where change was possible. I then ran a competitor benchmark (e.g. BrowserStack) to pressure-test my assumptions and come prepared to discuss options with PMs.

The turning point was realising the IA depended on how users prefer to work. Analysing existing research, I identified three persona scenario types, each pointing to a different IA approach. That insight let me move from guesswork to a structure grounded in real user behaviour — and we landed on an architecture that balances transparency and oversight with letting users focus on the testing type most relevant to them.

What it took — the tradeoffs

After defining persona types, I explored several concepts to fit each one — and ended up with too many options, which made deciding hard and caused several iteration loops. The real blocker was that we hadn't yet narrowed our target user type. Breaking the deadlock took a round of discussions with the Product Director and team feedback to commit to a single, balanced compromise. All of this happened with limited research resources, so close stakeholder alignment did the work that more research normally would.

Outcome

• Aligned a senior stakeholder on a clear direction. Working closely with the Product Director, I helped redefine the app structure from the ground up and kept a shared vision throughout — despite limited research resources.
• A scalable, future-proof IA that can absorb new testing modules (API, Mobile, Load) while preserving the experience for current users.
• A defensible decision under ambiguity — persona-driven analysis turned an overwhelming set of options into one balanced, agreed approach.

What I'd do differently

I'd narrow the target user type far earlier. Most of the iteration loops and indecision came from trying to serve every persona at once; committing to a primary user sooner would have cut the wasted exploration and got us to the balanced solution faster.