Final Assessment Checklist
What is being Assessed
The Service shall be assessed in all the areas of all the Sections of the Service Standard. The Service Team shall submit all the necessary evidence to promote compliance with the Service Standard. A demonstration of the service, along with all the requested evidence concerning the method, steps and implementation of the service, will be necessary.
Section A: Understanding User Needs
For the following areas of assessment:
1. Understand users and their needs
2. Solve a whole problem for users
if the Service has obtained an “Aligned” result during the Preliminary Assessment Session, it will proceed for assessment on the next area (number 3. below) of the current ‘Section A’.
However, if it has not undergone the Preliminary Assessment, this will be carried out as part of the current evaluation, and all its steps will be followed.
3. Provide a joined-up experience across all channels
| Areas to be explored | Evidence of Work |
|---|---|
| 3.1 – Ability of users to complete their goal across online and offline channels | ● Offline user journey flow designs ● Online user journey |
| 3.2 – Consistency of User experience across all channels (online and offline) | ● Offline user journey flow designs ● Online user journey flow designs |
4. Make the service simple to use
| Areas to be explored | Evidence of Work |
| 4.1 – Simple and easily understood language within the service | Notes from user research findings Before and after screenshots of pages iterated according to findings |
| 4.2 – Consistent styles with the Digital Services Design System | 4.2.1 – Follow the design system principles |
| 4.2.2 – Include the HTML 5 important globals in the<head> section of the HTML as defined in the design system | |
| 4.2.3 – include title and description in the <head> section of the HTML as defined in the design system | |
| 4.2.4 – Include social meta tags in the <head> section of the HTML as defined in the design system | |
| 4.2.5 – Include theme meta tags and manifest.json in the <head> section of the HTML as defined in the design system | |
| 4.2.6 – Use the right colours in the service as defined in the design system | |
| 4.2.7 – Use the right page template in the service, which includes max width, responsive breakpoint, and the designated sections as defined in the design system | |
| 4.2.8 – The content shall follow the vertical spacing rules as defined in the design system | |
| 4.2.9 – Use one of the layouts as defined in the design system | |
| 4.2.10 – Use the right typography rules as defined in the design system | |
| 4.2.11 – Include a gov.cy header as defined in the design system | |
| 4.2.23 – If you used different design elements than the ones specified in the design system, explain with evidence: ● how the design system’s elements fail ● how the new design elements benefit the users ● how they align the principles of the design system. | |
| 4.2.13 – Include the skip link in all pages as defined in the design system | |
| 4.2.14 – Include a back or breadcrumbs components as defined in the design system | |
| 4.2.15 – Include a page title (header `<h1>`) in all pages as defined in the design system | |
| 4.2.16 – Follow the guidance for focus state on interactive elements as defined in the design system | |
| 4.2.17 – Place elements in the correct order as defined in the design system | |
| 4.2.7 – Use the right page template in the service, which includes max-width, responsive breakpoint, and the designated sections as defined in the design system | |
| 4.2.19 – Indicate error messages and error summary as defined in the design system | |
| 4.2.20 – Follow the structuring a service and question pages pattern to get input from the users | |
| 4.2.21 – Use the check answers pattern before users submit information to your service | |
| 4.2.22 – Use the user interface elements components and patterns the way they are defined in the design system | |
| 4.2.23 – If you used different design elements than the ones specified in the design system, explain with evidence: ● how the design system’s elements fail ● how the new designs elements benefit the users ● how they align the principles of the design system. | |
| 4.3 – Test the service on a variety of devices | ● The list of devices (e.g. laptop, tablet, mobile phone) with relevant screenshots ● A flow of the service on at least one of the devices |
5. Make sure everyone can use the service
| Areas to be explored | Evidence of Work |
|---|---|
| 5.1 – Check the online service for accessibility in accordance with the Cyprus Accessibility Standards | Accessibility test (results) report |
| 5.2 – User research of the service with all potential groups of users, including people with accessibility needs | User research findings report with results of people with accessibility needs |
Section B: Leading Agile Teams
For the following areas of assessment:
6. Have a multidisciplinary team
7. Use Agile ways of working
if the Service has obtained an “Aligned” result during the Preliminary Assessment Session, it will proceed for assessment on the next area (number 8. below) of the current ‘Section B’.
However, if it has not undergone the Preliminary Assessment, this will be carried out as part of the current evaluation, and all its steps will be followed.
8. Iterate and improve frequently
| Areas to be explored | Evidence of Work |
|---|---|
| 8.1 – Any iterations based on user research/needs, if exist | The list of the iteration features and the value to the users based on user research |
Section C: Choosing the right technology
9. Create a secure service which protects users’ privacy
| Areas to be explored | Evidence of Work |
| 9.1 – Relevant laws on data protection including EU data protection rules that apply to the service | Data Protection Impact Assessment (DPIA) report with the relevant approval, where applicable |
| 9.2 – Users’ personal data been collected and processed in a way that ensures their privacy | |
| 9.3 – Performance of penetration testing on the service | Penetration Test (results) report |
| 9.4 – Performance of Web Application Security Assessment (WASA) of the service | Web Application Security Assessment report |
10. Define what success looks like and publish performance data
| Areas to be explored | Evidence of Work |
|---|---|
| 10.1 – KPIs/success metrics based on identified user needs for the service | User needs and key performance indicators (KPIs) measured for the service (see Performance Framework) |
| 10.2 – Methods/tools for gathering KPI/performance data | ● The methods/tools used ● A list of data gathered |
11. Choose the right tools and technology
| Areas to be explored | Evidence of Work |
| 11.1 – Technology choice | Total cost of ownership |
| 11.2 – Compliance of Technology chosen with the DSF Technical Principles | ● System design document ● Solution architecture document |
| 11.3 – Use of proven, mature, adopted, and open standards technology |
12. Make your data and functionality available via APIs
| Areas to be explored | Evidence of Work |
| 12.1 – Use common patterns such as REST for service’s APIs | API documentation including the uniform resource identifiers (URIs) |
| 12.2 – Test of the APIs and the service | Test report |
| 12.3 – Enforce security standards on the APIs | Screenshot of the SSL certificate including the uniform resource locator (URL) |
13. Use and contribute to open standards, common components and patterns
| Areas to be explored | Evidence of Work |
|---|---|
| 13.1 – Open standards used (existing or new) | ● System design document ● Solution architecture document |
| 13.2 – Use of DSF Design System common components and patterns | ● List of components used with screenshots (distinguish which are from the DSF Design System and which are not) In case the service does not use common components and patterns, demonstrate a clear user need for not doing so and share relevant documentation ● Copy of open source code licence |
14. Operate a reliable service
| Areas to be explored | Evidence of Work |
| 14.1 – Test the service in an environment similar to live to anticipate issues that could cause downtime, and mitigate them | Test report |
| 14.2 – Regular deployment of changes on the service with minimal disruption to the service? | ● System design document ● Solution architecture document |
| 14.3 – Availability of README and CHANGELOG files | ● a README file named “README.md” (see About the README file – Digital Services Factory (dmrid.gov.cy)) ● a CHANGELOG file named “CHANGELOG.md” (see About the CHANGELOG file – Digital Services Factory (dmrid.gov.cy)) |
15. Ensure your service is ‘DSF ready’
| Areas to be explored | Evidence of Work |
| 15.1 – Service’s other hosting options (such as on-premises hosting) | ● System design document ● Solution architecture document |
| 15.2 – Follow of 12 factor methodology to support portability and resilience (https://12factor.net/) | |
| 15.3 – Containerisation of the service and on which infrastructures can the service run to provide broad hosting options |
