Overview
Governments often rely on legacy digital transaction systems that have been built in an ad-hoc manner over time. This results in inconsistent user experiences, redundant maintenance efforts, and difficulty in scaling new services efficiently. TaPaaS (Transactions Platform as a Service) was initiated to address these challenges by creating a standardised, scalable, and modular platform for government transactions.
Business goals
- Uncap business capacity to take on new work, generating new revenue
- Reduce maintenance costs by 80%
- Increase speed to market by 50%
- Reduce cost of delivery to enable smaller agencies to go digital with Service NSW
- Deliver a consistent user experience
- Increase velocity of design activities
Design challenges
From a design perspective, the core challenge in standardising government transactions was balancing consistency and flexibility. Government services vary widely in complexity, user needs, and regulatory requirements, making it difficult to apply a rigid, one-size-fits-all solution.
Transactions range from simple payments to multi-step applications requiring verification, document uploads, and approvals. A standardised framework had to accommodate variation without sacrificing usability.
While a modular system reduces redundancy and improves efficiency, agencies often need tailored experiences for their services. A balance needed to be struck, defining where flexibility was necessary and where strict standardisation was beneficial.
Citizens interact with multiple government services and expect a predictable and intuitive flow. Standardisation meant designing reusable patterns, structures, and interactions that worked across services, ensuring a seamless user experience.
Transactions range from simple payments to multi-step applications requiring verification, document uploads, and approvals. A standardised framework had to accommodate variation without sacrificing usability.
While a modular system reduces redundancy and improves efficiency, agencies often need tailored experiences for their services. A balance needed to be struck, defining where flexibility was necessary and where strict standardisation was beneficial.
Citizens interact with multiple government services and expect a predictable and intuitive flow. Standardisation meant designing reusable patterns, structures, and interactions that worked across services, ensuring a seamless user experience.
Mazlow's hierarchy of standards.
The process
As lead designer on this tranche, I developed a process for us to follow, aligning to team dependencies and our timeline, and enabling asynchronous work for other design and development efforts.
Some process slides. Click to enlarge.
Audit
The team conducted an audit of approximately 20 transactions, analysing every UI component based on:
- Form (the UI component type)
- Function (its purpose in the user journey)
This helped identify consistent vs. inconsistent component usage, laying the groundwork for standardization.
Prioritisation
Findings were compiled into a heatmap, highlighting:
- Components requiring standardization
- The effort needed for alignment
This allowed the team to prioritise components based on impact and effort.
Collation
Components were grouped based on shared functionality. This helped in defining core design patterns and eliminating redundancy under a unified standard
Design & Ratification
Designers compared UI variations using a heuristic framework to determine the ideal standard. Components were tested in all relevant contexts to ensure future-proofing. A design council reviewed and ratified the final components for consistency.
Documentation
Finalised components were documented in Figma templates, detailing:
- Variants, states, and use cases
- Do’s and don’ts for implementation
- Accessibility considerations
This ensured clear guidelines for adoption across all government services.
Click into the images to get some indication of project scope.
The outcome
With this process we have have standardised about 160 components facilitating 120 functions, consolidating it down to around30 components and their variants.
We are yet to commence build, but we have succeeded in meeting our goal by our deadline. This was the first of many steps in unblocking the growth and revenue streams for our agency by reducing time to build by 50% and limit maintenance costs to a maximum threshold that doesn't grow with new agency transactions onboarded.
All of our process and rationale is thoroughly documented, and handover documents are prepared for developers to begin working their magic.
We are yet to commence build, but we have succeeded in meeting our goal by our deadline. This was the first of many steps in unblocking the growth and revenue streams for our agency by reducing time to build by 50% and limit maintenance costs to a maximum threshold that doesn't grow with new agency transactions onboarded.
All of our process and rationale is thoroughly documented, and handover documents are prepared for developers to begin working their magic.
