This is our first weeknote about working on the alpha phase of Extract. It’s a regular, weekly communication of what we’ve done, what we’re thinking about, ideas, decisions, scrappy thoughts, and stories about our work designing and testing Extract. It’s also how we can remember what we’ve done. Written for us, but shared with you.

This week’s note comes from the people on the team working at Ministry of Housing, Communities and Local Government (MHCLG). In future weeks, we’ll feature work from the Incubator for AI (i.‌AI) too.

We’ve written about Extract and where it came from on the MHCLG Digital blog, if you’re not familiar with it. But since you’re here, we’ll presume you know what it’s about.

So, what did we get up to this week?

Forming as a unit

As a wise man once said (and another man once drew), ‘the unit of delivery is the team’. This week we kicked off the alpha, held our first planning session, and started looking at risky assumptions. New people joining the team has meant we can get started, so we’ve focused on forming as a unit.

Guiding principles

In the kick-off, Steve shared some principles to guide us through the alpha. The alpha phase is an opportunity to try out different solutions to the problem you’ve identified, finding out what works for users (and what doesn’t). To help create variety, we’ll start small, learn fast and iterate towards the design that meets users’ needs.

We looked at the principles from Lean UX too, as the alpha phase is all about velocity of learning, not velocity of delivery. The Lean UX principles are:

1. Moving from doubt to certainty
2. Outcomes, not output
3. Removing waste
4. Shared understanding
5. No rock stars, gurus, or ninjas
6. Permission to fail

Progress is better than perfection

After the kick-off, Jenny and Chanelle lead our first planning session. As we’re still waiting for key roles to join the team, the purpose was to get started on preparatory tasks and start planning ahead for testing with local planning authorities down the line.

It was also an opportunity to test out a basic delivery model and change aspects of it now (rather than waiting for a retro). We refined how we do estimation, and we thought about how best to frame the units of work. Instead of trying to craft the perfect delivery model on paper, we dived right in and gave it a go. Progress is better than perfection.

Steve and Gordon also chatted about how we might best keep i.‌AI’s progress aligned with MHCLG’s sprints. As i.‌AI’s work is experimental, rooted in the practices of continuous improvement, estimations don’t work too well. They’re going to use hill charts to show progress instead.

Mapping out what we know…and what we don’t know

On Friday, Fabia lead a workshop to map out our assumptions about Extract, joined by Hannah (our new frontend developer), Jenny, and Steve.

Calling out your assumptions is an essential part of any test & learn approach. Testing our assumptions allows us to find out whether we’re right or wrong, creating a feedback loop. If we’re wrong, we can change our minds, change the designs and ensure the solution we deliver works for users. If we’re right, we crack on.

Fabia asked some questions which helped us list out everything we thought we knew:

• Who are the users?
• Who won’t be a user?
• How technical are they?
• What are their current methods [for extracting data from documents]?
• How do they edit shapes on a map?
• What technologies are they using?
• What are the inputs?
• What are the outputs?
• Why are they using it?
• What happens after?

We wrote up what we know so far, from speaking to local planning authorities. Then we placed those on a scale of known to unknown: which facts we’re confident in, which assumptions we need more evidence to rely on.

There’s some more work to do on that next week, and once we’ve onboarded a user researcher, we’ll start prioritising what we need to learn first and form a research plan.

On to the next one

All in all, a pretty good first week. The best way to build up steam is to light the stove, and sooner rather than later we’ll be chugging along.

Subscribe to the feed if you’d like to follow along, or check back here next week. (Read more about how to use feeds.)

Ciao!

This is our second weeknote about working on the alpha phase of Extract. It’s a regular, weekly communication of what we’ve done, what we’re thinking about, ideas, decisions, scrappy thoughts, and stories about our work designing and testing Extract. It’s also how we can remember what we’ve done. Written for us, but shared with you. (Read last week’s note if you’d like to catch up.)

The key theme of the week was knowledge-sharing, living up to the guiding principle of sharing understanding that we established last week. The more a team collectively understands what they’re doing and why, the less they need to debate what happened or why and can quickly move to utilising that learning.

Assumptions to validate

Monday started with a workshop to finish off mapping our assumptions, which we had started last week. These are the assumptions we’ll be validating or invalidating throughout the alpha, so we’re glad we got those out of our heads early.

Though this isn’t everything we’ll be exploring, some of our assumptions include the following.

• The need for efficiency: there’s a strong assumption that these users desperately need to reduce manual effort in extracting data from planning documents, as they’re currently spending significant time on this task.
• The need for accuracy and consistency: users require high accuracy in data extraction; inconsistencies are a major pain point.
• Integration with existing systems: there’s an implied need for the system to potentially integrate with existing planning systems – though this isn’t fully fleshed out yet.
• PDF is the dominant format: though we know that some local planning authorities have TIFF files of scanned documents, PDFs are more popular.

Each of these assumptions has an impact on the functionality and user experience of Extract, hence why we’re testing out different options during the alpha phase.

Re-using code from other parts of government

Make things open, it makes things better. That’s a government design principle that encourages us to share code, share learnings, and makes it possible to get a head start by re-using other people’s work.

Fabia, Hannah and Kevin have been looking at the map components we can borrow from HM Land Registry and Environment Agency, rather than building our own. They’ve done some great work over the years, especially on the accessibility of maps, and we’re keen to share back anything we learn too – returning the favour.

The team started documenting where we might re-use these tools in the user journey of Extract, so we can hit the ground running when we do more prototyping.

Scribbles, diagrams, flows

Wednesday was a busy day, but our best collaboration session yet. Jenny, Chanelle and Fabia came down to London from Manchester, and Gavin, Gordon and Kevin left the Whitechapel Building to head over to 2 Marsham Street, the MHCLG offices. We camped out at the team table all day to work through a packed agenda.

To kick things off, Owen introduced the technical stack of planning.data.gov.uk to the team. There were lots of similarities in approaches, which was really good to hear. Though the current prototype of Extract is built in Next.js, the team agreed that porting it over to an Express.js app now would reap rewards in the near future, helping with quicker prototyping.

Throughout the meeting, the team members shared their expertise and experiences, aiming to align on the product’s architecture, and deployment strategies. This collaborative discussion is essential in the early stages of forming a team to build a digital product, as it fosters understanding, consensus, and efficient division of tasks among team members.

Next up, Fabia gave everyone a run-through of the user journey she’d been drafting. It’s an early idea – and obviously not validated with users yet – but sharing feature ideas and early thinking on the user experience is always good.

We talked about bulk uploads, per-document processing, how users would refine the outputted data, the need to undo and redo actions, how to keep data linked up with documents, human-in-the-loop versus human-over-the-loop, accessibility challenges and pre-existing workflows.

Steve and Jenny also scoped out the plan for research and testing, optimising it for our time-poor colleagues in local planning authorities. They’re stretched and we want to make best use of the time they kindly offer us.

It was a great day and we got a heck of a lot done.

Welcoming a user researcher

Our user researcher, Rob, joined us on Thursday, and Steve spent the afternoon onboarding him. That means stuffing his head with lots of context, the programme’s mission, our strategy, and how Extract will play a part.

On Friday, Rob, Fabia, Jenny and Steve shared ideas for the first round of research, which we’ll be able to start planning. If you’re from a local planning authority and you’ve contacted us about being involved, we’ll be getting messages out very shortly!

Looking at red-line boundaries

Steve visited West Oxfordshire District Council way back in August, and despite taking lots of videos and detailing processes and hearing about pain points, one thing he didn’t manage to document was what happens when a new planning application arrives.

Arthur and Sean demonstrated how they use Uniform and ArcGIS Pro to get red-line boundaries into their back-office systems. It was helpful not only to see the process but also to see which tools were available to the team already. It’s all valuable context which can highlight where Extract can be most useful for local planning authorities.

Next week

Next week, we’ll be

• prioritising risky assumptions
• writing hypothesis statements based on those assumptions
• planning the first round of research, and
• recruiting research participants.

Subscribe to the feed if you’d like to follow along, or check back here next week. (Read more about how to use feeds.)

Here’s the highlights of what we got up to this week.

Burning questions

On Monday we prioritised our risky assumptions, identifying the key things we need to learn in order for the product to be a success. We wrote hypothesis statements to hold together our learning, thinking and making, pairing clear outcomes with measures of success. These statements help us know when we’ve validated an assumption, so they’re a core part of the alpha phase.

Our hypothesis statements took this format:

We believe that [doing this/building this feature/creating this experience] for [these people/personas]
will achieve [this outcome]. 
We will know this is true when we see [this market feedback, quantitative measure, or qualitative insight].

We also spent time calling out all our burning questions, the nuance we need to understand in order to design and deliver a product that meets users’ needs. These fell into five groups:

• Their process, and the end-to-end journey
• Accuracy of output and time spent on task
• Ownership of the output
• Incentives to convert documents into data
• Satisfaction with the output

This work is moving into a knowledge kanban to track the progress of our assumptions and learnings. We will continue to map our evolving assumptions, hypothesis and questions as we learn from the upcoming user research.

As Erika Hall reminds us, enthusiasm isn’t a substitute for knowledge. Asking these questions will help us learn about and mitigate the four big risks with product and service development.

End of sprint demo

During the end-of-sprint demo, Jordy showcased a new feature for extracting and identifying individual trees (as points) in Tree Preservation Order documents (TPOs). Previously only capable of handling area-like objects, this was achieved by integrating Gemini AI to recognise and label each tree, even providing details like species. Jordy generalised the method, meaning it can be applied to other point-like objects in future.

Aydin also worked on adding versioning to track and changes that users make to shapes, allowing them to undo and redo changes while they’re refining the output. We expect this will be really useful for users.

Gavin presented innovations in the georeferencing technology he’d developed. The system now performs smarter lookups for addresses, using an LLM to choose the correct address when ambiguity arises, significantly improving accuracy. He also showed improvements to pinpoint locations on maps. It can now more accurately identify and place shapes (polygons) over maps, even in challenging formats like old-style coastal maps.

Rob presented his research roadmap for the alpha phase. The roadmap showed how we would produce valuable, robust research outputs within five weeks, leading to an well-defined MVP.

Rob proposed a high-level research timeline with specific focus areas for each week:

• Week 2: Metrics pilot (almost like prototype testing)
• Week 3 and 4: Evaluative studies on user-centred design questions (the burning questions)
• Week 5: Another look at metrics work, incorporating learnings from weeks 3 and 4 (aiming to show an improvement)
• Week 6: Final documentation and handover of next steps

The metrics pilot (and follow-up study) aims to capture baseline data and surface necessary measures or logs for future benchmarking and success metric development. The evaluative studies will assess speed, accuracy, and overall experience using Extract compared to GIS software, with follow-up surveys to gather quantitative and qualitative data.

A new sprint

The team got together to plan the development of key features ready for testing. Though some of these have been in existence for a while, they were built into an inaccessible frontend. These are being ported over to an Express.js frontend by Kevin and Hannah at great speed, which can utilise the Extract backend.

Fabia documented the design thinking for Extract, covering some of the build-up to the start of the alpha.

Fabia also started design research for one of the trickiest features: evaluating the AI’s output alongside the original document, in an accessible way. This falls right in the middle of the user’s journey and will set a core design constraint, helping us eliminate a big uncertainty early on. Starting in the middle can help us address design problems early on, making it quicker to design and develop features in successive weeks.

Hannah and Kevin started looking at the who, what, where, when, why and how of frontend development, exploring where code will live, where it will be deployed, and other details. This operating model will pay dividends in coming weeks.

Steve and Owen made a start on one of the assurance tasks, calling out how to meet the principles in the AI Playbook for the UK Government, which was mentioned in a Parliamentary question and answer last week.

Aligning on plans

Aligning two teams to work as one, with complementary methods, is tricky, especially as we’ve been moving at different speeds in the past. There’s a need to refine how incubating and scaling overlaps with the alpha and beta phases, so that products and services can meet the Service Standard and spend controls.

This is a common stage of team development though and will be beneficial to work through. And we’re all committed to the mission equally, so we’re moving in a common direction.

Invitations to join research and testing

Adding to all the progress already made, Friday ended with an achievement as the first invitation to join research and testing went out to a local planning authority! More will be going out early next week, recruiting even more people for research and testing.

Onwards!

Recruiting research participants

The week started off by selecting local planning authorities (LPAs) we’d like to do research with. We whittled a list of 31 LPAs down to 14 based on a few criteria:

• The LPA had published less than 5 datasets on planning.data.gov.uk
• The LPA hadn’t yet published datasets for either Article 4 directions, conservation areas or tree preservation orders
• We research with a good mix of rural and urban authorities
• We research with LPAs from regions across England

We’ve contacted LPAs in the following regions: Yorkshire and the Humber, South West, London, West Midlands, East Midlands, East of England, North West, and South East.

Seven LPAs are urban (according to rural/urban classifications from Office for National Statistics), and seven are rural. In some cases, this can have an impact on the number of tree preservation orders (TPOs) an LPA manages. (Adur & Worthing councils recently shared a large, delicate TPO map) in case you’ve not seen one before.)

First participants recruited!

And the big win of the week was recruiting the first participants! We’re really grateful to LPAs for giving up 1 or 2 hours a week to help us research and test Extract, it’s absolutely essential to ensuring we start with user needs.

Their Chief Technology Officer asked how Extract works, so they can think about how IT and information security policies might be affected. We’ve written a note on the technology for senior leaders and IT teams who might have this question too.

Building and deploying the prototype

This week we also finalised the plans for the first prototype, figuring out the who, what, where, when and how. That includes

• what features will be in there
• who’s building those
• where we’re deploying the prototype (and how we’ll use pre-production environments in parallel)
• when we’re having a code-freeze on model improvements
• when we’re deploying the prototype (ahead of the first research session, for testing), and
• how we’re working in phases, building version 0.1 while shaping up features in version 0.2.

We’re borrowing approaches from dual-track agile which should increase our velocity, helping us make the most use of the limited time we have available. For example, while Hannah is building version 0.1, Fabia and Kevin are exploring accessible shape editing features in fullscreen mode (for version 0.2). (Re-using HM Land Registry’s map component has helped us move quickly here.)

Working in these offset phases – or dual tracks – should help us make the most of each other’s strengths. We’ll experiment with the approach and iterate when we need to.

Here’s a first look at version 0.1 taking shape.

Improving accuracy

Gavin, Jordy and Rich are constantly looking at ways to improve the technical accuracy of Extract, based on some metrics set when the incubation phase was started. This continuous improvement mindset has already delivered impressive results, and it’ll keep quality high as we encounter new variations in document styles.

A couple weeks ago we spoke about ideas for using user behaviour to improve the accuracy of extracted shapes, and Gavin demo’d some experiments that had been happening. Whenever a user adjusts the position of a shape on the map, or adjust the lines and points that make up the shape, these corrections by users can be fed back to the model to improve outputs going forwards.

This ‘accuracy modifier engine’ can also help us see how well the AI’s actions satisfy the user’s intent. Incorporating this kind of human feedback is crucial, but we’ll also be asking for qualitative feedback from users too.

More details on this work in future.

Using AI as a new material

Fabia and Steve had a think about an emerging design principle for the work, making more use of AI as a new material.

We don’t want to build another GIS tool. Users have those. Using AI as a new material means speaking to the agent to shape things, the user’s intent becoming the agent’s actions. (And if this is too tricky, we can fall back to established tools and patterns.)

In some cases this could be quicker than editing point-by-point, though we’re aware that’s a behaviour users will be familiar with. It’s early thinking we’ll look to play with down the line.

Next steps

Next week is all about getting the first research session completed and more research booked into the calendar. The sooner we can get to insights, the better, and we’re really chugging along now.

Onwards!

MVP 0.1 release and testing

Finally, after weeks of anticipation and preparation, we’ve put Extract into the hands of our users with the release of Extract 0.1 MVP. Earlier in the week, we began our first research sessions. We’re looking to understand how LPAs are digitising planning documents at the moment, without Extract, to get benchmark timings for the current process. We’re also carrying out research sessions with stripped back features so we can validate our core feature set and prioritise future features.

3’s the magic number

The team also began looking into the newly released Gemini 3 and Segment Anything 3 models. We think there may be meaningful improvements throughout the extraction process.

We’re currently experimenting with how to integrate these into Extract as soon as possible and get their maximum performance. From initial experiments it should lead to a significant boost as well as speeding up the process.

Below are examples of how precise the tools have been. The current version of Extract struggles with precision of results from these harder maps, so these images show how the new models can really boost our accuracy even further.

Collaboration and new ways of working

As part of our alpha ways of working, the MHCLG and i.AI teams spent time refining how we plan and deliver together. We’re shaping a process that lets both teams test and research independently while staying aligned on priorities. This includes shared release planning, clearer and optimised agile ceremonies, and a coordinated research, delivery and release plan.

Next steps

We’re still in alpha, and much of our work continues to focus on the benefits model and understanding the problem space. Testing the 0.1 MVP is already giving us insight into what LPAs need, and will help us prioritise the backlog and identify the core functionality for a 1.0 release next year.

Our focus next week is preparing the 0.2 MVP release and deepening our experiments with the new models. We’ll also continue research sessions with LPAs to validate what’s working in the 0.1 MVP, what isn’t, and what this means for our priorities as we build towards 1.0.

What we’ve heard from users so far

You’ll remember from last week that we started the first benchmarking session, and early this week it finished.

In this first round of user research, we tested an interactive prototype of Extract with five users across four LPAs. This ‘MVP Test’ allowed us to observe real users interacting with the tool in their actual context of use.

Early analysis indicates that the core concept is well understood and shows strong potential to deliver effective, highly valued solutions.

One promising insight is that users are already thinking about what the prototype might enable after an extraction has been reviewed. Even when an extraction was less successful, users were interested in being able to easily transfer and reuse parts of the data within their own systems and tools.

As one participant explained:

This would definitely speed up the process, but the question is: how transferable is the data is to back-office systems?

Seamless integration and reuse of extracted data within users’ existing systems in an important part of the proposition, so we’ll need to dedicate some research to help us achieve it.

Insights from this study are helping us:

• deepen our understanding of the problem space
• evaluate the technology from a user perspective, and
• inform user-centred design and engineering decisions.

As we iterate the prototypes, they will continue to serve as research tools to probe broader, less-defined factors that influence implementation, governance, and trust, ensuring the solution aligns with users’ expectations and integrates seamlessly within their wider ecosystems.

Early next week we’ll firm up the plan for the second round of research.

Merging ideas

Fabia, Hannah, Kev and Aydin spent time interrogating and critiquing multiple user flows, looking at the many options we have for features and the whole user journey. This was to help with merging the diverse ideas from both teams into one cohesive flow.

The designers and frontend developers also spoke about the constraints that shape what we design and build. For example, there is not always a one-to-one relationship between an area and the planning documents that describe it. A user may need to upload multiple files (a map, a design statement, a legal document) to extract all the information about one place. How might we help users combine documents or combine extractions for one entity?

The conversation also moved on to how we’ll merge multiple strands of work in the codebase. Working from one consistent codebase, using and iterating the shared components, will help us move faster – essential for rapid prototyping, and helpful for the future too.

Lunch together

One highlight of working together in Marsham Street on Wednesdays is lunchtime. For one hour, we step away from the work and get a chance to chat, to catch up – and, most importantly, devour a plate of pie, chips and gravy!

Making these social bonds isn’t just fun, it also helps the work work. So that we don’t only have a shared commitment to the goal but also to each other.

After lunch, Gordon kindly shared a gift he’d bought for each member of the team – an Extract mission patch!

Planning for version 0.2

Off the back of the research sessions, we started planning version 0.2 – what would be in it, and how it would work. Before we make a start on it though, we need to consolidate the codebase and plan who’s working on what. That’ll happen early next week.

We’re going to trial something new, pairing a developer with a designer so they can work in unison. The goal is to eliminate the hand-off between design and development, instead figuring out the constraints and possible options together. We want to encourage creativity too, and coming up with lots of options. As Linus Pauling said:

If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away.

Get the obvious ideas out of the way and together we’ll come up with the good ones.

Continued experimentation with the latest AI models

Gavin, Jordy and Rich have carried on experimenting with the latest versions of Gemini and Segment Anything. The new technology is performing well on the hardest maps we’ve tested.

Making improvements

The first research session generated a series of insights which we’ve put into 3 categories:

• Concept: the overarching idea & value proposition of the solution.
• Context: the environment and workflows in which the solution operates.
• Usability: the practical experience of interacting with the solution.

The insights we’ve categorised as conceptual and contextual can impact the success of Extract as a product as much as the usability insights, but we’re better able to act on and improve the usability issues. So we’ve been working on making those improvements before addressing the conceptual and contextual insights that were raised.

Human-computer dynamics

Ethan Mollick shared the concept of ‘centaurs’ in his book Co-Intelligence. Working like a centaur means giving AI tasks you hate but can easily check, seeing whether it speeds things up or allows you to focus on other, more meaningful tasks.

Compared to humans, AI is not yet good at many things but does produce good outputs in a lot of other areas. Ethan Mollick called this ‘the jagged frontier’, and it’s why taking the centaur approach is useful. If AI cannot produce perfect outputs but can create something good enough – something you can improve and work with – the outputs from AI can still be useful. Indeed, that’s what users indicated to us in the first research session.

It’s clear that humans being able to smooth out the rough edges where AI isn’t good enough may be a factor in real-world AI adoption for some time. Helen Toner, the interim executive director at Georgetown’s Center for Security and Emerging Technology, wrote about that recently, saying:

We should be thinking more about human-computer interaction dynamics, human factors, user experience, user interface. What does the trust between those parties look like? How do you maximize the benefit that you’re able to get from those AI systems by designing that human-AI system well? As opposed to just skipping to the end and assuming, well, at some point the AI is going to automate all of it, so who cares about the human-computer part.

There’s lots we can learn in this space – human-computer interaction – that can be useful. Addressing the usability issues first can also help us draw out more of the conceptual and contextual issues (which require more evidence to prove) in further studies, so it feels sensible to look at these first.

Usability issues

Our first prototype was stripped back, a basic flow and set of tools allowing users to upload a document, extract the data, and approve or reject the extraction. We didn’t include any editing tools as we wanted to understand whether it was good enough as it was. We expected to be proven wrong, and that ended up being true.

Because the prototype was so minimal, a few issues came up. However, except the lack of editing tools, these issues weren’t major. On the whole, users understood what to do, completed the task in under 10 minutes, and a couple of participants even downloaded the data to refine further elsewhere. Not bad.

Some of the issues included:

• extraction time duration and signposting
• only being able to upload PDFs
• not realising you could drag & drop files (but being used to doing that)
• how we designed the review stage, where users compare the original document to the extracted data
• matching map data with related text data

We spent the majority of the week addressing these through interface changes, a complete re-design of the user journey, and better content design (clearer labelling, improved instructions). We believe these should make it easier for users to use Extract, and the addition of editing tools may influence more users to approve and export the outputted data.

We’re running another round of research and testing next week, and we can’t wait!

The editing tool

In a previous weeknote, we shared how we’d re-used HM Land Registry’s map component as the basis for our own. We’ve been building on top of that, adding more features for the upcoming testing.

Firstly we’ve developed new shape creation tools, allowing users to snap lines and points to the map for greater accuracy. Some users mentioned that they draw lines on the side of the road, some mentioned they draw lines in the middle of the road, and our tools should support both use cases.

We’ve also added the option to toggle satellite view, which is especially helpful in viewing whether a tree is placed correctly.

We’ve also been working on the accessibility features, making it possible to navigate the map, move shapes and edit shapes using a keyboard. When you get feedback from people with disabilities early in the design and build of a product or service, problems become easier to fix, and you come up with solutions that benefit everyone. We wanted to get this in now rather than later, when it’s more expensive to address.

Gemini 3

Google’s newest release, Gemini 3 Pro, is now integrated into Extract. Gemini 3 is better at deciphering and pulling information from legacy records, is more reliable, and excels at vision tasks.

We tested a single-shot prompt from Gemini 3 Pro against our current multi-stage tree preservation order (TPO) extractor (Gemini 2.5 Flash) and noticed significant improvements.

• Speed: Single-shot Gemini 3 Pro is comparable in time to our previous method.
• Reliability: It is highly reliable, returning successfully on every one of the hundreds of examples tested.
• Accuracy: Extraction of trees from TPO documents is much more accurate. The F1 score (a measure of the overall quality of a predictor) is consistently higher. Crucially, Gemini 3 is far more likely to get the tree’s location exactly right (within one marker’s width).

Extending the alpha

We’ve decided to extend the alpha period into next year. Originally we set ourselves a tight timebox, trying to learn as much as possible inside 8 weeks. Though we held one research session and have another coming up next week, the insights we’re getting back indicate that we’ll need time to learn more.

It’s not surprising. Artificial intelligence is a new technology, there aren’t well established patterns for interacting with it yet, and the planning domain requires precision. Quality and trust are major factors in doing this well.

Spending more time with users, collecting more insights, will massively improve our ability to mitigate risks and build the right thing. We’re extending the alpha phase by another 4 weeks, covering January 2026.

Thinking ahead to the beta

We’ve also been thinking ahead to the beta phase, where we take our best idea from alpha and start building it for real.

We want to make sure that local planning authorities are available for research and testing, to be part of the private beta, hence why we’re thinking about this now. We can’t build and improve Extract without their input, and they rightfully need time to plan how they’d get involved.

We’ll share firmer plans in the next couple of weeks, but if you’re a local planning authority with thousands of planning documents you need to convert into data (tree preservation orders, Article 4 directions and conservation areas), get in touch.

And finally…

Goodbye to Jenny, one of our product managers, who’s leaving us today. Jenny’s done a lot on Extract over this year, and we’re really grateful for all her input.

Bye Jenny!

Design rationale

Earlier in the week, Fabia added more notes on the design of our first two prototypes to our design history. It explains why we stripped away features we figured we’d need, talks about the Frankenstein phase of combining two frontends using collaborative ‘mix-and-match’ prototyping, and talks about how what we learned from users fed into later iterations of the design.

Check it out!

Rapid pre-release testing

Before we get into the research that happened this week, it’s worth calling out the excellent effort the team put in for testing the second prototype internally, before we released it to production for testing with users.

After deploying the second prototype to staging, everyone started running through the prototype, looking out for inconsistencies, bugs and broken things.

A couple of show-stoppers popped up. Instead of sorting these out in isolation, Hannah and Kev treated it like an incident and hopped on a call, debugging the problems and figuring out a way forward. Gavin joined later to help out too, and incredibly we got it all sorted in a couple of hours.

The prototype needed to be ready on production by 3pm. It was online and sparkling clean by 2.45pm. Top work from all involved!

Second round of research

Rob ran the second round of research, speaking with five people from four local planning authorities. Most of the users were GIS officers, although one person worked in planning policy, which surfaced lots of interesting points.

We’re not making any conclusions just yet nor sharing any early insights. We’ve got another session on Monday, meaning we’ll have tested with six people from five local planning authorities come lunchtime next Monday.

After that, we’ll be analysing the evidence, forming insights, and ready to end the year on a high. We’ll come back in the new year to continue the alpha.

Adapting for the unexpected

Researching, designing and developing products and services is not a linear process. Even though we describe it as a linear process with a start and an end, it’s actually more like a loop.

Right now, we’re exploring solutions to a problem. Problems are seldom well-defined, coherent, and tractable. So when we’re testing a prototype, what we hear from users often tells us things about the problem we didn’t previously understand or know about. We’re continually discovering new insights we didn’t expect, testing and learning and testing and learning.

Test and learn relies on a culture of learning, expecting the unexpected, and a willingness to accept new information and change the plan in response. And new information is coming up suggesting we’ll need to adapt the plan a little bit.

Early next year we’ll need to do some discovery-type research to better understand users’ needs, tasks, motivations and goals. There’s high variation in how they produce and maintain planning data (which doesn’t always include working with documents), and mapping this landscape a little more will teach us about where we need to focus.

It may even suggest some other forms of prototype we hadn’t considered before, and it’ll definitely help with planning a private beta too.

As previously mentioned, we’re going to continue the alpha phase in January to gather more evidence. We’ve tested two prototypes with eight users from seven local authorities but don’t feel like we’ve got conclusive evidence just yet. Collecting more will help us learn whether we can effectively meet users’ needs.

So, what were the key findings and insights?

What we learned

Georeferencing is the foundation

Overwhelmingly, users found Extract’s ability to look at old maps and locate the same place on a current map hugely helpful. This is known as georeferencing and is the most important part of creating geospatial data from documents. It’s also the hardest and most time-consuming job when working with historical maps. If you’re looking at an old map and a piece of land is developed or a track is turned into a junction, it can be hard to work out where it is on a newer map.

Some quotes from users involved in testing show you how foundational a job it is for turning old maps into data.

The first stage is to get it right with the georeferencing. That is the foundation. So if you get it wrong with that, there’s a 95% chances of you getting it completely wrong when it comes to the spatial position and accuracy of the feature itself.

Georeferencing and digitising is complex work, so this can help people.

Auto-georeferencing is good because that’s a cumbersome process.

Some users mentioned wanting to get this feature into their own GIS tools, so we’re looking into GeoTIFFs – a way of embedding geographic metadata into images. Our understanding is that this may let users draw shapes in their own tools, so it’s an alternative solution we’ll start prototyping in the new year.

Bringing colleagues along

Despite that, we also heard that from users that they’d like to invite others to work on digitising documents with them. Geospatial information system (GIS) officers are in high demand at local authorities and often work across many service areas. As a result, they’re stretched across many projects and may not always have the time to spend on lengthy projects – like digitising historical planning information, for example.

Users suggested that Extract might help create efficiencies at local authorities by allowing GIS officers to pass some digitisation work to colleagues without GIS skills, allowing the GIS officer to ‘sign off’ anything produced by their colleagues.

Accuracy of shapes is very important

Users also said that the accuracy of the shapes outputted was paramount. Few users found the shapes drawn by the AI agentic workflow to be satisfactory enough to adopt, and many users redrew the shapes themselves. There’s an opportunity to look into whether we can encourage the model to produce more ‘regular’ shapes or with fewer points, to increase accuracy and user satisfaction.

That’s just a couple of insights from a wealth of findings, but it’s enough for us to pause and consider the next steps carefully.

Challenging preconceived assumptions

Stepping back from it all, it’d be sensible to reframe the problem and truly understand its scale. From what we’ve heard from users, not all local planning authorities need to convert documents in order to prepare or provide data to national standards. Some times they already have data but it’s patchy, and some times it’s just hard to find the time to transform it from one schema to another.

These details affect not only how we design and build Extract, but also how we launch it and onboard users. Ultimately it’s about making sure we learn about users and their needs so that we can build the right thing.

That’s a wrap…for now

It’s been a hugely exciting year though. This time last year, extracting data from documents using AI was just an idea, but we’ve developed a novel method to do it with multimodal large language models.

As mentioned earlier, the team have properly earned their break over the next couple of weeks, and we’re really looking forward to starting up again in January.

Anyway, now onto my speech, my Christmas speech: Thank you, all, and Merry Christmas.