Start With Imagination, Not Code

Lessons from Building a Shared Legislative Platform

I recently chatted with Matthew Lynch, who works for the UK’s National Archives and is service owner for Lawmaker — a shared legislative drafting and publication platform now used across multiple UK parliaments. To my surprise, we spoke about the role of creativity in building legislative platforms, and how Lawmaker evolved by reimagining possibilities rather than simply updating existing tools.

Matthew Lynch is a Service Owner for the UK National Archives' Lawmaker, a browser-based tool for drafting and managing legislation for the UK and Scotland.

Lawmaker offers a compelling case study in what can happen when vision leads the way — and when digital transformation is treated not just as a technical challenge, but as a creative, collaborative process. I hope it will inspire you!

Highlights:

• Reimagining the Process: Challenging the status quo, focusing on what could be, not just replicating what was.

• Working Together: Collaboration among institutions like the UK and Scottish parliaments was crucial for overcoming legacy challenges and pooling expertise.

• Navigating Challenges: How different visions and informal beginnings were managed before formal agreements took shape.

• From Prototype to Production: Early wireframes and prototypes helped build confidence and support, setting the stage for a fully developed system.

• Digital Transformation: Lawmaker is a browser-based, cloud-hosted platform that modernizes legislative drafting and publication by leveraging structured data.

• Innovative Features and AI: New tools, including AI enhancements to clarify legislative amendments, are making the system even more effective and transparent.

• Practical Advice for Innovators: Starting small, experimenting with prototypes, and maintaining ownership to ensure the tool meets real user needs.

Beatriz Rey, Ph.D.

---

Beatriz: Thanks for taking the time to talk with me. I’d love to hear more about the tool you developed.

Matthew: It’s called Lawmaker.

Beatriz: Yes, I love that name! I was hoping you could walk me through how Lawmaker came to be adopted and what exactly it does.

Matthew: That’s one of the most interesting aspects of this work — not so much the technology itself but figuring out how to make these things happen. How do you get people to agree to adopt a new system? How do you get them to pay for it? Those challenges are often more complex than the tech side. In the UK, we don’t have a federal system like the US, but we do have a similar structure in some ways. There’s the main parliament in Westminster, and then devolved parliaments in Scotland, Wales, and Northern Ireland. So, while they're not states, they function in a comparable way in terms of having their own legislative bodies. Spain, for example, has a similar structure with the Catalan Parliament and other regional jurisdictions. Each of these UK jurisdictions was using its own software to manage legislation. On top of that, we had a completely different system for handling secondary legislation — things like rules and regulations issued by government agencies and departments. So, we had this patchwork of tools.

The only point where everything converged was at the publication stage. For the past fifteen years or so, we’ve had a single platform — legislation.gov.uk — where we publish all enacted legislation. Once a law is passed, whether in Westminster, Scotland, or Wales, it’s published there. But behind the scenes, all that content was coming from different sources, using different systems. The responsibility for publishing that legislation falls to the organization I now work for: The National Archives. We're also known, somewhat grandly, as the King's Printer — and we hold that title not just for England, but also for Scotland, Wales, and Northern Ireland. We've held that responsibility for some time, but historically, we just worked with whatever formats and systems each jurisdiction provided. That all started to shift in the early 2010s. At the Westminster level, there was growing recognition that the existing tools were no longer fit for purpose. Scotland was going through the same realization. That’s when the push for a new, unified solution really began. Wales and Northern Ireland had adopted similar tools — they kind of went their own way. But Scotland and Westminster were in a different place. They both knew something had to be done about their outdated systems. One key difference between the UK and the US is that the legislative process here is much more of a shared endeavor between the executive and the legislature.

Beatriz: Because it's a parliamentary system.

Matthew: Exactly. It’s formally the parliament that passes legislation, but the process is largely driven by the executive. That means, in both Westminster and Scotland, the tools used for legislation are shared between the executive and the legislature. Since the executive drafts most of the legislation, it's crucial that both branches use the same systems.

Beatriz: So the push for change came from within parliament?

Matthew: Yes, but it wasn’t just parliament — it was always a kind of dual initiative. In both cases, it was the executive and the parliament coming together and saying, “We’re not happy with our current tools. We want something better.” At first, it was just a case of software renewal — our tools were outdated, and that got the ball rolling. But at the same time, there was a broader shift happening: both the executive and parliamentary sides were embracing a digital-first agenda. We needed to rethink our processes around digital workflows, rather than continuing to shape everything around paper.

One of the big holdouts in that shift was the legislative process. It remained heavily dependent on printed documents. Even things like parliamentary amendments and debates still relied on physical copies of bills and printed materials. So there was growing recognition that we needed new tools — and that those tools had to be digital. As I’ve said elsewhere, we introduced digital tools 20 or 30 years ago, but those tools were just there to help us produce paper more efficiently. Everything was based on Word or Adobe FrameMaker — essentially desktop publishing software. It wasn’t about transforming the process itself; it was just about making the existing paper-based process a bit easier to manage.

Beatriz: The real shift wasn't just adopting technology but using it to fully digitize the process.

Matthew: That’s been our push all along. We had Westminster and Scotland realizing their tools were reaching end-of-life. They wanted something new, and they were aligned with this broader digital agenda. Meanwhile, at The National Archives — which is responsible for all secondary legislation — there was a similar realization. By a historical quirk, The National Archives isn’t just the publisher of secondary legislation; it's also responsible for providing the drafting tools used by lawyers across government. And those tools were just as outdated — Word-based systems that needed replacing. Given that we were already publishing all legislation, and that digital consumption of legislation had far outpaced printed use, we had a strong argument. These days, while legislation is still printed in nice volumes, those mostly just sit on shelves. What really matters is the digital version — that’s what people use. So we argued that if legislation is now primarily consumed online, the entire legislative process should be oriented toward digital outputs. We needed to model the entire workflow around digital use, not just printed documents. I think it was around 2012 to 2014 when these initial conversations started happening.

Beatriz: And you said the early stages of this began around 2010, right? At that point, the internet was already widespread, so people were using it to follow legislation.

Matthew: Yes. But even though the internet was widely used, things still take time to get off the ground. We had the ideas in place, and at one point, it looked like each jurisdiction was about to go off and build its own system. But, fortunately, thanks to some conversations and connections, a small group came together — including people from Scotland, the UK Parliament, and The National Archives. At the time, I was working in the Scottish Government, in the legislative drafting office. That’s when we started thinking: rather than each of us building something separately, why not work together and create a new tool we could all use?

Beatriz: From what you're saying, this was very much a collaborative process between the UK Parliament, the Scottish Parliament, and The National Archives. As you continue telling the story of how it all developed, could you also highlight some of the hurdles or difficulties in coordinating the interests of those three institutions?

Matthew: Absolutely. And actually, because of the way our system works, it quickly expanded to more than just three institutions. It became a collaboration between the Scottish Parliament, the UK Parliament — and within the UK Parliament, you have two separate houses, each with its own legal and corporate identity. So, depending on how you count, we were working with five or six separate partners. We couldn’t even fully agree on how many there were! So yes, coordination was a big challenge.

Right from the beginning, people had different visions. Some just wanted a basic software replacement — something like “I just need a better version of Word.” Others had a much broader vision: they imagined a fully digital, paperless legislative environment. We were navigating those tensions. One way we managed that was by not aiming too big at the start. For quite a while, there was no formal agreement to do any of this. It really started from a genuine spirit of collaboration: a few people thought, “Wouldn’t it be great if we could do this?” Then the next question was, “Does anyone have a bit of funding to explore the idea?”

It was very much a classic "invest small in high-risk ideas and fail fast if necessary" approach. There wasn’t a significant financial commitment from all the partners, and not everyone signed on from the start. Some organizations were more willing than others to contribute early on, either with funding or staff time. We agreed that if it moved forward, we would recognize those early contributions and share the overall costs fairly down the line. It all began quite informally. One organization had a little bit of money, another had staff with some time to spare, and we had a supplier — originally contracted to manage our website — who had some R&D capacity. That allowed us to start developing the software without going through full procurement. We weren't even thinking yet about building a final product — we just wanted to see if it was viable.

Beatriz: But if you’re doing all this informally at first, without contracts or formal commitments, how do you ensure people stay engaged and committed?

Matthew: Well, early on, people were only committed to the small, exploratory phase — mainly through funding or in-kind contributions. But once we got past those early hurdles and had something concrete to show — like a prototype or some research results — we could go back to everyone and say, “Look, here’s what we’ve built, here’s what we’ve learned. Are you now ready to formally commit?” That’s when we moved into a more structured phase. We launched a formal procurement process to build the actual system. At that point, we established a Memorandum of Understanding (MoU) among all the partners. That agreement committed everyone to sharing costs and staying involved for at least three to five years. And from there, the organization I work for — The National Archives — took on the lead role.

Beatriz: How many stages would you say the process had?

Matthew: That’s a good question. One thing we did very early on — and I think it worked well — was to partner with an agency that specialized in user research and interface design. Before we even thought about the technology, we started by imagining what the system could look like. We created wireframes — just basic mockups — based on the anecdotal frustrations we’d heard from users. This was still in the “small group discussions” stage, just a handful of people from different organizations. We invested a small amount of seed money — just a few thousand pounds — to design those wireframes, like a “fantasy software” exercise. Then we took those wireframes on a kind of roadshow. We visited all the potential partner organizations and sat down with the people who would be using the system. We showed them the mockups and asked, “Do you like this? Does this make sense for your work?” It wasn’t about business cases or procurement documents — it was about getting people genuinely excited and engaged.

Beatriz: It sounds like the project was also an exercise in imagination — and that’s how you got people on board. Would you agree?

Matthew: I think you’re totally right. And honestly, the public sector isn’t always great at that kind of imaginative thinking. I give a lot of credit to my current boss — someone who’s always had a bit of a visionary streak, someone who’s willing to explore the unknown and take a few risks. That mindset made a big difference. It’s a bit like agile development — you show something, you iterate, and you learn. Paperwork and rigid procurement processes can be deadly for innovation.

Beatriz: But eventually, you did get to that more formal stage, right?

Matthew: Yes, but it was much easier by then because we already had momentum. And when it came time to work with suppliers, we didn’t just hand over a long list of requirements. Instead, we showed them the wireframes and said, “This is what our users want. Can you build it?” It wasn’t just conceptual either. After we had the wireframes, we started creating prototypes. We went to our initial supplier — again, using existing contracts — and asked them to build some of those designs into working models. That allowed us to experiment without having to engage in a lengthy procurement or worrying too much about major costs. Then, when we moved to formal procurement, we didn’t start from scratch with a huge document of technical specs. We had working prototypes. We told potential suppliers, “This is what we’ve got. What we’re looking for now is a development partner who can take this and build it into a real system.” We gave them an indicative list of requirements, but made it clear the project would continue to evolve. It wasn’t a waterfall project — we weren’t delivering a finished blueprint. It was more like: “Here’s where we are now. Help us build the rest.” Yes, it still overran a bit, and yes, it cost more than we originally hoped. But the dialogue with suppliers was better and more productive because we had a clear, shared understanding of what we were trying to build.

Beatriz: And the supplier who eventually built the system — did they deliver it for both the UK and Scottish Parliaments?

Matthew: Yes, it’s one system. We’re running it as a shared public service. The way it’s structured now, The National Archives essentially acts as the service provider. We operate it like a software-as-a-service (SaaS) model. Each of the partner organizations pays an annual fee. We calculate the total cost and then split it across the different partners. From their perspective, they’re just paying for a service — but what they’re actually getting is access to a shared, purpose-built legislative drafting and publication tool.

Beatriz: Could you tell me a bit more about how Lawmaker works in practice? For instance, from the perspective of a legislative officer — someone working for an MP—how might they use the software? How does it function day to day, and how does it make the legislative process easier, if that makes sense?

Matthew: The key feature of Lawmaker is that it’s entirely browser based. It’s hosted in the cloud, which means there's no need for any of our partner organizations to maintain servers or install software on users' devices. That setup makes it much easier to provide access to multiple organizations across different jurisdictions. In terms of users, Lawmaker is primarily designed for professionals — people working in the executive, like government lawyers and legislative drafters, as well as staff in parliamentary institutions. That includes clerks who manage legislation, publishing officials responsible for releasing parliamentary documents, and digital teams that manage parliamentary websites. It's not widely used directly by Members of Parliament themselves — at least not yet. Typically, MPs rely on their staff or clerks to interact with the system on their behalf.

Beatriz: So their staff are the ones using it?

Matthew: Some staff members do use it, but many still prefer the traditional approach — handing over notes or printed documents to a clerk, who then takes care of the formal process. Lawmaker is a professional-grade tool with a lot of features, and that complexity can be a bit much for users who just want to make a quick amendment or proposal. That’s why, in some cases, parliaments are exploring simpler interfaces for MPs and their staff.

Beatriz: If there’s still a bit of a paper trail or some manual work happening, how do you make sure that everything is eventually captured in Lawmaker?

Matthew: That’s a great question. The short answer is: Lawmaker is responsible for generating all of the official outputs. So, for example, every bill, amendment list, and update to legislation that gets formally published by parliament comes from Lawmaker. If something isn’t brought into the system, it basically doesn’t exist in the official record. From the beginning, we designed Lawmaker to integrate easily with other systems. Users can draft legislation directly in Lawmaker, manage amendments, track the legislative process, and generate revised versions of a bill after it’s been through committee — all from within the platform. But increasingly, we also want Lawmaker to connect with other tools that parliaments already use.

For instance, MPs want to be able to propose and support amendments but giving them access to the full authoring environment of Lawmaker wouldn’t make sense — it’s too complex for that purpose. Some parliaments are building dedicated member portals, with simplified interfaces. These portals may have widgets or tools that allow MPs to submit amendments or express support for others. That data then flows automatically into Lawmaker, where it becomes part of the official record.

Beatriz: Are the systems that members and their staff use integrated with the Lawmaker behind the scenes?

Matthew: That’s the intention: to allow for multiple integrations, depending on the needs of each parliament. And we’re still in relatively early days. This is a big shift for a lot of institutions, and when we rolled it out, we made the case that the effort to transition would pay off in the long run. We often describe Lawmaker as a platform. In many ways, it’s not doing anything radical — it’s enabling people to complete the same legislative process they already followed. But the big change is in how it’s built. Because it’s designed around structured data, it’s far more flexible and powerful than traditional systems.

That shift away from paper is key. When you treat every step of the legislative process as structured data, it becomes much easier to generate multiple outputs: printed copies, web versions, even data sets for AI analysis. And now, people are really starting to see the value in that. Even if Lawmaker itself isn’t doing something directly with the data, the fact that it’s available means other systems can. One of our big motivations at The National Archives was that we already manage the UK’s legislative publishing service, and we have this incredibly rich legislative dataset — essentially every piece of legislation passed in the UK going back to around 1200 AD. Because Lawmaker is built on a data-first architecture, we’ve been able to bring some of that historical data into the tool to enhance its functionality. Lawmaker isn’t just a word processor for bills — it’s a system grounded in legislative data. And that opens the door to building features and capabilities that were never possible before.

Beatriz: You mentioned the initial stages began before 2014. How long did it actually take for the system to become fully implementable?

Matthew: I think the proper development began in 2017, once all the partners had formally agreed to move forward. That kicked off with a five-year contract. The service went partially live in 2019, so about two years after development started. As of now, the service is fully live.

Beatriz: Where would you say things stand today?

Matthew: All primary legislation in Scotland and the UK is now handled through Lawmaker. Around 50% of our secondary legislation across the UK is being processed in the system, too, but that part is taking longer to roll out because it involves every government department and a wide range of agencies. We’re looking at around 2,500 users just for secondary legislation, so it’s a broader and more gradual implementation. The system is still primarily used by professional staff — drafters, clerks, and legislative officials. And next month, the Northern Ireland Assembly will officially join Lawmaker. We’ve been working on that integration for about a year, so starting in April, they’ll be part of the shared service too. It’s a big step.

Beatriz: I’m originally from Brazil, and I’ve worked closely with our legislative institutions. One persistent challenge there is that the systems used by the Chamber of Deputies and the Senate aren’t integrated. There’s often resistance — one house doesn’t want to “lose turf” to the other. It’s fascinating to me that the UK Parliament, Scottish Parliament, and now Northern Ireland are all using a shared system and seem to be doing it without fear of losing control over their own processes.

Matthew: That’s a great question — and yes, there was some hesitation in the beginning. There were concerns about independence, control, and how much flexibility each institution would have. But those concerns were balanced by the benefits: they knew that collaborating meant sharing the costs and efforts of building something truly useful. We were also very intentional about reassuring them. From the beginning, we emphasized that Lawmaker wasn’t about changing how they do things — it was about supporting their existing processes with better digital tools. We never pushed for them to conform to a single model. Each body could maintain its own way of doing things, even while using the same core platform.

Beatriz: Is Lawmaker flexible enough to allow for that?

Matthew: What we found is that, while each parliament has its own traditions and formatting, the underlying patterns are similar. They all debate, amend, and pass legislation. The structures vary, but the workflows follow common logic. A shared system like Lawmaker can support all of them, as long as it’s designed to be adaptable.

Beatriz: This is such a compelling case study, and I’m going to share it with colleagues in Brazil. During the process of creating and developing Lawmaker, was there any formal participation from Members of Parliament, their staff, or civil society organizations?

Matthew: Not formal participation. Some of the work we were doing likely made its way to parliamentary committees — especially the committees that oversee the internal business of the House — but there wasn’t a structured consultation process. That said, we did engage informally with a range of interested parties — particularly people who had been active in the open data and open government communities. We had conversations with them over time, sharing ideas and gathering informal feedback. We also connected with international efforts — at the time, the European Commission was working on similar tools and approaches. There was some engagement, but it was mostly informal and not part of a formal participatory design process.

Beatriz: Is Lawmaker only accessible to people who work within parliament? Do civil society organizations have the ability to contribute, for example, with amendments?

Matthew: Lawmaker is currently an internal tool, used by parliamentary staff and officials. Civil society organizations don’t interact with it directly, but that’s largely because the current parliamentary processes themselves don’t allow for direct public input. Amendments are the prerogative of elected members — so if civil society groups want to propose something, they have to work through MPs, who then decide whether to take those proposals forward. That’s how the system is currently structured. But this ties back to the idea of Lawmaker as a platform. Our hope is that by creating this system — and, more importantly, the structured data that powers it — we’re laying the groundwork for others to build on. If there’s interest in developing tools that promote public participation in the legislative process, Lawmaker provides a much stronger foundation to start from. The data is there, and some of the tools we’ve built could be reused or adapted in different contexts to support greater civic engagement.

Beatriz: You mentioned earlier that the systems used by members and their staff can be integrated into Lawmaker. How are people receiving the platform?

Matthew: New technology is never universally embraced, and we’ve faced some challenges — especially around expectations. One of the downsides of starting the project with beautiful wireframes and mockups is that people expect the final product to be just as polished from day one. And when you're delivering software incrementally, that can be hard to manage. Also, and I’m sure it’s similar in the US House, parliamentary organizations are under intense public scrutiny. There's a sense that if something doesn’t go exactly right — if a bill isn’t published on time, for instance — that democracy itself is being affected so there’s a lot at stake

Part of the learning curve for us has been adapting to the expectations and working styles of these institutions. Running a service for this kind of user is very specific, and we've had to learn how to manage it pragmatically. That said, I think we’ve now turned a corner. We're at a point where users appreciate the system’s flexibility and our ability to make improvements. When someone comes to us with a pain point — something that’s time-consuming or frustrating — we can often say, “Yes, we can change that.” Because Lawmaker is something we’ve built together, and we all have ownership of it, we can adapt it as needed.

We're also starting to go beyond simply replicating existing workflows. One example is how we’re using integration with our legislative data to automate small but time-consuming tasks. Take secondary legislation, for instance: when a lawyer references another piece of legislation, they’re required to include a footnote listing its legislative history — when it was passed, whether it’s been amended, when it came into force, and so on. Traditionally, they’ve had to look all of that up manually — flipping through books, searching databases like LexisNexis, etc. But we already have all that data in our legislative database. We’ve been able to build a feature that automatically generates those footnotes. It’s a niche example, but it shows the kind of targeted improvements we can now make.

Beatriz: Will you explore AI at some point?

Matthew: One prototype we’re just finishing involves using AI to support legislative drafting, especially when a bill is designed to amend existing legislation rather than create something entirely new. That’s very common in the UK — we often pass bills that both introduce new provisions and modify existing laws. The problem is that those amendments are really difficult to read unless you’re a legal expert. You get all these phrases like “In Section 25, leave out this word and insert this section,” and unless you already know the original text, it’s almost impossible to understand what the policy change actually is. So the prototype we’re building uses AI to apply those changes in real time to the existing legislation. It’s not meant to be legally authoritative — it doesn’t have to be perfect — but it gives drafters and stakeholders a clear visual of what the law would look like if the bill were enacted. That way, while someone is still drafting a bill, they can say to their client, to an MP, or to the public, “Here’s what the updated legislation would actually look like.” It makes the process more transparent and easier to understand, even for non-lawyers.

Beatriz: If you were speaking with someone in a role similar to yours — someone about to begin a project like the one you started with Lawmaker — what advice would you give them?

Matthew: Start small. That’s absolutely key. And just as important: don’t try to replicate what you already have. That’s one of the biggest mistakes I’ve seen. Over the years, I’ve looked at a lot of procurement specifications from different organizations, and what I’ve realized is that most of them just describe the system they already use. Then they go to a supplier and say, “Please build us a system.” But, what they’re really asking for is a digital copy of the status quo. They’re not asking the supplier to think creatively or work with them on something new.

Beatriz: That connects to the imagination part you talked about earlier.

Matthew: That imaginative leap is so important. You have to explore your options, try things out, and — if you can — take a prototyping approach. And I’d add: take ownership. Even though we worked with external suppliers, because we didn’t have all the in-house expertise, we never handed the project over to them completely. We’ve always retained ownership. It’s our system. We bring in outside expertise, yes, but the organizations using the tool are the ones who shape and maintain it. That comes with more risk, of course, but if you want a user-focused system — something that truly responds to the needs of those doing the work — you have to keep it close to home.

Beatriz: Is there anything about the process that I haven’t asked that you think is important to highlight?

Matthew: One thing I’d add is the importance we placed on open standards and open data. Yes, Lawmaker is still a closed system in the sense that it’s built for internal use — by parliamentary and government users, not the public or civil society. But from the very beginning, we made a strong commitment to open standards. We knew that if we were building something for the long term — something that might someday interact with other systems or be useful to a broader community — then adopting open standards was the right foundation. In the UK, we already had our own legislative data standard, and we still use that for publication. But instead of designing Lawmaker around our domestic standard, we chose to adopt the international LegalDocML standard. It just made more sense — it was a good fit technically, and it positioned us as part of a broader ecosystem.

Beatriz: So you’re working from a shared core.

Matthew: Exactly. That decision means that if we do want to share our data with civil society or other governments, they’re more likely to be able to use it. It also means we can potentially reuse tools and code from others who are working with the same standards. That was a shift for us, but it’s proven to be a smart one.

Beatriz: Thank you so much. This was a fascinating conversation.