Reviewing policy exceptions and rule changes

Put the request beside the decision

A policy exception asks permission to do something outside an existing policy. The reviewer needs to understand the request, why it is necessary, and what will reduce the risk. I explored that review experience alongside the submission process.

Make the review easier to scan

I tightened the typography and spacing so reviewers could scan the case, reduced the demo controls, and corrected the header colors. I kept the sample-data warning and role switch separate from the review controls.

Use the prototype to settle the open questions

In the April walkthrough, the business owner explained that there was no fixed committee quorum. Someone needed to record the final decision after the appropriate people had responded. The later requirements assigned that responsibility to a Compliance coordinator.

She also pointed out that someone seeing the prototype for the first time could mistake the sample requests for real cases. It needed a clear dummy-data label. After the walkthrough, she asked for the link to share with her team.

These earlier prototypes retain their own review models. They do not implement the later coordinator stage. The HTML walkthrough uses Deny and Audit trail; the later requirements use Decline and Version History.

Show the impact before asking for approval

In a separate assignment, I mapped a portal for proposing changes to business rules. A requester would test a change and attach an impact assessment before submitting it for review. Engineers retained control over applying the change.

Keep the handoffs moving

The proposed flow returned rejected requests with feedback, routed submissions to reviewers, and sent reminders when a response was missing. It also included escalation and reminders for users to acknowledge a change. Engineers remained responsible for applying approved changes.