Role: Lead UI/UX Designer
Tools Used: Adobe XD, Confluence, Storybook, Zeplin, Miro
G2 Risk Solutions, formerly G2 Web Services, is a fintech company that provides services centered around the assessment and mitigation of risk, particularly in regards to credit-providing banking institutions. Their flagship product is a SaaS risk engine which uses a combination of AI and human auditors to examine databases of merchant account applicants for suspicious or prohibited behavior.

Challenge
Their risk-assessment flagship product was aging, and I was brought in to oversee the redesign of the site’s UI. This quickly evolved into a complete ground-up redevelopment with a new tech stack and a completely scratch-made experience, greatly expanding the scope of the original contract.
Goals
- Reduce the cognitive load for high-volume users
- Increase readability of data
- Provide better insights on dashboards
Purpose
Though a Design System benefits nearly everyone who touches a product in some way, the primary benefactors are the designers and developers who will ingest the design system as part of their own processes, giving them the building blocks to make better products in less time. A good design system aids in consistency, scalability, and efficiency for the whole team as well as the products they work on.
How did we solve the problem?
Starting Point and Stakeholder Requirements
Though this would be the first software Design System the company employed, there were some starting points for me. Most significant was the Brand Guidelines set forth by the marketing department, which set me up for success by defining an approved color palette, typography, and even a set of pre-approved stock photography to help set the tone of customer-facing instances.
I also spent a great deal of time studying how both employees and customers used the existing tool, conducting focus groups, one-on-one interviews, and shadowing select users to observe where their greatest time sinks lay. This body of data, along with some direct requests by company stakeholders, formed the backbone of the entire project.
Anatomy of a Design System
Knowing what users needed translated first into rough ideas of what sub-experiences would need to be provided for within the whole.
Having defined that list, each sub-experience was broken down further into the minimum necessary Page Templates, which at first used intentionally vague hand sketches to represent different functions that were commonly re-used among pages. These included things like an information center or dashboard, user profile pages, and multi-step processes encompassing different permutations of the same screen.
Each of these pages were refined further into groups of Design Patterns, each of which handles a separate function of the overall experience, such as a menu, a set of common controls, or a method of displaying data. These are arguably the most important aspect of the system, as it provides most of the scalability and continuity to the user experience.
Finally, the Core Components could emerge from within the patterns, those most basic atoms of design like links, buttons, form input fields, tables and windows.

Design and Test
For every component, pattern, and template there was a lengthy process of design iteration, which included sketches, wireframes, high-fidelity mockups, and interactive prototypes to aid in testing and informing further design decisions. At every step in the process the results were demoed for Product, Marketing, Management, and Development teams to insure that opportunities for communication were plentiful.
In the final stages of design, whole interactive prototypes of the entire experience were produced by me and an assistant, allowing even more opportunities for “real-world” feedback by those who would use the final product most.
The Hand-Off
During the design process I began using a dedicated space within the company Confluence as an interactive repository for the emerging Design System, and as the designs were refined so was the contents of the wiki. It became the primary source for the Design System, allowing me to update everything as needed to keep everyone using the system on the same page.
Working with the Development team, we created companion instances for each element in Zeplin, allowing for enhanced communication of UI specifications between users, and connected the two via the app Storybook which also allowed for experimentation and further testing without interfering with the dev environment.
Conclusion
The Design System, as well as the product it was initially created for, launched to much acclaim. Customer Satisfaction scores went up by a minimum of 20% year-over-year, and the average time-on-task for employees dropped by nearly 30%, satisfying the two main KPIs that the client was focused on.
This project highlighted the need for constant and thorough communication, not only by keeping us on our toes with an ever-changing scope that required everyone to coordinate their work, but by providing numerous instances where a user who might not have normally had input on a design process shared an insight unique to their position that changed everything.