Project Background
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.
Role & Team
Their risk-assessment flagship product was aging, and I was brought in to oversee the redesign of the site's UI and UX. I worked with multiple teams consisting of a Project Manager, 3-7 Developers, and a Business Analyst. Each team was responsible for a different portion of the overall experience, and keeping them coordinated was of the utmust importance. As the project progressed, it became necessary to work with other designers as well, to scale the design work and expedite the process of larger changes.
Design Process
- Reduce cognitive load for high-volume employee users
- Increase readability of data
- Improve relevance of dashboard data
In order to determine what was most important to focus our efforts on, I arranged a series of meetings with individual stakeholders as well as larger groups of stakeholders. In the individual meetings I could interview the thought leaders of their organization, getting not only a qualitative insight into their subjective opinions and experiences using the tool but a list of ideas about the product’s future from the people most experienced with it. When I brought them together, I started with this list of ideas (and some more suggestions the meeting attendees had together like a focus group) and used techniques like affinity diagrams and dot voting to help the leadership better define their needs, as well as ranking them in importance.
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 the results of meetings with stakeholders, formed the backbone of the entire project.
One thing that became immediately apparent is that the new project would require a Design System in order to maintain consistency and scalability.
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.
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.
Ensuring Accessibility compliance in a product or experience is mandatory if you're creating inclusive digital experiences that are accessible to any and all users, regardless of ability level. By embedding accessibility principles at the Design System level, we could ensure that our service was not closed to users with visual, cognitive, or motor impairments. At every stage, we audited our Design System against WCAG 2.0 guidelines to maintain that standard.
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.
The most difficult (and, arguably, most important) part of this endeavor was bringing the Design System to the various development teams and gaining their buy-in. I had to not only extoll the virtues of the system, emphasize the benefits of using a Design System in general, and onboard them to its proper use, but also field questions live in front of a group that could also include C-suite guests on occasion.
By engaging with the teams and embracing feedback, I was able to not only make changes to the Design System based on technical restrictions or requirements, but help give those developers a sense of owenership over the final product. After all, without them willingly using the Design System to its fullest, what's the point in even having one?
Outcome
The Design System was widely adopted and used for nearly every project undertaken since, including some far beyond the scope of the original product.