Better than an Excel file
A small exchange in the team chat this week crystallised something I've been pondering for a while now.
A colleague shared a spreadsheet - a list of regional delivery managers and their assigned trusts. The data exists in the platform. You can find it if you know where to look, which filters to apply, which view to select. But my colleague had extracted it into Excel and shared that instead. "I know this is in the system", they wrote, "but I find this easier".
Someone else immediately asked whether we could add columns tracking product adoption status by trust. A reasonable request - useful information, neatly consolidated. The conversation continued, with gentle reminders from leadership that we should avoid Excel exports where possible, to maintain "one source of truth".
I found myself typing a response: if we can pass the "better than an Excel file" test, we're getting somewhere. Then deleted it. Then typed it again.
We are our own users
The observation felt too on-the-nose to post without context. We spend our days building digital tools for NHS trusts, trying to convince clinical and operational staff to use centralised platforms instead of their familiar spreadsheets, their printed lists, their paper workarounds. And here we were, doing exactly the same thing.
This isn't hypocrisy. It's evidence. We're not different from the users we're designing for; we're enacting the same patterns, for the same reasons. The Excel file isn't a failure of discipline or a rejection of the platform. It's a signal about what the platform doesn't yet do well enough.
Last year, I wrote about the doctor's notebook - the folded piece of paper carried through board rounds, capturing what actually needs doing next while the digital dashboard displays patient status. I framed it as a boundary object: an artefact that bridges different registers of work, different communities of practice. The dashboard speaks the language of operational metrics; the notebook speaks the language of action and relationship.
The Excel file serves a similar function for the programme team. The platform speaks the language of data governance and system architecture; the spreadsheet speaks the language of "I need to share this with someone right now".
What Excel affords
Klidas and Hanegan (2022) observe, somewhat ruefully, that across the organisations they've worked with, "Excel reports often hide the truth". The concern is legitimate: when data escapes the governed platform into local spreadsheets, it fragments. Different versions proliferate. Updates in the source system don't propagate. The "single source of truth" becomes multiple sources of approximation.
But this framing - Excel as the enemy of data integrity - misses what the spreadsheet is actually doing. It's not hiding the truth; it's making it portable.
The platform requires authentication, navigation, context. The spreadsheet sits in a Teams channel, immediately accessible. The platform enforces data structures; the spreadsheet accepts annotation, highlighting, the addition of a column that someone thought would be useful. The platform is authoritative but distant; the spreadsheet is approximate but present.
Pedersen and Wilkinson (2019), studying welfare service digitalisation, describe how professionals consistently create "shadow systems" - local tools and practices that run alongside official platforms. These aren't aberrations or implementation failures; they're structural features of how knowledge work actually happens. The shadow system fills gaps the formal system leaves unfilled.
Seams again
Previously, I explored the concept of seamful design - the idea that rather than hiding the joins between systems, we might make them visible and useful. The doctor's notebook sits at a seam between the digital representation of the ward and the embodied practice of care. The Excel file sits at a similar seam: between the platform's governed data and the team's working knowledge.
Star and Griesemer's (1989) original formulation of boundary objects emphasised their dual nature: "plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites" (Suoheimo et al., 2025). The Excel file is almost pathologically plastic - anyone can add a column, highlight a row, annotate a cell. The platform, by contrast, is robust but rigid. It maintains data integrity at the cost of local adaptation.
This isn't an argument against platforms or data governance. But it suggests that the boundary between governed and local, between system and spreadsheet, isn't going away. It's a seam - and like all seams, it can be designed.
The test
What would it take to pass the "better than an Excel file" test?
Not feature parity. The platform will never match Excel's plasticity, nor should it try. The affordances that make spreadsheets useful for local adaptation - the lack of enforced structure, the ease of modification - are precisely what makes them unsuitable for authoritative data.
Instead, the question is whether the platform serves the purpose better than extraction would. For the colleague sharing regional delivery managers: can they share a link as easily as attaching a file? Can the recipient access it without navigating three authentication steps? Can someone add a note without submitting a change request?
Gasser (1986), as cited by Bratteteig (2003), described a category of work he called "fitting" - the labour of making systems work in contexts they weren't designed for. Every time someone downloads data to Excel, transforms it, and shares it another way, they're doing fitting work. That work is currently invisible to the platform and its designers.
Goodman and Kuniavsky (2012) define workarounds as "situations in which informal, ad hoc responses to a problem have become the status quo". The Excel extract is a workaround. But it's also diagnostic: it reveals where the platform's model of work diverges from work as practiced.
Shadow systems as signal
What if we treated shadow systems not as problems to be eliminated but as signals to be read?
The Excel file tells us: sharing is harder than it should be. The annotated printout tells us: the data model doesn't capture what people actually need to track. The parallel spreadsheet tells us: someone needs to combine information from multiple views in a way the interface doesn't support.
Pedersen and Wilkinson found that shadow systems in welfare agencies had "a more permanent character than merely being start-up or implementation problems". They weren't transitional; they were structural. Staff didn't create them because they didn't understand the official system; they created them because they understood it perfectly, including its limitations.
The same is true here. My colleague didn't share an Excel file because they couldn't find the data in the platform. They shared it because the platform doesn't support the kind of sharing they needed to do.
Making systems less shadowy
There's a version of the platform's success where no one ever downloads to Excel again - where the digital tool becomes so useful, so well-fitted to practice, that the shadow systems wither away. I'm not sure that day is achievable, or even desirable. Some plasticity needs to remain local; some adaptation is better handled outside governed systems.
But there's another version of success: where the platform acknowledges the seam between governed and local, makes it visible, and provides good tools for working at the boundary. Not eliminating shadow systems but making them less shadowy - understanding what they do, supporting the legitimate purposes they serve, accepting that some information will always escape the system because that's how information works.
The Excel file my colleague shared is, in Star and Griesemer's terms, a boundary object. It sits between the platform's authoritative data and the team's working practices, translating between registers. The fact that we're building the platform and still reaching for the spreadsheet doesn't make us hypocrites, it helps us empathise with the users we're designing for. We're not different from them; we're doing the same thing, for the same reasons. The question is whether we can design the platform to be better at that thing than Excel is, or probe more deeply into why Excel is doing it better and why that might be ok or necessary.
References
- Bratteteig, T. (2003). Making Change: Dealing With Relations Between Design And Use. PhD thesis, University of Oslo.
- Gasser, L. (1986). The integration of computing and routine work. ACM Transactions on Office Information Systems, 4(3), 205-225.
- Goodman, E. & Kuniavsky, M. (2012). Observing the User Experience: A Practitioner's Guide to User Research (2nd ed.). Morgan Kaufmann.
- Klidas, A. & Hanegan, K. (2022). Data Literacy in Practice. Kogan Page.
- Pedersen, J. S. & Wilkinson, A. (2019). Big data: Promise, application and pitfalls. In A. Wilkinson, N. Bacon, S. Snell & D. Lepak (Eds.), The SAGE Handbook of Human Resource Management. SAGE.
- Star, S. L. & Griesemer, J. R. (1989). Institutional ecology, 'translations' and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39. Social Studies of Science, 19(3), 387-420.
- Suoheimo, M., Jones, P. H., Lee, S.-H. & Sevaldson, B. (2025). Systemic Service Design. Springer.