The citizen development proposition - that domain experts can, with appropriate tooling, build and maintain the software their work requires without depending on specialist engineering teams - recurs across every generation of enterprise software. Spreadsheets were going to eliminate the need for custom financial applications. Visual Basic for Applications was going to put database development in analysts' hands. Low-code platforms were going to close the gap between business requirement and delivered product. Each iteration has generated genuine capability at the margins while falling short of the systemic transformation its proponents promised. The current iteration, in NHS data analytics contexts, involves React frontends and typed API layers connecting to proprietary platform ontologies. As Bock (2021) observes in his survey of low-code platforms, the field exhibits "a propensity toward marketing jargon, terminological inexactitude, and inflated promises" that should prompt caution before any organisation commits to citizen development as a strategy rather than a supplement.
The previous post in this series mapped the structural gap between what NHS analytical workflows require and what the current platform architecture provides. This post examines why the skills case against the React self-service proposition is structurally well-founded, and what a more honest account of the division of labour between analysts and engineers would look like.
The analyst-as-developer proposition
The programme's stated ambition was for analysts to build their own dashboards: analysts should be "self-sufficient" or "self-serve"; a React component library would enable them to build without engineering bottlenecks; training would equip them to produce publication-quality frontends. This vision is not implausible on its face. It is also the latest iteration of a proposition that the end-user software engineering literature has been examining - and consistently tempering - since the 1980s.
Ko et al.'s landmark survey of the field, co-authored by fourteen researchers across eight institutions (2011), established that most programmes are written not by professional developers but by people with expertise in other domains, and documented the full range of software engineering challenges these end-user programmers face: requirements, design, reuse, integration, testing, debugging. Even people with professional development experience doing end-user programming, the survey found, would not approach the work with the same quality goals they would apply to production code. Burnett's (2009) earlier framing of the underlying tension remains precise: "end-user programming empowers - but to do what? Make really bad decisions based on really bad programs?" The empowerment case is real; the question is whether the capability the tool provides is matched to the capability the user actually has.
Within the analytics domain specifically, Kandel et al.'s (2012) interview study identified three analyst archetypes varying widely in programming proficiency and reliance on IT support. The Application User archetype - relying on GUI-based tools and pre-prepared data infrastructure - maps directly onto the analyst population that NHS data platforms now expect to build React applications. Treating "analyst" as a homogeneous category that can uniformly absorb frontend development responsibility ignores this well-documented variation. Tory et al.'s (2023) identification of "data workers" - those for whom data use is not a primary role - as an under-recognised and under-served population reinforces the concern: tooling designed for professional analysts is being extended into software engineering territory that professional analysts themselves rarely occupy.
The programme's own experience made the skills gap concrete. As one programme engineer described the actual requirement for an analyst operating in the React and typed API workflow:
"We're basically going to ask analysts to say, you need to do all your pre-calculations in PySpark, which you probably don't know because you've used SQL before. You're not allowed to write any calculations in the front end. You've got to go and create a TypeScript repository and learn TypeScript to aggregate it".
The design risk compounds the skills gap, and it operates at a level that a well-maintained component library cannot address. Frost's (2016) atomic design hierarchy is instructive here: standardising atoms and molecules - the button components, form inputs, and chart primitives that a component library provides - leaves the organism, template, and page levels entirely open. Analysts assembling those components into actual dashboards will make different structural choices about information hierarchy, narrative sequence, contextual framing, and layout; the outputs will be visually consistent at the component level and incoherent at the page level, which is where analytical meaning is actually constructed and communicated. A component library resolves the lowest-level design problem while leaving the highest-level one untouched.
The obvious response - enforce standardisation at the template or page level, constraining how analysts assemble components into outputs - runs directly into the problem that the previous post identified in the native dashboard environment. Rigid template standardisation is precisely what suppresses the communicative and social function of analytical work: the ability to frame data differently for different audiences, to construct a narrative around a finding, to present the same dataset as a briefing paper for one stakeholder and an operational dashboard for another. Tory and Bartram (2021) establish this as central to analytical value - the "conversation through and around data" that produces meaning rather than merely transmitting it. An analyst forced into a fixed template cannot have that conversation; they can only fill the template. The fragmentation problem and the standardisation problem are not two points on a dial that can be dialled to an acceptable middle; they represent a structural tension in what self-service analytical tooling is being asked to do.
Blue: analyst-owned. Green: published output. Orange: engineering dependency. Red: new capability required of analyst. Amber: governance gap. The first four workflows each require three steps, all within analyst competence. Even R Shiny, which produces interactive web applications, stays within the analyst's existing language. The React workflow requires seven steps, with engineering dependencies at steps 2–3 and entirely new skills required at steps 4–6.
AI code-assist tools are increasingly offered as the response to this skills gap. The evidence warrants scepticism, particularly in a healthcare data context. Perry et al. (2022) found that approximately 40% of programmes generated by AI coding assistants contain exploitable security vulnerabilities, and that developers using these tools were more confident in their submissions despite the flaws. Fu et al. (2024) analysed 733 code snippets from real GitHub repositories and found that 29.5% of Python and 24.2% of JavaScript snippets generated by AI tools contained security weaknesses. An analyst using code-assist to write queries against a platform's typed API layer without understanding the underlying type system will produce code that compiles but does not do what they intend, in an environment where audit trails, data protection, and access controls are not negotiable.
Accessibility as a structural forcing function
There is a further dimension to the React strategy that rarely surfaces explicitly in programme discussions: the use of custom frontends as an escape route from a proprietary presentation layer that cannot meet public sector accessibility and branding obligations.
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require all public sector digital services to meet WCAG 2.2 AA. The GDS Way states explicitly that accessibility compliance cannot be guaranteed by any third-party system, and the legal requirement applies regardless of whether the tool is enterprise-grade or proprietary. The NHS digital service manual requires external suppliers contracted to the NHS to meet the same standard.
Enterprise BI platforms have a poor accessibility record. Power BI's screen reader support has been assessed as "extraordinarily difficult" to navigate, with compliance described as "highly dependent upon the report creator" - effectively externalising the burden to non-specialists. For the platform in this programme context, no Voluntary Product Accessibility Template or Accessibility Conformance Report was available in public documentation; the vendor's published claims amounted to a high-level assertion of operating in accessibility-required environments, without detail on which components, at what conformance level, or with what testing evidence. The platform's native dashboard environment was not built to the NHS design system; its customisation was limited to header formatting, background colours from a fixed palette, and border styles.
For organisations building NHS-branded, publicly accessible dashboards, this creates a structural forcing function: exiting the native presentation layer and building custom frontends is a compliance necessity for that class of products, not an analyst capability upgrade. The React strategy in programme discussions collapsed this distinction. React as a compliance mechanism for public-facing, accessibility-obligated products is a legitimate and well-scoped use. React as a general-purpose analyst tooling upgrade, through which the broad analyst population builds and maintains its analytical outputs, is a categorically different proposition, and one the accessibility rationale does not support.
Deployment, sustainability, and the citizen development record
The deployment and maintenance burden receives little attention in programme documentation. Under the hybrid model that emerged - React components hosted on dedicated subdomains - a single national report with three tabs required three dedicated subdomains. A national analytical function with hundreds of analysts each building and deploying applications would require deployment pipelines, subdomain management, version tracking, and dependency update processes that did not exist and had not been designed.
This is a sustainability problem as much as a scale problem. Muller et al.'s (2019) documentation of invisible labour - work that creates and sustains the conditions for data-driven activity but is not visible as infrastructure, only as the individual outputs it enables - applies directly. The workstation owners in this programme context had accumulated responsibilities for data stewardship, user access management, code maintenance, and compute cost management that were never formally defined, documented, or trained for. When those people change roles, the knowledge moves with them; the platform has no mechanism for capturing it.
Binzer and Winkler's (2022) systematic review of the citizen development literature identifies governance as the central unresolved problem across the field. The deployment and sustainability challenges are not isolated failures but structural features of citizen development at scale, and they recur precisely because the governance required to address them is not designed in advance. The fragmentation concern is also the inverse of the original motivation: the native dashboard environment produced inconsistent outputs because teams built differently within its constraints; React without centralised deployment governance produces inconsistent outputs because teams build, deploy, and maintain differently without constraints. The consistency problem relocates rather than resolves.
What the division of labour should look like
The engineer-to-analyst handoff model - build a React product, then hand it to analysts to maintain and extend - is not obviously wrong as an aspiration. A comparable national NHS analytical product demonstrates one workable version: a centralised React application with a standardised data ingestion model into which analysts contribute structured data rather than building frontends. Analysts do not need React; they need the data specification. The frontend is maintained by a specialist team. The distinction this instantiates - between analysts using a React-based product and analysts building and maintaining React-based products - is the distinction the broader programme strategy had not resolved.
A tiered model proposed informally within the programme, and supported by the citizen development literature, offers a more sustainable account of the division of labour.
Under the tiered model: the native dashboard environment as the default for standard analytical products; extended visualisation capability for complex charting requirements within the native environment's extensibility boundary; React reserved for engineer-built exceptional cases with a clear compliance or portability rationale. None of this was formally agreed. The programme proceeded to train analysts in React.
Under this model, React is infrastructure rather than analyst tooling: maintained by a specialist engineering capability, governed by clear standards, deployed through managed pipelines, accessible to analysts as the audience for products rather than as their builders. Analysts contribute domain knowledge, data specification, analytical methodology, and requirements; engineers contribute software quality, deployment infrastructure, accessibility compliance, and maintainability. This is not a regression from an ambitious vision of analyst self-service; it is the division of labour that the evidence consistently supports.
The four-day React training course that was procured - with prerequisite fluency in HTML, CSS, and JavaScript - covered React basics without addressing API integration, NHS design system component usage, dashboard design patterns, end-to-end testing, or QA processes for analyst-built applications. None of those things existed in documented form when the training ran. The course is better understood as a proxy for a strategy that had not yet resolved what kind of applications analysts should be building, who should govern them, and what sustainability looked like at the scale the programme required.
The governance question
Bock (2021) identifies in the citizen development literature a propensity toward inflated promises in how platforms are presented to organisations. The analyst-as-developer proposition in this programme context exhibits recognisable features of the same pattern: a demonstration of a technically sophisticated output produced by specialist engineers; approval by senior stakeholders based on that demonstration; implementation reality encountered later by people who are not those engineers. The pattern is not unique to this context; it is a structural feature of vendor-client relationships where technical fluency is unevenly distributed across the decision-making process.
The governance question is not whether analysts should use platforms to produce analytical products - they should, and reducing engineering bottlenecks is a legitimate ambition. It is whether governance structures are designed to distinguish between the tiers: to identify which outputs require engineer-built, centrally maintained infrastructure; which require the mid-tier extension capability; and which the native environment handles adequately. Without that distinction, strategy defaults to the path of least resistance - whichever tier is easiest to demonstrate - rather than the path most likely to produce sustainable analytical capability at the scale the programme requires.
This post draws on observations and meeting records from a NHS data platform programme. All individuals are referenced by role. Where direct speech is used, it reflects contemporaneous notes rather than verbatim transcripts.
References
Binzer, B. & Winkler, T.J. (2022). Democratizing Software Development: A Systematic Multivocal Literature Review and Research Agenda on Citizen Development. In Proceedings of ICSOB 2022. Springer.
Bock, A. (2021). Low-code platform. Business & Information Systems Engineering, 63(6), 733–740.
Burnett, M. (2009). What is end-user software engineering and why does it matter? In IS-EUD 2009. Springer.
Frost, B. (2016). Atomic Design. Brad Frost Web.
Fu, M., Tantithamthavorn, C., Le, T., Nguyen, V. & Ghose, A. (2024). Security weaknesses of Copilot-generated code in GitHub projects: An empirical study. ACM Transactions on Software Engineering and Methodology.
Kandel, S., Paepcke, A., Hellerstein, J. & Heer, J. (2012). Enterprise data analysis and visualization: An interview study. IEEE Transactions on Visualization and Computer Graphics, 18(12), 2917–2926.
Ko, A.J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., Scaffidi, C., Lawrance, J., Lieberman, H., Myers, B., Rosson, M.B., Rothermel, G., Shaw, M. & Wiedenbeck, S. (2011). The state of the art in end-user software engineering. ACM Computing Surveys, 43(3), 1–44.
Muller, M., Lange, I., Wang, D., Piorkowski, D., Tsay, J., Liao, Q.V., Dugan, C. & Erickson, T. (2019). How data science workers work with data: Discovery, capture, curation, design, creation. Proceedings of CHI 2019. ACM.
Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2022). Do users write more insecure code with AI assistants? arXiv:2211.03622.
Tory, M. & Bartram, L. (2021). Conversations with data: Understanding analyst and dashboard user workflows. IEEE Computer Graphics and Applications, 41(6), 15–26.
Tory, M., Bartram, L., Fiore-Gartland, B. & Crisan, A. (2023). Data workers and their workplace. IEEE Computer Graphics and Applications, 43(2), 19–30.