Flow Checker redesign
Facebook started blocking messages sent without a tag describing their purpose. My team built the Flow Checker so users could make sure every message was tagged — then power users started complaining, and I went to find out why.
The problem
Users were complaining in the community about the Flow Checker, and a user video showed the problem clearly. Around 18 users of different levels — many of them power users — commented on two angry posts. I reached out to them with a short survey. Everyone said the same things:
- It asks me to tag messages that will be sent within 24 hours, which don’t need tags.
- It keeps popping up while I’m working and testing flows.
- It jumps me away from the node I’m working on to an untagged one.
Finding a solution that fits
Users imagined three ideal fixes: a checker that reads the flow’s context, a way to turn it off, or a checker that only reports problems and lets them decide. I weighed each against the constraints — this was a redesign, not a rebuild — after talking to developers:
- Reading context needed heavy backend work and many edge cases.
- Turning it off raised hard questions: who gets the option, and how do beginners avoid hurting themselves?
- “Don’t check this again” meant storing excluded nodes per user, a lot of work for limited benefit.
So I proposed separating fixing from notifying: no more automatic jump to the first problem node, and a small alert on publishing instead of a widget that covers the canvas.
How the new checker works
The behaviour depends on where the user comes from. Arriving from the “fix it” page means they’re ready to fix things, so the checker opens expanded and shows every error type. Opening a flow as usual shows only the errors that make sense in that context, collapsed.
Problems are fixed one at a time, with progress screens in between. For errors the system can’t point to exactly, nodes with the relevant content type get a yellow outline — yellow because red means error — and the widget collapses to a tooltip so it doesn’t hide the flow.
Measuring it
I defined new analytics events and success criteria: more tagged bots (bots with over 70% of flows tagged, then around 40%), fewer undelivered messages tagged Other and OTN, and the share of users who fixed their issues in the widget without hitting them again.