Creating a Design System for the Public Sector
Working for a large public sector client that comprises diverse applications and departments can present many challenges when it comes to ensuring a consistent user experience. This was particularly evident for the client I currently work for.
As the cacophonous image below illustrates, a lack of consistency on even the simplest of items such as buttons increases the cognitive load for a user but also adds unnecessary development effort and maintenance for developers.
The image was taken from an internal UX audit of the client’s systems and similar issues were pervasive across all applications. For the end-user, complex processes become just that little bit harder when your primary action on a page jumps to various locations each step of the way. For the developer, lack of clear guidance promotes ambiguity and wasted effort. How can we build a smooth efficient workflow when we can’t even get the basics right?
What can one person do to make a change?
I work across multiple Agile teams to improve the UX of a suite of related applications and support developers with front-end development. I began to see the same questions and problems appearing repeatedly so I started to look at smaller incremental processes that could be improved to promote better practices.
Tackling these issues wasn’t solely selfless. I wanted to save myself time from repetition, but I also felt I could bring real value to my team and others. Version1 actively pursues a ‘Value Add’ initiative with their clients directly focussed on these types of problems i.e., taking everyday pain points and offering solutions.
Below I highlight some of the key issues that I experience day to day, not just for me but other developers on my team:
- The existing process of UI management was the dissemination of PDFs which didn’t provide guidance on how to implement the code
- Without guidance from designer to the developer the team wouldn’t estimate or cater for proper UI implementation
- New applications would copy over CSS from an existing one and inherit unnecessary code often leading to more being written to overwrite it
- Without proper guidance or governance divergences and inconsistency arose leading to confusion for developers.
- Cross-browser compatibility and accessibility is often tested at the end of a development phase which can be too late to make changes.
- User experience and UI is often deemed subjective with individual teams deciding a slightly different solution to a requirement.
- Inconsistency across screens looked poor and didn’t reflect well on the reputation of the client
If you find yourself nodding along to these issues perhaps take stock of the culture around UI/UX governance in your workplace, and the below solution is something you too could bring forward to your team.
Beginnings of a Design system.
One solution that companies employ is design systems that document UI components to varying degrees of accessibility, documentation, and code. This is valuable but quantifiable time savings are often hard to establish to justify its use. Rather than trying to get buy-in from management, I began tackling the issues from the ground up and iteratively documenting existing components, focus on the key areas of HTML and CSS; accessibility; UI/ UX best practices; developer guidance.
A developers’ time is a precious commodity so I knew any approach would need to fit seamlessly into existing work processes to get them on board while keeping it simple and accessible for the business users and new joiners. I proceeded with using technologies familiar to most developers with the application.
Gitlab, used by all developers on the client site for version control was used as our database. It would house all the static HTML pages which document each component and comprised of the necessary HTML, style tags with CSS specific to the component, and notes on guidance. There is nothing overly complex within these pages, just HTML, CSS, and notes, each wrapped in a custom tag for parsing later by the calling application.
The front-end was built using Angular which calls the GitLab API to get a list of all components, separated by category, to create a navigation pane. Any additional documentation and research, as well as dependencies, can be stored in one central location for dissemination. Versioning, permissions, and quality control are all managed by GitLab. GitLab could also be used to assign and track the status of features so people interested in getting this up and running but from a project management discipline could then get involved, opening the way for more input and traction.
It’s easier to explain how the design system worked through screenshots of the application.
Benefits to the team and client
Overall, the benefits this brought to my team were instant, summed up best by the following feedback from the client:
“It has allowed developers within the team to work to a consistent look feel while at the same time reducing the time spent on front end development and design concepts and standardising the User Experience for any new functionality. In certain instances, it has also been adopted by other development teams pointing the direction for how a design system could be used to scale the benefits achieved to all departments.”
Importantly a budget was found to enhance its features beyond a basic proof of concept, and I could allocate a certain amount of time per week to work on the design system.
The noticeable and tangible benefits experienced by my team include:
- Developer estimates were more accurate for front-end development tasks
- Test estimates also improved and there was less ambiguity around expected behaviour
- As an Agile team, we could ‘shift left’ a lot of the development and testing such as cross-browser testing and basic accessibility
- Business members could browse existing solutions to problems and better inform their requirements
- Reduction in duplication of work and the development of the UI for new requirements was faster
- One location for department-wide styles, icons, fonts, dependencies, and documentation
- Master files of CSS were kept clean of any bloating and quality ensured
- New components were documented and refactored to provide best practices and guidelines to developers
- Consistency across related applications in both action and meaning
- Helped reinforce AA accessibility standards
Next steps
After the benefits became evident the requests for additional features began, which more than one developer (myself) could accomplish. Items such as tighter integration with design tools like Adobe XD, importable components into angular applications, and documentation and audits of other departments.
A new suite of applications is in the process of being developed with the aim to use a design system as an integral part of their design, implementation, and management. This has begun the cultural shift towards better UI/ UX governance with the organisation. Ideally, I would love to see a move similar to that of GOVUK with a universal and cohesive approach to government web applications, but to date, it has been a huge leap forward since when I first started. Now with buy-in from the client, along with the previous momentum gained from my design system, these will be exciting next steps.
About the Author
Ian Slattery is currently a Business Applications Consultant for Version 1’s Ireland Digital and Cloud Practice.
