OpenCities provides the website and form functionality that modern Governments need to transform their digital customer journey.
As a SaaS platform that powers millions of resident interactions around the world, OpenCities leverages rich usage data and machine learning to continuously evolve its customer experience.
Enabling Governments of every size to deliver world-class digital experiences, OpenCities re-imagines how councils procure, deliver and evolve their website and online services.
The OpenCities CMS boasts a series of functionally accessible and responsive components out of the box, which set a solid foundation for the designs to be built upon.
As the sole designer in Australia and New Zealand, I was responsible for creating beautiful and modern themes for OpenCities' clients – two things that are rarely associated with Government.
As the sole client-facing designer across Australia and New Zealand, I was responsible for walking clients through the design process and running a variety of workshops and discovery sessions with local Government stakeholders.
These workshops allowed me to dig deeper into the client's needs, determining the feasibility of their requests, how closely they align with user needs, how their branding would be incorporated into this solution, and advising clients around meeting WCAG 2.0 accessibility standards.
Utilising the expansive OpenCities front-end component library and theming capabilities, I created designs for a variety of local Governments throughout Australia, New Zealand and the United States. Themes would vary from main council websites to those of local events and facilities within any given local Government area.
At its crux, OpenCities was built on the ideology of serving better – the government and its residents, the software and its users, the company and its staff.
As a senior designer, having joined a newly established team with a low level of design maturity, I began exploring ways to improve processes, enhance output, and eliminate the pain points experienced by the implementation team and its clients. Some of which included:
- Lack of consistency between workshop content and design delivery between Australian/New Zealand and U.S teams
- Double-handling of design elements, lacking a source of truth and reasoning behind each component's rigidity
- Reliance on developers to fill in gaps that were missed throughout the design process
- Ineffective handling of design feedback and iteration
- Difficulty onboarding new staff who were unfamiliar with the complexities and intricacies of working with a rigid CMS, and/or those who had little experience working alongside WCAG 2.0 accessibility requirements
- Lack of documentation, educating new hires about the OpenCities CMS and the flexibility (or lack-there-of) within it
Knowing that each client would have their own colour system, fonts and graphics library, would a published component library that we pulled into each file be the most efficient approach given the intricacies of our use case? Probably not.
I began thinking about the idea of creating a toolkit that could be utilised to educate designers, run more engaging and true-to-product workshops, ensure consistency in development handover, as well as automate some of the more tedious handover requirements.
"Murphy's big-picture, customer-centric view and commitment to design excellence shows through not only in the output of her work, but also her customer interactions, leading to smoother project and improved customer outcomes"
After much deliberation, I began putting together a master file that could handle the intricacies of what we required. Throughout the file, I set up a series of base styles, following what existed within the code library, recreating each component and content block that existed within the CMS in Figma.
I then put together a greyscale palette (in an attempt to prevent pushback or colour bias from external stakeholders), following a primary, secondary and tertiary colour, with a couple of accents included, all of which followed WCAG 2.0 accessibility requirements out of the box. This then meant that if the documentation was followed, we could bulk-style and automate some of the design required.
The file that housed all of this information – alongside tips and tricks to handling some of the intricacies of accessibility contrast requirements, elements that must remain as they are, etc. – became the standard for the design team to duplicate for each project. Among many other things, it allowed us to:
- Run meetings/workshops from the file directly, building out wireframes in real-time
- Provide developers with consistent handling and file structure
- Onboard new designers with confidence, educating them about the CMS and accessibility requirements while they work
- Request feedback directly from Figma prototypes, eliminating guess-work and understanding the true context of each change request
- Style internal page components without additional time or resources, as simple as a click of the button
- See more consistency between the proposed designs and website when built
"You are upping the game for our entire client implementation process"