Why services suck at spreadsheets
This post is based on the first half of ”A thousand things at once: bulk transactions and data collection in digital services” – a talk we gave as part of Services Week 2025.
Picture this: you are designing a service where users need to manage potentially many hundreds of things. The normal design system patterns don’t scale well to this size. Asking a user to fill out a multi-page web form for each thing is clearly too time-consuming and impractical. What they need is to tell your service about hundreds of things, all in one transaction. So what design pattern do you reach for?
If you've answered "a spreadsheet template" then you're not alone – it's a design pattern that we've seen commonly occur in digital services where users need to carry out multiple transactions at once. In the spreadsheet template pattern, users download a spreadsheet with predefined columns, fill out the rows with their own data, and then upload the spreadsheet into the service which validates and processes it. We've seen it used for everything from submitting details of employee pensions to collecting data about government contracts.
Unfortunately, we've also seen the challenges that pop up when relying on spreadsheet templates and the resulting frustration from users when they are forced to grapple with submitting their data using one. Having seen the problems repeat themselves over and over again, we've come to a worrying conclusion: asking users to fill out spreadsheet templates in the way we do it today does not meet user needs and should not be used as a design pattern in usable and accessible government services.
Thankfully, we do have a way forward for collecting data in services – but first, let's dive into the problems and examine what makes spreadsheet templates difficult to use.
Users have to understand everything at once
The first question that a user must answer when using a spreadsheet template is what the template requires them to provide. Their information needs are just like for any other service – they need to know what is being asked of them and how they need to supply it.
On the web, designers can use helpful and specific data entry tools like date pickers to help users input data in a human-friendly way and without needing to think about things like expected formats. In spreadsheets we are stuck with just "cells" which only accept free text – so if a service requires a user to enter a date on a spreadsheet template, it typically needs to communicate the specific format that it is expecting. Spreadsheet templates thus need users to understand a higher level of detail than would otherwise be necessary because spreadsheets don't give users any help with data entry.
In Government services we've agreed on the idea that asking users less questions at once makes the service more usable. The norm is for multi-page forms, which typically ask only one or two things per page. Doing this helps users focus and not get cognitively overloaded. In spreadsheets we have the opposite pattern – users have to understand everything at once. The data model required by the service is shown or explained to the user in its entirety and they are then left to fit their data into that model. There is a lot more that the user needs to understand in one go and remember, so the guidance must be very clear, simple and thorough – if it’s not, the spreadsheet becomes unusable and error-prone.
Spreadsheets are not good at delivering guidance
What's worse, spreadsheets do not have a very straightforward way for providing guidance as part of the sheet. Some spreadsheet formats support comments, but these are typically hidden from user view in a way which is not easily discoverable and only appear when hovered over with the mouse, so they don't work well. On some templates all the guidance offered to the user is the column heading and in some there's none at all. Where more explicit content is offered, it's typically shuffled away onto a separate sheet – requiring the user to flip back-and-forth between sheets. It's slow, frustrating and error-prone.
Services with spreadsheet templates thus typically turn to external documentation. We've seen guidance for spreadsheets delivered on service web pages and even (gasp) webinars. Gov design principles are clear that guidance external to the service is not very effective – normally users don’t read it, and when they do they have to flick back and forth between screens to make use of it.
The end result is that whilst users have higher information needs due to the spreadsheet medium, these needs are typically unmet. Users get frustrated and waste time understanding how to populate templates.
Most users can’t transform data in bulk
It's important to realise that users of spreadsheet templates are typically not creating data from scratch. Most of the time they are filling in a template by using information they already have stored elsewhere.
For example, imagine a user who runs a trucking company is asked by a service to submit details of all of the vehicles they have MOTs for. This is something they will typically already be recording somewhere else – in fact, most likely they are recording it in a spreadsheet of their own. The spreadsheet they have will be serving more than just this single need though – it might contain historic vehicles that no longer have MOTs and may also include a lot more information about servicing and mileage.
The task for this user is not to "fill out a spreadsheet template" but in fact to "copy data from an existing source and transform it to match the service's needs".
What sort of transformations are we talking about? Well, users might need to take a date in one format and convert it into another, or use one or more values from their existing data in computing a new one for the service (e.g. add up two numbers and choose a label depending on the result), or filter the data to just what the service requires – the list of possibilities is long, and approaches general purpose programming for the most complex tasks. There's a reason that data scientists are paid so much when 80% of their job is data cleansing!
Don't forget that these transformations need to happen in bulk – the whole reason we are using a spreadsheet in the first place is so users don't have to spend the time doing things one-by-one. For a hundred things, maybe a manual transformation is possible, if frustrating and slow. For a thousand, it is clearly too time-consuming and is out of the question.
“Spreadsheet templates are typically very fussy and require users to learn how to transform their existing data into something the service will accept.”
Let's return to the dates example as nearly every spreadsheet template we've seen involves dates. How do users transform them using an office spreadsheet tool? Well, for a start Excel will reformat dates entered in one format into the one it thinks is best for the user's locale – even if users type out dates in the correct format, they may end up with incorrect formatting. This is predictably confusing.
Whilst Excel does have date formatting options, most users don't know how to wield them to pick arbitrary formats (Excel only offers "short" and "long" form the drop-down menu, and these are typically locale specific). From a (small and informal) survey of office workers, we found that most users are not able to transform a date in Excel from one format to another unaided, and have to turn to their search engine to understand how to do this task. Should government services really be relying on designs that require users to ask their search engine for help?
In short, spreadsheet templates are typically very fussy and require users to learn how to transform their existing data into something the service will accept. Even when acknowledging that services using spreadsheet templates are typically not targeting general citizens, most users simply don't have these skills.
Providing error correction as part of a service is normally poor
We've mentioned above that the additional burdens that spreadsheet templates place on users typically make them error-prone. Unlike a digital service where errors are discovered and fixed by the user as they progress, errors in spreadsheets are only discovered right at the end when the spreadsheet is submitted – meaning there is a long feedback loop between the user making an error and it being found and fixed.
What's more, error handling is normally treated as a bit of an after-thought. Giving high quality errors to spreadsheet users is often not given much design time. Typically this results in an unhappy path for a user that:
Only highlights one error out of many in the spreadsheet – both in terms of errors across multiple rows and different types of issue with the same row
Shows a text-only error in isolation from the sheet, referencing row and column numbers – requiring users to go and identify the bad cell in their spreadsheet separately
Presents the problem in confusing language that hasn't been content designed
The error path also normally requires the user to go and correct their spreadsheet outside of the service and then completely resubmit it. This misses opportunities for the service to provide help with their error correction – it can only do its best to provide guidance on how the problem might be fixed, and it's up to the user to do that themselves. This also means that all of the valid data is simply discarded, when the user might be able to proceed with valid things and come back later to deal with the invalid things.
Templates are limited in the help they can provide
We have seen some examples of spreadsheet templates that include validation. There is, however, a limit to what can be done. Whilst simple things like checking formats or ensuring dates are in an acceptable range might be possible, some validations require the service to be involved. For example, spreadsheet validation can't check that email addresses can really receive mail, or that an address matches to a postcode, or that requested licenses are still available or within quota. There will always be validations that are really helpful to users that can only be performed by the service – which is possible in a web form but not in a spreadsheet.
It's also important to remember that showing the user an error is less helpful than simply limiting their choices to valid inputs. Spreadsheet tools do include some methods to suggest certain values in a drop-down, but typically these only make sense for slowly-changing reference data. If the user needs to pick from a list of things that change regularly or that only they might have access to, the one-size-fits-all spreadsheet template can't include those as drop-downs. Instead they are just asked to copy and paste some identifier to make their choice. Whilst a spreadsheet template could be personalised on a per transaction basis with only the choices that make sense, we've never seen this done!
Spreadsheet templates are used as a compromise
Hopefully you've got a feeling for some of the design challenges associated with spreadsheet templates. It would be obviously acknowledged as sub-par if these turned up in a web-based digital service, which might not even pass a Service Assessment. So given all the issues, why are spreadsheet templates still so commonly broken when used?
We believe there are two broad reasons. The first is that as a design community we lack a general design system for spreadsheets. From reading the problems above, you may have started to come up with some ideas of what works and what doesn't. For example, it's clear that some validation can be helpful when done well and there is a clear need for an excellent way to provide guidance. As of writing, there are no generally accepted design patterns for doing this and not a lot of discussion amongst designers about how to do it well.
The second reason is that there is a lack of commodity tools for working with multiple transactions at once in digital services. If you're a designer on a service team and you want to support bulk transactions but you know your users can’t use APIs, what choice other than a spreadsheet template do you have? Building tools that make multiple transactions work well on the web is hard and is certainly an undertaking that feels too big for a team just delivering a digital service. What is needed are some proper tools, built once for everyone, that make working with multiple transactions in services easier.
In the second part of this post, we’ll look at how to solve some of these issues – both with spreadsheet templates and with spreadsheet uploads in services in general.