Read acknowledgement feature
Turning a passive metric into a deliberate, auditable user action; under real constraints.
WorkJam channels could already tell you who had seen a post. What they couldn't tell you was whether anyone had actually read it. For most posts, that's fine. For the ones that matter like new safety protocols or policy changes, the things a company needs a paper trail for, "seen" isn't enough. I led design on the feature that closes that gap: Compliance Read Acknowledgements.
The temptation with a feature called "read acknowledgement" is to bolt a checkbox onto every post and call it done. That would have shipped faster. It also would have trained users to dismiss the checkbox the way they dismiss cookie banners, defeating the entire point.
The real problem wasn't can we capture a confirmation. It was can we make the confirmation mean something. Every design decision downstream came back to that question.
One of the first debates was whether acknowledgement requests should be dismissible. Forced is more rigorous; dismissible is more humane. Hardcoding one behaviour would have forced channel owners to either over-pressure their employees on every post or under-protect their compliance trail. We made it a per-post configuration. A safety bulletin in a warehouse can block the user until they confirm. A reminder about an updated dress code doesn't have to. The configuration lives where the context lives: with the person creating the post.
When a user dismisses an acknowledgement, it reappears next session under the same logic. Dismissible doesn't mean optional. It means not right now.
Channels already had a "viewed" framework that fires after a post sits in the viewport for two seconds. Reusing it for acknowledgements would have been technically cheaper and architecturally cleaner. We didn't reuse it. The user has to scroll to the bottom of the post and tap Acknowledge manually. Reactions and comments are blocked until they do.
This is the decision I'd defend hardest. Auto-acknowledgement on a scroll timer would have generated a legally weak audit trail and conditioned users to ignore the signal. The friction is the feature.
At first we agreed (PO and I) on this statement: Editing a post would reset its acknowledgement state, end-users would need to re-acknowledges. We changed that. If a post has an ongoing acknowledgement process, content and audience edits are blocked entirely. Owners can still adjust the duration, cancel, or delete; they just can't quietly mutate what people are agreeing to.
This sounds restrictive. It's actually protective, of the user, who shouldn't unknowingly acknowledge revised content, and of the channel owner, who now has a defensible record. The system surfaces a clear message explaining why edit is blocked and what to do instead. Resetting acknowledgements on edit became a configuration for later, not the default.
The hardest scope conversation was mobile. Mobile users see acknowledgement requests and indicators, full parity on the acknowledging side. But the dashboard for reviewing who has and hasn't acknowledged is web-only.
The people chasing down non-acknowledgers are desk-based admins or managers running follow-ups, not frontline workers on a phone in a store. Building the review UI twice would have either delayed launch.
In this project, 3 things came out of scope: acknowledgement on duplicate posts, the option to add acknowledgement to already-published posts via edit, and the standalone admin dashboard for cross-channel acknowledgement review. Estimates had inflated; the team was at risk of shipping late and diluted.
Duplicate-post acknowledgement was the cleanest to remove, owners can configure acknowledgement on the new post manually. The admin dashboard was harder. We compensated by making the acknowledgement user list reachable directly from each post, which covers the most common workflow (one owner chasing one post's non-acknowledgers) even if it loses the cross-channel view. The feature shipped lean and provable. The advanced compliance tooling has a clear path to follow.
The things I'd track post-launch: whether the manual scroll-to-acknowledge interaction holds up against the temptation to tap through, whether channel owners overuse "forced" acknowledgement for posts that don't warrant it, and whether the web-only review constraint actually holds or whether mobile admins start asking for parity. The success metrics are defined. The interesting question is which assumptions break first.
This feature isn't visually very ambitious. It's a checkbox, a button + banner, and a list. What makes it senior-level work isn't the UI but the decisions about where to add friction, where to refuse it, what to cut, and what to refuse to ship even when it would have been faster. Compliance features fail quietly when they're designed for the easy case. This one was designed for the case where it has to hold up.