Due to a Non-Disclosure Agreement some details on this project are limited.
Continually evolve a design system that is:
A national bank’s online banking platform is very out of date aesthetically and functionally. The bank has overhauled their site’s digital product with a new design system to start. As designers progress through ever more complex features, the design system needs to grow with their objectives.
Within the greater online banking experience, I worked with a core team of subject matter experts to maintain and expand the design system on a consistent basis.
The design system team provided a standard of excellence and source of truth for the entire online banking experience and consisted of:
Which ultimately delivered a completely revamped experience that will serve:
The design system team that I worked on had three primary functions:
Let's take a look at some ways each of these duties are executed:
Each week, the team reserved two 1 hour slots to go over newly created designs from the various teams to ensure a panoramic consistency throughout the product. The execution of keeping consistency happened in one of three ways:
1. Pointing to a design that was in direct violation of outlined standards within the documentation.
2. An ideation of a design that our ‘out of the box’ components would not accommodate.
3. Overlap of the same design idea but with a different visual treatment than what was already agreed upon amongst other teams.
The design system is constantly changing whether it’s deleting, adding, or tweaking the existing documentation. The spark for change can happen in a couple of different ways. The most common way is having designs organically populate in several teams flows. When that happens, the process looks something like the below:
When it came to forms, our documentation was relatively limited on their placement and stipulated that forms either went in a wizard (step counter) or a modal (dialog).
Nevertheless, we started to see forms that were in an altogether new environment: containers.
We didn’t have anything in our documentation to support this kind of usage but kept seeing it submitted by different experiences within the bank. I performed an audit across our entire experience to see where and how these container forms were being used and why they truly differed from our other forms.
While the audit was intending to assess commonalities between each team’s environmental use case for container forms, other revelations came out of the wood work. Namely, how teams were using different kinds of form elements such as radio buttons, check boxes and button toggles to lead users through settings.
After raising some questions about how teams were using form elements, I wanted to see if there was a definitive opinion based on UX principles, other design systems, and competing financial products.
This research led me to construct new documentation to re-align our standards for toggles and accordion forms as well as create new documentation for forms within containers. I then presented the research with proposed changes to our governance committee. This committee included the following individuals:
After presenting, each product team representative casts a vote to approve or deny changes. With my presentation, I successfully persuaded the committee to induct the following changes:
Changes to the toggle documentation then required changes to the coded component in our component library. We had previously made a combination toggle and save button container for developers and designers to use which was was now voided. I constructed a Jira ticket to remove this iteration from our component library.
I also wrote up new official drafts for the accordion form, slide toggle as well as container forms which were then published to our documentation site for future designer reference.
There are so many moving pieces and thus considerations that have to be taken into account when working on enterprise software. If changes need to be made, it’s not always about the ultimate design experience but what will be the lightest lift for the whole system without negative impact.
The power of design system management lies in the team’s ability to oversee the designs of an entire experience. The goal of a design system management team is uniformity and predictability within an enormous product and isn’t always about being cutting edge or sleek.
Nothing is set in stone when it concerns a design system. Documentation can and does change depending on the circumstances and as the system evolves.
