Everything you can do to a grid, in one place beside it

Three modes, switchable: fully expanded; a narrow icon rail where hovering a group icon opens its links in an overlay; and fully hidden, revealed by moving to the left edge and dismissed by moving away. Items can be pinned above the groups. The groups themselves collapse.

The links and their names did not change. What changed is that a flat undifferentiated list of twenty-plus modules became collapsible groups, and that hiding the menu stopped being a trap: the previous behaviour opened on hover but required a click to put away.

Three modes because the feedback sessions produced three genuinely different working styles — people who want the menu permanently open, people who want a thin rail, people who want the screen entirely to themselves. Cheap to build, and it ends an argument that has no correct answer.

Pages inside the product, opened as tabs above the breadcrumb, each holding a different dataset or report, each renamed by the user. Work in one browser tab instead of a strip of them. The breadcrumb stays underneath: a page you renamed still says where you are inside it.

Users were running the platform across many browser tabs because they needed several tables open at once. Browser tabs are the wrong container for that: they truncate to a favicon and a few characters, they all look identical, and they cannot be named after the thing inside them. Someone running one application across a strip of identical tabs is hunting, not working.

The right-hand panel carries its own vertical rail. Behind it: column selection, display density and number format, query editing, chart configuration, access entitlements, sharing, notification templates, dataset linkage, review scheduling, visibility restrictions. One container, one place to look, one mental model.

Half the rail operates the data. The other half governs it — who sees which rows, who may change them, where the data came from, when it has to be checked again. Both halves are the same container in the same place, because in this product the person doing the second is usually the person who just did the first.

None of these controls were missing before. They were modals and menus attached to different parts of the grid module, and every one of them covered the data it configured while it was open. What people reported was the symptom — the hunt for the right menu, the dialog in the way. Consolidating all of it into one container was the answer to that, and the scope of the consolidation was a design call rather than a request.

The panel also serves two different people on the same screen. The Data and Data Management tabs separate them explicitly: one is reading and analysis, the other is fields, types, data criticality, workflow participation and rights. Two audiences, one product — rather than one product split in half.

Report configuration moved out of a step-by-step wizard and into the panel beside the report. Dataset, name, fields and query conditions are all editable while the resulting rows stay visible. Change a condition, watch the table answer.

The complaint was specific and repeated: to correct a report name you had to walk back through every earlier step, and while building a query you could not see what it returned. The configuration and its result were never on screen at the same time.

Chart type — line, bar, pie, pivot — switches inside one configured widget. Category, values and aggregation stay filled in; the visual type is a property of the chart, not a different object.

The obvious version of this feature is a chart type picker that saves a click. The real reason is downstream. A chart that someone has added to their dashboard belongs partly to them now. Delete it and publish a replacement, and every dashboard holding it goes blank until each person re-adds it by hand. Editing the existing chart updates what they already have. The same rule governs access: a user with rights to a report can put its chart on their dashboard, and only the owner can change it.

A report can deliver itself: on a schedule, to a list of recipients, through a named template. The subscription list answers one question per row — does it still work. Status, schedule, next run, the result of the last delivery, how many people it reached. A failed delivery opens where it sits, showing the addresses that bounced and the repair beside them.

Scheduled delivery is where internal reporting quietly dies, and it dies in two specific ways. A template loses a placeholder because someone edited the dataset underneath it, and the subject line goes out empty. A schedule reaches its end date and simply stops. Both failures are silent, and both are discovered by the person who did not receive something they were not thinking about.

So templates and schedules became objects with their own lists, and each of them says who depends on it: how many subscriptions use this template, which subscription this schedule feeds. A schedule warns days before it expires rather than after it has stopped. Setting a subscription up happens in the panel, beside the report being delivered — and several selected reports produce several separate subscriptions, because each will fail, expire and be renewed on its own.

A dashboard page that holds charts pulled from reports across the whole platform, live. The chart on the dashboard reads the same data its report does — when the underlying dataset moves, the dashboard moves with it. Alongside them, saved entry points to any screen in the product.

Two separate requests met in one surface. Users asked to see the charts from their reports in one place instead of opening each report to check it. And feedback sessions surfaced a habit nobody had designed for: people were copying links to screens they used daily and keeping them in email or in local files, because the platform had no place to put them.

Copying a link to any screen, table or dialog already existed in the product. What is new here is the proposal to make the dashboard the place those links live and open from — Proposed a direction for, not built.

A full rework of the platform's visual identity: a new mark, palette, typography and component language, delivered as a bespoke system built on Material Design 3 rather than applied as a skin over it. Several visual directions were presented; one was chosen and taken through the product.

The brief here was the opposite of the market risk platform, where the instruction was to change as little as possible. This product looked its age, and the visual work was part of the ask.

What the page shows is the system, not the identity: the component sets as they exist in the working file, the surfaces and the type scale, and how all of it behaves on dense tables. The mark itself is client property and not shown.