Modernising parliamentary information management
Replacing fragmented document workflows with a single source of truth
Client details removed to respect confidentiality. Built on ServiceNow's Horizon design system.
Live Proceedings, the screen an officer uses to run the order of business and record each outcome as the chamber decides it. The record is official, so it can't change by accident.
Snapshot
Sector: Public sector (a national parliament)
My role: Lead designer, end to end
Team: Strategist, solution architect, engineer, and me as sole designer
Platform: ServiceNow — a Chamber Information Management workspace, a parliamentarian portal, and two custom drag-and-drop surfaces
What I did: interviews and current-state mapping, collaborated on the service blueprint, created the future-state journey, prototyping, evaluative testing, and the full UI, including two custom surfaces the platform couldn't do on its own.
Every sitting day, a parliament produces a set of official documents, and each one has to be accurate, some of them constitutionally significant. The systems behind them were decades old: Word templates, copy-paste between systems that didn't agree, and a records tool that only let one person work at a time. I helped redesign the model underneath all of it. The main problem wasn't any single screen. It was whether staff could work the same records at once, produce accurate documents without retyping, and still get the printed papers a sitting day needs. The work shipped into implementation. I worked on the Senate experience.
The problem
A single motion passes through five people before it's finished, and each one waits on the person before them. Everyone worked from their own copy of the data, so the copies drifted apart and mistakes crept in, and no two people could work at the same time. The problem wasn't the individual screens. It was that each document was produced separately, which made the waiting and the retyping unavoidable. What had to change was where the system kept the source of truth.
My role
I was the only designer on the project, working with a strategist, a solution architect and an engineer. I participated in user interviews and the current-state mapping, and in the two-day HCD workshop where we agreed the future state. I built the future-state journey and did everything after it: the prototypes, the testing, and the full UI. Two of the surfaces, Live Proceedings and the Document Generator, didn't exist in the platform, so I designed them from scratch. The rest I designed on top of capabilities the platform already had.
The design problems
There were three main problems to solve. One set of records needed to produce every document, without anything being copied between them. Several people needed to work the same sitting day at once, instead of one after another. And decisions made during a sitting had to be recorded quickly and accurately, on a record where a mistake matters, because some of these documents are constitutionally significant.
Decisions and trade-offs
One shared record. The main decision was to stop treating each document as the thing people work on, and treat the underlying business item as the record instead. Once each motion, notice or bill exists once, as a record, every document is just a view of those records. Building a document means selecting and ordering records, not writing from scratch, and recording an outcome updates it everywhere it appears. That one change removes the copying, the waiting and the mismatched versions together.
A single motion followed across all five roles and every surface it passes through. The same shared record sits underneath all of them.
Two separate tools. Live Proceedings and the Document Generator use the same records but have different interfaces. Assembling a document ahead of a sitting is slow, careful work; running the chamber live is fast and can't afford mistakes. They're different jobs done by different people, so I designed each one for its own task rather than making one tool do both.
A soft lock instead of last-write-wins. Several officers work the same sitting day, so two of them will sometimes open the same item. Rather than letting whoever saves last overwrite the other, the item shows who is editing it and holds it until they're done. It's a little more work to build, but it avoids one officer silently overwriting part of an official record.
Corrections are logged, not silent. Changing something that has already been published is treated as a correction, not a normal edit. It asks for a reason, records what changed, and marks the item so the change is visible. Officers can still fix mistakes quickly, but nothing on the official record changes without a trace. The history itself came from the platform, which logs every change automatically.
Publishing works as a set of states. Officers edit a draft only they can see, and publishing is a separate, deliberate step; the interface shows when the draft is ahead of the published version. A change to something already published is logged as a correction with a reason and a before-and-after, and edits made offline are reconciled rather than overwritten.
Designed for print. Chambers still use printed documents during a sitting, so print wasn't an afterthought. The builder previews in the browser as you assemble a document, then produces a Word version through the platform's document plugin.
The solution
Two of the surfaces were custom-built, because the platform couldn't do them out of the box. They're where most of the design work went, so I'll go through them in detail.
Live Proceedings is the officer's screen for running the order of business live and recording what the chamber decides, item by item. It's in three parts: the day's order of business runs down the left, a marker shows which item the chamber is currently on, and a panel on the right is where the officer records the outcome for the selected item. That panel changes to suit the item, since some are voted on, some debated, some tabled and some simply noted, so it shows the right options for each rather than one generic form. When an item goes to a recorded vote, it opens a step-by-step flow for a division: the bells, the doors, the tellers, the count and the declared result. Several officers can work the same day at once while the public follows along, so the screen keeps two versions: a working copy the officers edit, and a published version the public sees. Publishing is a deliberate step, and any change to something already published is recorded as a correction, with the reason and what changed. The rule behind all of it is simple: the record is official, so it can never change quietly.
The order of business runs down the centre, with a marker for where the chamber is up to and a panel on the right that changes to match the selected item.
Recording a division. The officer is taken step by step through the bells, doors, tellers and count, rather than filling in a blank tally.
The Document Generator is where a sitting day's documents are put together. It has two parts: a searchable list of business items on one side, and the document being built on the other. You find the item you need and drag it into the right section of the document. Nothing is retyped, because nothing is being copied; it's the same records, arranged into a document. The same list builds every document a sitting day needs, the Order of Business, the Dynamic Red, the Notice Paper and the Journals, so they can be built at the same time from one source instead of one after another. It had to be custom because, in the platform, this content lives in lists and tables, which are fine for storing records but not for building a document out of them. You search or browse for an item, drop it into place, preview the document in the browser as you go, then export it to Word for printing.
Business items are searched or browsed on the right and dragged into the document, section by section, on the left.
The same builder produces every document. The Order of Business, Dynamic Red, Notice Paper and Journals are all assembled the same way, from the same records.
Creating and previewing a business item, so its wording is correct before it's placed in a document.
I designed the other surfaces too, the parliamentarian portal and the tracking page, but these were built on capabilities the platform already had, rather than from scratch like the two above.
The portal, a single place for parliamentarians to lodge motions, questions and postponements, replacing a mix of channels and hard copy.
My Business Items, where a parliamentarian can track each of their items from notice given through to resolved.
Impact
The work was built and put into service. Because everything ran on one shared record, the copying and the waiting were gone: a whole sitting day could be worked on in parallel, and the printed documents came out without anything being keyed in twice. I don't have user metrics to share, and the client is anonymous, so the main thing I'd point to is that a system this sensitive, handling official and in some cases constitutionally significant documents, was trusted enough to go into service.
Reflection
The main thing I took from this project is how much a single structural decision can do. The concurrent editing, the lack of retyping, the parallel documents, the public view that can't contradict the record, none of those were features I designed one by one. They all followed from one earlier decision: making the business item the record. Often the most important design decisions aren't on the surface people see; they're in the model underneath it.