A report anyone can start

MaintainX is the CMMS frontline industrial teams use to log work orders, track assets and keep plants running. I joined in 2025 as a senior product designer, and later led design across Reporting, Search, Automations and Chat. When Autodesk acquired MaintainX in 2026, I moved to asset intelligence.

This case is about the first thing I picked up there, a week in: a custom report builder, and what happens when people know exactly what they want to see but can’t get there.

Role

Senior product designer, design lead for reporting

When

2025

With

A product team and five to seven engineers

Scope

Custom Report Builder, from an early version to a real product

The decision

Ask what you want to report on, instead of asking for a data source, and build the table before choosing the chart

What changed

The builder became easier to start, though some of its complexity stayed; the AI version, whose first iteration I designed, builds the table from a sentence, and the manual builder stepped aside

Everyone wanted reports

MaintainX works a bit like a Jira for maintenance. The people who run operations kept asking us for more and better dashboards, our competitors all had some kind of reporting, and we were thin there. Reporting was also where MaintainX had to prove what it sells: that it helps you fix machines before they fail and run a leaner operation.

When I arrived there was a reports section, and underneath it the data models were still being built so the information could be used at all. The custom report builder was supposed to let anyone build the report they had in mind. It was very hard to use. Tables had to be joined, the same dimension meant different things in different contexts, and you had to know the difference between an average and a median.

In user sessions people told us the same thing in different words: I know what I want, I can picture the table, I don’t know how to get there. The product team was new, me included, and I know data models and analytics tools. If I couldn’t use it, how was I going to explain it to anyone?

Editing a table is easier than starting one

Our first move was templates. The premise held up every time we tested it: show me a table and I’ll edit it. People could read a table and change it, but a blank builder gave them nowhere to start. So we started from the metrics everyone asks for, mean time to repair, total inventory cost, the kind of list you would get from searching for the most important maintenance metrics, plus the tables customers kept requesting because a business metric had been requested of them.

The selector grouped them by what they were about, work orders, asset health, parts and inventory, cost, and kept a way out at the bottom of every list: if the template you needed wasn’t there, you could build it yourself.

One question instead of a data model

Joins have two classic traps. In a fan trap a join quietly repeats rows and a sum comes out inflated; the chasm trap is its cousin, two tables meeting through a third, and the counts go wrong again. Our first answer was a setting called primary data source, and in tests people given a task did not even know where to start.

So we turned it into a question: what do you want to report on? People could answer that one. Reporting on employees or on money, for instance, sums the tables differently, so the answer decided how they were joined. We used to ask for the secondary sources up front too; that was painful, so it went. You pick what the report is about, and add any column you like afterwards, with no limits. I am not sure that was the best answer to the fan and chasm traps, but it was a way through, and people could use it. Some complexity stayed after the rename: the builder was understood a bit better, not fully.

Most of this came from watching the product in use, and from using it ourselves. Our own usability questions were too generic at first (what do you think this means?). It helps that MaintainX stays very close to its customers: we could call back and ask again, and they answered.

The table before the chart

The first builder opened on the chart. Five tiles sat at the top of the panel, table, bar, line, pie and gauge, and the data came after them: an X axis, a Y axis, a column to segment by. When we tested it, that order turned out to be the opposite of how our customers thought. They built a table with the data first, and only then shaped it into one chart or another. It surprised us.

The order had a cost you could feel, too. Each chart type kept its own slots, and a pie had only two, so switching from a bar to a pie could drop a column on the way. For a formula that needs three or four inputs, that was a dead end.

So we turned the panel around. Data and Dimensions came first: you pick the columns and the table builds itself as you go, live. Visualization moved under it, as a choice you make once the data is right, and each chart takes the columns it needs from the table without throwing the others away. The empty builder said it in so many words: build your table, live.

A formula is one more column

Custom formulas came next. The metrics everyone asks for were already on the Reporting page, mean time to repair, mean time between failures, downtime hours, cost per work order, but every operation counts its own, and without formulas teams exported the data to a spreadsheet to finish the sums by hand. We wanted to prepare a dimension for people instead of asking them to build it: price times quantity, already turned into the value of the parts in stock.

In the new panel a formula is one more row under the columns, since both add a dimension to the table. Adding one gives every column a letter, A, B, C, and you can write with the letters, with the columns’ names or with the names you gave them, mix the three, and use one formula inside the next. The column fills in the moment the formula is entered, so you can see whether it is right before you trust it.

Because the chart now reads its columns from the table, the formula survives the chart. You pick the series, the value of the stock here, and switch between a bar, a line, a pie and a gauge against a target, and nothing has to be added again.

The formulas had real limits, and each one was a limit of the query underneath: a formula starts from columns already in the table, works inside one dataset, and handled numbers and dates before anything else, and a heavy one could time out on a big dataset. Every capability like this opened the old question again. Do we stay with primitives, or ship combinations? And behind every metric the details got worse. The cost of a technician is a different number if you count the time spent on the machine or the time the work order stayed open, and work orders are rarely opened and closed at the moment the work happens.

When the chart stopped needing the builder

Then the AI boom arrived, and it moved faster than any interface we could ship. You could ask for a table in a sentence, how many work orders did my morning shift close, and it would do the joins for you and get it mostly right. You can still edit the result and save it, which is the template idea all over again: the AI builds the first table, and you edit it. Templates stayed too, and they also served plans without the top Enterprise tier.

Its first version, the one I designed, lived inside the builder. A button opened Copilot, you wrote what you needed, and it built the report in the same panel you would have used by hand, then asked you to check the data before saving it, and whether it had helped.

In the product it settled into a simple shape. At first the builder opened on a choice: start from a template, build a custom chart, or start with AI. Later one button in Reporting opened a small modal with two ways in: answer what you want to report on and start building right there, or tell the AI what you need. The templates, once the front door, moved to the side. Either way you land in the report builder, and when you save, the report becomes a page of its own where every chart you made is a widget.

Six small things from the builder, close up and set moving: the letters a formula writes with, the five ways to show a table, Copilot at work, a column that is a formula, the live update, and the question every generated report ends on.

The builder already existed when I arrived, and we took it to something real. I designed that, and the first iteration of its AI version, and then moved on to other parts of the product before the story ended. As far as I know, it is now mostly AI, a friend told me people used the language version a lot, and the manual builder stepped aside (very elegantly): it still works, it is just not the front door. That is the part I find most interesting: the data underneath moved faster than we could make a clickable builder usable, and the AI skips the builder and shows people the chart they wanted.

It was a hard way to start at a company: a week in, on data models, with a team I didn’t know yet, in another country. I don’t know what I would do differently. The bet on leaning into AI was the team’s, more than mine, and a year later 2025 already feels like the stone age.