Discover
To determine the value of the portal for the users, their interests and ways of using the portal, we created a persona mindset map, based on the services provided via the portal, the existing use data and statistics. Next, we developed a customer journey map for each persona, which gave us a better idea of their expectations regarding the services in the portal. We conducted discussions with representatives of the various interest groups to confirm the conclusions we drew from the analysis.
Proof of Concept
The objective of this phase was to combine the interests of the end users and the possibilities that the state portal could offer.
Build and test
In the development phase we enhanced and upgraded the VEERA design system used by the state. With the help of this we created Click Dummy tests for the validated customer journeys, which our development partner started to work on and implement.
As a part of our latest project, we have built an entire component library called CVI that implements a design system used at Eesti.ee.
Since CVI is used in government-level projects, the requirements for usability and accessibility are high. The library must conform to the AA level of the WCAG 2.2 standard. WCAG stands for accessibility standards called Web Content Accessibility Guidelines (WCAG) that aim to make new technologies accessible to everyone. WCAG’s primary purpose is to provide a clear set of rules, based on years of research and testing.
Keyboard navigation, equal access to the UI for screen readers and other assistive devices, and the ability to present content for people with visual disabilities are all requirements when a new component for CVI is developed. The accessibility design starts with the component ideation but does not finish with the release. User feedback and continuous testing inform improvements. And with the library code open-sourced, everybody is allowed to participate.
Similar to state-level UI libraries in other countries like the UK or Netherlands, CVI is designed for growth. Given the library’s scale and fast iteration rate, manually testing each component and updating for their accessibility performance would be highly inefficient. This is why we created an automated testing process.
CVI employs an open-source accessibility testing engine called Axe. Upon every component update, the engine tests the code automatically, applying more than 100 rules. As the check is mandatory, code can only be submitted to the library if it has been tested. An error discovered during automatic testing will be immediately communicated to the developer, allowing the issue to be fixed. The check can also be initiated manually before changes are committed. However, a positive result doesn’t mean components are fully accessible – as mentioned above, no automation will replace all human effort, and testing with various assistive devices and real users is still conducted.
Since the testing had been deployed, we have tested and published more than 200 library updates. The testing has already saved a lot of time, allowing us to focus on the most complicated components and scenarios. The same engine has since been employed in other design systems and component libraries that Nortal works on.
