◎
Important signals surfaced first
The interface separated information that needed action from information that was only available for reference.

OneView had to support product lifecycle work, compliance reviews, risk assessments, approvals, monitoring, and third-party oversight. It also had to connect business accountability, regulatory controls, and the technical platform underneath.
Teams did not need another complete report. They needed to know what had changed, what was overdue, what carried regulatory weight, and who was responsible for the next task.
I led the UX strategy and interface direction, including dashboard structures, prioritisation logic, object relationships, and governance journeys. The designs also had to work within ServiceNow.
For each signal, I asked whether it helped someone decide what to do or only added more information. That meant leaving out some data as well as adding it.
Using briefings, stakeholder input, and artefact reviews, I defined the core objects, the roles that touched them, and the moments when a review or escalation happened. I connected products, owners, controls, risks, third parties, reviews, and tasks in one model, then built role-based overviews that could lead back to the record behind each signal.
The work gave OneView a shared structure for products, risks, controls, reviews, tasks, and owners. Stakeholders could move between an overview and the record behind it.
The project showed me that dashboards work better when they are organised around responsibilities and decisions rather than every available metric.
If I started again, I would define the shared domain model on day one. Every screen, metric, control, and notification depended on it, and agreeing the language earlier would have reduced later rework.