Awarded to Jumping Rivers Ltd

Start date: Monday 4 October 2021
Value: £65,000
Company size: SME
The National Archives

Develop DiAGRAM prototype to meet accessibility standards and make improvements to user interface

7 Incomplete applications

6 SME, 1 large

2 Completed applications

2 SME, 0 large

Important dates

Wednesday 4 August 2021
Deadline for asking questions
Wednesday 11 August 2021 at 11:59pm GMT
Closing date for applications
Wednesday 18 August 2021 at 11:59pm GMT


Off-payroll (IR35) determination
Supply of resource: the off-payroll rules will apply to any workers engaged through a qualifying intermediary, such as their own limited company
Summary of the work
Improve the accessibility of a software application (currently developed in R/Shiny) through front-end development to meet the following standards: GDS service standard; Web Content Accessibility Guidelines (WCAG) 2.1 level AA. Improve the usability of the interface.
Latest start date
Monday 30 August 2021
Expected contract length
Four months with potential extension to a maximum of six months.
No specific location, for example they can work remotely
Organisation the work is for
The National Archives
Budget range
£65k maximum for 4 months, if extended to 6 months maximum total value of £100k.

About the work

Why the work is being done
DiAGRAM (Digital Archiving Graphical Risk Assessment Model) is an integrated decision support tool built on an underlying Bayesian statistical model. It was developed by the NLHF funded project “Safeguarding the Nation’s Digital Heritage” as a risk assessment tool for UK and international archives.
A prototype tool was created using R/Shiny for rapid development and easy incorporation of advanced statistical processing. This prototype has accessibility issues that have prevented us releasing the tool as a live service. These accessibility issues now need to be addressed.
This is a complex system, parts of the user interface are not intuitive to non-specialist users and require testing and refinement to expose more of the underlying mathematical principles.
Problem to be solved
1. Develop the DiAGRAM prototype to meet the accessibility standards set out in GDS service standards and Web Content Accessibility Guidelines (WCAG) 2.1 level AA (and the NCSC standards for system security).
Determine whether the DiAGRAM prototype can be developed within the current R/Shiny architecture to meet the accessibility standards and, if so, carry out the necessary improvements.
If not, recommend an alternative architecture (consistent with the architectures and technologies currently in use at The National Archives) that will enable the accessibility standards to be met, while maintaining functionality that is at least equivalent to the existing prototype. Agree and implement these changes.
Test the service against the specified standards and provide evidence that the criteria are met.
2. Develop the DiAGRAM prototype to improve the user interface of the ‘advanced customisation’ feature of the tool.
If the available time and budget allows, implement refinements to the user interface to improve ease of use and understanding, testing these with archivists from The National Archives or elsewhere.
Who the users are and what they need to do
Users are primarily UK-based archives professionals working with digital archival materials. They may also be from the wider GLAM (galleries, libraries, archives and museums) sector and/or from institutions based outside the UK. DiAGRAM allows these users to model the risks to the digital heritage for which they are responsible. They may be interested purely in understanding the current risks, but DiAGRAM also supports advocacy, enabling users to model alternative scenarios representing potential different levels of investment into preservation services or different approaches to reducing risk, to assist in engaging stakeholders or preparing business cases for action or investment.
Early market engagement
The Alpha prototype was created by a consortium including statistical experts, user experience experts and developers. This work is to continue development of the prototype to make it ready for formal release.
The tool will be subject to an internal service assessment process to GDS Service standards.
The prototype tool is live at
The code is available at
Any work that’s already been done
The full prototype is available as described above, and all outputs of the wider project.
A formal accessibility audit is being carried out and the report will be available to the appointed supplier. Retesting for certification will be carried out at the end of the project period. We also have findings from initial user research, additional research and testing may be required to define the problem space.
Existing team
Product Manager (part-time). The Product Manager has an archives and maths background and worked on the original project. There is some potential for input from the wider department including user researchers. There is some potential for input from archivists as testers of any changes. We expect to have a user researcher on placement from the latter part of September.
The original project team is no longer in place. We are looking to the supplier to resource and manage delivery of this work, in close collaboration with The National Archives Product Manager.
Current phase

Work setup

Address where the work will take place
Work will take place at the supplier’s premises. The National Archives staff are working fully remotely.
Working arrangements
TNA staff will be available during a UK 9-5 working day.

The supplier to provide their own equipment and technology. You will need access to R, GitHub, Slack and the ability to download R packages.

The work will be delivered by the supplier to standards set by TNA.

The supplier will work in an Agile way to scope, plan and deliver the work incrementally, with regular active communication and demonstrations and reviews of progress.

Regular virtual meetings will be on MS Teams, Slack will be used for quick communications. There is some flexibility with the choice of virtual communication methods.
Security clearance
Baseline security clearance will be required (BPSS).

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
  • Strong experience of developing applications in R using Shiny and other supporting packages (please specify). Be able to familiarise themselves with such an application quickly.
  • Strong experience of developing accessible applications in modern programming languages such as Java and Python.
  • Experience of User Interface development for a web-based application which includes interactive graphs and visualisations.
  • Expertise in testing components and pages against accessibility standards and fixing accessibility issues identified through testing.
  • Write clean, accessible and performant code that it is open by default and easy for others to re-use.
  • Work in an Agile way, following a test-driven approach and demonstrating progress and discussing findings regularly.
  • Initiative in proposing and testing different ways to improve the tool’s accessibility.
Nice-to-have skills and experience
  • Have a working knowledge of Git for version control.
  • Have a working knowledge of HTML, CSS and/or JavaScript.
  • Have a working knowledge of performance optimisation.
  • Have a background in statistics or analysis.

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How many suppliers to evaluate
Proposal criteria
  • Describe how you would go about familiarising yourselves with the current codebase and determining the extent to which the accessibility issues identified can be resolved within the current architecture
  • If that would not be possible, describe how you would determine an appropriate alternative technical solution and plan the conversion from the current architecture
  • Your case study/work history should show evidence of the use of the proposed approach.
  • Describe how you would identify risks/dependencies within your approach and methodology for addressing accessibility issues, and mitigations to ensure quality and timely delivery. Provide examples in your case study/work history.
  • Provide examples in your case study/work history.
Cultural fit criteria
  • Communicate clearly and effectively with technical and non-technical colleagues.
  • Actively seek feedback to steer their developments.
  • Apply technical expertise to find the best solution to a problem.
  • Work independently and at pace to deliver work to agreed standards and deadlines.
Payment approach
Capped time and materials
Additional assessment methods
  • Case study
  • Work history
  • Reference
  • Presentation
Evaluation weighting

Technical competence


Cultural fit




Questions asked by suppliers

1. Can resources work from outside UK (Offshore)?
Yes, though you should note that our staff will only be available in UK hours.

You may be marked down on cultural fit if the evaluation panel feel it may be difficult to schedule calls with you at an appropriate time.