# Datamaran architecture redesign

Restructuring how a complex ESG platform reveals what matters.

## The problem

Datamaran started as a regulatory intelligence tool. By 2025 it had become something more layered: regulatory tracking, ESG benchmarking, double materiality assessments, AI-powered research, and a growing set of analytical modules. Each addition made sense on its own. Together, they produced a navigation structure that reflected the product's history more than its users' goals.

Users were not navigating Datamaran — they were searching it. Power users had developed personal rituals to reach the features they needed. New users couldn't find where core workflows began. The sidebar had become a list of product decisions rather than an entry point to work.

The problem wasn't any single feature. It was that the information architecture had been built incrementally, one launch at a time, and the seams were showing.

The reframe that drove the work: the problem wasn't that the sidebar was messy — it was that the structure reflected the product's history, not the user's goals.

## My role

**Senior Product Designer** — I led the information architecture and navigation redesign end-to-end: research, structural proposals, interaction design, stakeholder alignment, and handoff. I worked alongside a product manager, a lead engineer, and a researcher who ran the user sessions.

## What the research surfaced

We ran moderated sessions with twelve users across three customer segments — compliance leads, sustainability managers, and ESG analysts. We also reviewed six months of navigation analytics and session recordings.

Three patterns repeated:

**The sidebar was a list, not a map.** Users couldn't predict where a task lived. They navigated by memory, not by reading the structure. New tasks required exploration — not because the features were missing, but because the structure gave no indication of where to look.

**Module boundaries did not match task boundaries.** A user building a double materiality assessment needed to move across three separate sections to complete a single workflow. Each transition felt like leaving and re-entering the product. The structure imposed a discontinuity that the task didn't require.

**The AI assistant (Answers) existed outside the workflow model.** Answers was powerful for research, but it sat adjacent to the core tools rather than within them. Users who discovered it loved it. Most didn't know when to reach for it.

## The structural decisions

**Reorganize around jobs, not features.**
The previous structure grouped functionality by module: Regulatory Intelligence, ESG Insights, Double Materiality, Reports. These were accurate categories — they just didn't correspond to how users approached work. The new structure groups by what users are trying to accomplish: understand my regulatory landscape, build my materiality assessment, benchmark my position, generate a report. The features are the same. The organizing principle changed.

**Flatten depth, not breadth.**
The temptation was to reduce the number of items in the sidebar. That wasn't the problem. The problem was that secondary actions were buried two and three levels deep, requiring users to expand sub-menus before finding what they needed. The redesign kept breadth roughly constant while eliminating depth — surfacing secondary navigation into persistent contextual panels rather than nested menus.

**Integrate Answers into the workflow layer.**
Rather than a persistent side-panel that exists independently of context, Answers is now context-aware: the questions it surfaces, the data it draws from, and the actions it suggests are scoped to the current view. A user in the materiality assessment module sees Answers primed for materiality questions, not generic ESG research. The panel didn't change. Its integration into the navigation model did.

**Protect the power user paths.**
Keyboard navigation, quick-access command bar, and module-jump shortcuts were not part of the original IA. They were added as a deliberate layer for the segment of users who had built their own workarounds. Removing their workarounds without replacing them would have made the redesign a regression for the users who were using Datamaran most intensively.

## The detail that changed the decision

Mid-way through the structural work, I proposed an approach that moved the top-level navigation from a sidebar to a top bar — a pattern more common in analytics tools of this type.

We prototyped it. We ran sessions. Users in the compliance-lead segment navigated faster. Users in the analyst segment consistently reached for the sidebar that was no longer there.

The difference wasn't preference — it was workflow density. Compliance leads complete a small set of recurring tasks. Top navigation is efficient for that. Analysts move across the product continuously, cross-referencing and switching contexts. Sidebar navigation keeps persistent structure visible and reduces cognitive overhead when context changes frequently.

We kept the sidebar. The prototype run was worth it — not because it confirmed the original approach, but because it replaced an assumption with evidence.

## The outcomes

The redesigned architecture shipped to a controlled group of accounts before full rollout. Navigation analytics showed a reduction in cross-module journeys — tasks that previously required visiting three sections were completing in one. New user time-to-first-meaningful-action dropped. Answers usage increased in the accounts where contextual integration was live.

The metrics that matter long-term: support tickets related to "can't find" navigation issues, time-on-task for core workflows, and Answers engagement rate by module.

## What I learned

Information architecture work is not well-served by early convergence. The top-bar prototype felt like a detour at the time and turned out to be load-bearing — it converted a design debate into a research question. The answer came back faster and with more authority than any round of stakeholder review would have produced.

The other thing: users who have built workarounds have built them for a reason. The workaround is not the problem — it's evidence of one. Redesigning the structure without understanding what each workaround was compensating for would have removed the symptom while leaving the cause.