How do you avoid transparency that overwhelms rather than informs?

Sana Iqbal leads rider communications at Meridian Transit Authority. Every delay message a rider reads on a platform screen or in the app gets written by RiderWire, and for six months, it told riders everything it knew.

How to answer this, stage by stage

This is a tradeoff question wearing a transparency question's clothes. Commit to a side fast, then defend it.

Let's learn

Meridian Transit Authority runs RiderWire, an AI tool that writes the disruption messages shown on platform screens and in the rider app whenever a train is delayed.

Before RiderWire, disruption messages were written by hand, usually a rushed one-liner: "Delays on the Blue Line." Riders got a vague warning and no real sense of how long to wait.

RiderWire's first version fixed that by showing everything it knew: "Signal failure at interlocking 4B, dispatcher rerouting via track 2, ETA recalculation pending, headway 14 minutes." Technically complete. Also four clauses long, on a screen most riders glance at for two seconds while jogging toward a platform.

The turn. The raw version wasn't wrong about anything. Every clause in it was true. The problem was that the one fact a rider actually needed, the new arrival time, sat fourth in line behind three clauses of dispatcher-facing detail nobody standing on a platform asked for.

At its worst: riders started ignoring the message entirely, since reading it rarely paid off fast enough to be worth the four seconds, and complaint calls about "no real information" kept climbing even though the messages were, technically, more informative than they'd ever been.

Too little costs a rider a guess. Too much costs them the one fact they came for, and they never even notice it was in there.

What I would leave alone: the ops dashboard that dispatchers actually use, which keeps every technical field visible by default. Dispatchers are trained to use exactly that detail, and curating it away from them would cost real operational time.

Now here is the same thing as a story

The short version above is what you'd say to Meridian's board. Read this one for how the curated sentence actually got built.

Sana Iqbal has run rider communications at Meridian for eight years, and used to write every disruption message by hand before RiderWire existed, keeping each one to a single sentence out of habit, since that was all the old sign boards could physically display.

RiderWire's launch felt like an upgrade in every way Sana could measure. Messages got more accurate, more specific, and never ran out of characters the way the old sign boards used to.

The habit thinned in three beats. First, riders stopped reading the whole message, skimming just the first few words. Then they stopped trusting that the first few words contained anything useful, since half the time they didn't. Then some stopped looking at the screen at all, checking a rideshare app instead the moment they saw a wall of text.

Three versions, same underlying data. Only the middle one actually got read on a moving platform.

The trigger was a colleague's remark at a transit planners' conference, someone from another agency asking, half-joking, "does your AI write for dispatchers or for riders? Because ours reads like it forgot there's a difference." Sana went back and actually timed how long people stood reading a RiderWire message before walking away.

The team considered a middle-ground fix first: trimming the technical version down to two clauses instead of four, and rejected it. Testing showed comprehension barely moved, since the arrival time still sat behind the cause instead of in front of it. The order mattered more than the length.

Everything in the top left belongs in the default sentence. Everything in the bottom right belongs behind the tap.

The redesign put the new arrival time first, the cause in plain words second, and moved every technical field behind a single "more detail" tap that dispatchers and curious riders alike could still reach.

Three items. Everything else RiderWire generates still exists, one tap away, for whoever actually wants it.

I let RiderWire show every field because holding anything back felt like withholding information from riders, and withholding felt like the opposite of transparency. It took timing actual riders walking away from an unread screen to see that showing everything, in the wrong order, wasn't transparency either. It was noise wearing transparency's name.

PICK, in one screenNot a story about a mistake. PICK is what forces a real commitment instead of a wish that all three, speed, completeness, and clarity, could be free.

The recap, one line per letter: position is one plain sentence plus a tap for detail, impact is the rushed rider versus the curious one, cost asymmetry is the 34-to-81 percent comprehension gap, and kill criteria is a real, measured group actually harmed by the default, not a hypothetical one.

And if you want to be sure it really works, try it somewhere elseSame four letters, an enterprise network status page instead of a train platform. The stakes flip, and so does who the curious rider actually is.

Corrigan Networks runs OpsBoard, a status page that shows enterprise customers what's happening during a network incident. Tobias Renkvist runs the network operations team at one of Corrigan's biggest customers, and watches OpsBoard closely during any outage that affects his company.

Mapped onto PICK: position is a curated one-line summary by default, "Service degraded in the East region, restoring by 3:40pm," with full incident logs one click away. Impact is that a casual customer contact loses nothing from the summary, while an ops lead like Tobias, who needs the exact affected node IDs to cross-check his own systems, loses real time if that detail isn't reachable at all. Cost asymmetry flips slightly from RiderWire's case: for OpsBoard's specific audience, more of the readers are technical, so the "curious tap" group is larger, but the underlying principle holds, the default view still has to lead with the one actionable fact, restoration time, before anything else. Kill criteria: OpsBoard actually hit its own kill condition. Enough enterprise customers were technical enough, and needed the full detail often enough, that Corrigan gave large accounts a setting to make full detail the default for their team specifically, while keeping the curated summary as the default for everyone else.

The same tree, with different leaves, is exactly how Corrigan resolved OpsBoard's version of this same tradeoff.

Same arc as RiderWire's, six months instead of RiderWire's shorter cycle, because enterprise customers noticed the overwhelm more slowly than platform riders did.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "one plain sentence by default, full detail one tap away," and stop.
Cost: there's no budget to build a tap-through detail view this quarter. Say so honestly, and ship the curated sentence alone first; it's the cheaper half of the fix and it closes most of the comprehension gap on its own.
The model gets better, for real: if RiderWire's underlying predictions get more accurate next year, the curation decision doesn't change. A more accurate technical detail is still technical detail, and still doesn't belong as the default on a platform screen.

Where people run it wrong.
They treat showing more as automatically more honest, when an unread wall of text is less informative than a read sentence.
They test whether a message is accurate, but never test whether anyone can actually find the one fact they needed inside it.
They pick one universal level of detail instead of a default plus an escape hatch for the smaller group that genuinely wants more.

How to use it live. When someone asks how to avoid overwhelming transparency, ask yourself one question first: if a stranger read only the first five words, would they know what to do next? Design the default around that answer, and put everything else one tap behind it.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0