Hiding a Problem Is a Worse Design Than Showing It
The quotes below are from a usability call on September 23rd, lightly cleaned of transcription filler. The other person on the call was setting the product up for a customer account. The recording was for our own notes, not for publishing, so she stays unnamed.
The call was supposed to be thirty minutes of her clicking around and telling me where she got stuck. The first place she got stuck was a number.
She had been mapping products in bulk in a spreadsheet, and she had used our ID column as the key, because it was there and it looked like a key. Then the mapping came out wrong. She pulled up a SKU on one screen and it said 1374. On another screen, 1374 was something else. “The only reason I found it is because I was manipulating data in a spreadsheet and I was using the ID as the base,” she said.
Every table in our database numbers its own rows. A product and a listing can both be 1374 and have nothing to do with each other. I know that. I had never watched someone build a spreadsheet on top of it.
I defended the column anyway. My reason was support. When someone sends me a Loom or a screenshot with that number in it, I can go straight to the record without asking five follow-up questions. I clicked into a product to show her it was in the URL too, 2249, and in the breadcrumb. “So it’s kind of like everywhere,” I said, which I meant as an argument for keeping it.
“There’s already so much to look at on here,” she said. “If there’s no reason for them to have it, it’s just all back end stuff, then it just should live in the back end somewhere.”
I offered a tooltip. She didn’t want a tooltip. I said I’d go do some best-practice research, and we moved on.
Archived, but still inbound
Later in the call she said she’d exported the current inventory report a few different ways and got a different number of lines each time. The screen we had open said 7,510. She guessed there was a filter somewhere she hadn’t set, then jumped to a different problem before we worked it out, and we never went back to it. The different problem was a product showing about 120 units inbound. She went and looked at the purchase orders for it, and some of them were archived.
“So if the PO is archived, it still shows up as inbound.”
Yes. Archiving a PO takes it out of search and out of the default list. It doesn’t touch the order. Units still due on an open PO count as inbound until they’re received, or until the PO is deleted or put back to draft. Archive is a display flag.
“So what’s the point of archived?”
I didn’t have a great answer. A user asked for it a while back. They had years of old POs they never wanted to see again. It arguably helps performance too, since the default list can skip the four- and five-year-old orders instead of querying all of them. Arguably, because nobody on that call had measured it. What I told her was that archiving a PO that hasn’t been received is bad practice, and I don’t think archiving is a very useful feature.
Then she asked for the thing I said no to. If archive is the wrong tool, she said, fine, give the report a status filter so people can hide the POs that aren’t really open anymore.
“That violates a principle that’s pretty important,” I said. “An open PO that’s three years old is a problem. That’s a user error. There’s no reason a user should have an open PO that they’ve archived instead of dealt with. If we hide it, that’s actually worse, because then it’s a Band-Aid. It’s hiding something that needs to be addressed. I’d rather show it and say: you guys need to deal with this. This is a problem.”
It’s the same rule we follow in the ledger. When a sales channel says an order shipped and the stock was never there, we book the gap as a named amount that has to be cleared instead of letting it sit in a negative number.
She said okay and asked whether there were limits on deleting a PO. I explained that a received PO created inventory, and some of those units may already have been sold, so deleting it runs you through a screen that lists every place they were used and makes you reassign them. “Why is deleting a PO even an option?” she asked. “Maybe it was a mistake,” I said. “No, no,” she said. She meant why does the feature exist. I had answered why someone would delete one.
What changed after
I went back to the ID question after the call and couldn’t make my side of it hold up. The support argument is real, but it’s my convenience, and she was the one who had built a wrong mapping on it.
Two days later we shipped a per-user “Show internal IDs” setting, off by default. With it off, the ID column is gone from any table that has a SKU or an order number to identify the row. Tables where the ID is the only thing you can click, like inventory adjustments, show it as a document number instead: “Adjustment #353”. When I’m debugging with someone, turning it on is one click in their user menu. Exports still include the ID, because our importers match rows on it. Leave it out and an export you edit and re-import creates duplicates instead of updating anything. So the trap she fell into is still there for anyone who joins two exports on that column. I don’t have a fix for that yet.
The PO filter didn’t get built. An open PO from 2023 with units still due is adding those units to your inbound numbers, and three years on they are probably not coming. Hiding it from a report wouldn’t have closed it. The archive button is still there too.
If you want to see the report with a real catalog in it, book a time and I’ll show you.