Your admin screens need a journey

When I worked for an online printing company, setting up a new product in the catalogue took around fifteen admin screens.

They weren’t joined up. There was no defined order to work through, and nothing in the admin to tell you that you’d missed a step.

We never put a product live with missing options. But that wasn’t the screens working - it was training, and a build-and-test cycle that took far longer than it needed to.

Every new product or product group needed something the existing setup didn’t cover. There was a constant balance between hard-coding a special case and extending the admin screens to handle it. New things usually needed both.

Most new requirements spawned another admin screen. This meant the overhead for the catalogue team grew with every product we added.

We were also under time pressure, so there wasn’t much opportunity to do more than the basic necessary work. The screens themselves were fine. What they lacked was any sense of being part of the same task.

Every screen we built to make their job possible was another screen they had to fill in.

A new product wasn’t a single job. It was fifteen separate jobs, spread across screens that didn’t know about each other.

There was nothing to help you set up a new product as a set of sequential steps - and nothing that would tell you which bits were missing.

So that meant training people on how to do the setup correctly, and in which order. Products were always tested before going live. Testing was the only step that could catch gaps or errors. If a product was wrong, we found out by building it, then trying to order it.

None of the screens were wrong - but they led to a cost for the catalogue team, in the time they spent setting things up.

If you need training and a test pass to know whether you’ve finished a task, the journey is the thing you haven’t built.

A good example of this: we had two ways to control which product options could be selected together.

The first was for paper. We knew the valid combinations up front, so we modelled it as a linking group: pick one option from each group, and only the combinations that existed were selectable. Choose a paper type and the invalid paper weights disappeared.

Later we needed restrictions across a much wider range of items, where listing every valid combination wasn’t realistic. So we did the opposite: everything was allowed by default, and we set the exceptions.

We were mixing inclusions and exclusions. Both were needed, but they worked differently in admin, without a clear explanation why. If you were configuring a product, you had to know which kind of restriction you were dealing with and which screen it lived on.

It’s the same problem as the fifteen screens: separate setups that didn’t know about each other. This time the customer felt it too - some options vanished, while others let you choose them and then told you that wasn’t allowed.

Data was a challenge, particularly as more stakeholders wanted to know how things were performing.

One person would ask for a report, which I’d build. Then someone else would ask for a similar report, which I’d build too. You can probably see how this quickly spiralled.

I think we reached 70+ reports, which created a large overhead for the small tech team. Some reports were very similar, some hadn’t been used beyond the initial request, and it became harder to know which reports were the most valuable.

There was also the mega report. Everyone used it, people kept asking for new fields, and it was slow to run. That one was a pain, and it was the first one where I started pushing back - we were reaching the limits of the current approach.

It was clear we needed a better way to manage reports.

I’ve written about this before. Back in Quick Product Tips I argued you shouldn’t build every report, and that some reporting is better farmed out to a proper tool. That was the right instinct, but I stopped at “take a pragmatic approach”, which didn’t say what to do instead.

Since working on those reports, there are a couple of tips I’ve learned.

Building isn’t always the first step. Focus on having a read-only replica of the database with reporting tooling on top. Give people a set of pre-made reports they can customise, and help them build their own. It’s a common enough setup and I’ve seen it work well since. The one-more-field request stops being an engineering ticket and becomes something the person asking can just do.

Keep a small number of dashboards in the product itself for the at-a-glance and near-real-time stats, with light customisation. Those can work well as admin screens.

Build the sequence, not just the steps. Setting up a product should have been a journey with a beginning and an end. It can start as a set of disparate steps - but as the number of steps increases, the need for a wrapper on top increases with it. Having a clear order, visibility of what’s done and what’s still to do, and validation for any issues or gaps would have helped a lot here.

Where a product falls short, its users can help to fill in the gaps with training and testing. But it’s not the best long-term solution.

It was hard to spot how big a problem this was, because nothing broke. The steps were being diligently followed outside the system.

If your users are the integration layer, the product isn’t finished. It’s just being propped up by the people who have the manual steps in their heads.

Product Notes is free and lands every week. Subscribe to get it in your inbox.