This page is under construction…
Design systems
to the rescue!
Internal Tool - Desktop
Visa Credit Card application
-
ALPS 1.0 was the existing credit card application, designed by developers.
ALPS 2.0 was the name of the application once redesigned. This project was something I worked on for 4+ years but the information here is regarding the VISA Credit Card application, the first application in ALPS 2.0. -
4 Product Managers
3 UX Designers
1 User Researcher
Many front, backend devs & QA’s -
The credit union wants all of it’s members to use their products only.
The credit union feared their members would obtain for a credit card at a different financial institution because other institutions had a faster process. -
To keep members from going elsewhere for credit cards, the credit union decided to create a credit card application that would allow members to get approved for credit cards quickly.
-
This project timeline was 12 months. I was hired 6 months into the project. When I was hired there were no designs solidified for the application at all.
I suggested we implement this process:Design smaller pieces of the application
Be ready with a quick design, rough draft concept to manipulate with the PM daily (because we were so far behind)
Once the designer & PM was comfortable with the drafted concept, create a prototype and set up usability testing with 3 users (users were plentiful as they were internal employees)
Weekly - All Designers deliver a prototype of their PM collaborated & user tested design to entire product team for critique.
Create a design system along the way and require all designers to stick to it (this would require a lot of designer communication & shared documentation)
Adding another step into developers “definition of done” where they needed to review their developed work with the designer before it was completed. This allowed for design consistency in the finished product.
-
Designers feeling rushed because they were inexperienced with fast paced work environments
Designers being unfamiliar with mock ups and rough drafts - feeling uncomfortable sharing something that is not perfected
Designers feeling defensive during weekly design critiques
Designers feeling creatively stunted by having to stick to a design system
Designers not sticking to the documented system
Product managers sharing early stages of in-progress prototypes too often with developers & stake holders leading to premature product development
Developers failing to review their finished product with designers
Research data being tossed because “the user didn’t understand what they were suppose to do”
-
Because the team was willing to give to my proposed design process a try, it worked and we were able to complete a successful application in 6 months. Everyone received their bonuses and I was even given an extra bonus for helping the team reach their goals!
-
Creating a design system for all internal applications
Designers being consistent with design elements leading to intuitive user behavior
Building multiple loan applications quickly under the design system umbrella (Visa credit card first and then auto loan, business loan, etc.)
Working with developers to reuse design components speeding up production and quality assurance.
Many usability tests on smaller prototypes allowed users intuitive product in the end (hearing from the user rather than assuming, or running into larger user problems later).
-
Design consistency helped users process content faster and across multiple products because they were already familiar with it’s location, function and style
Design consistency helped developers reuse design components and maintain consistent spacing (no more winging it)
Design consistency gave answers to designers when they were given a new feature to design (no thinking up new design elements for every scenario/task)
Internal Tool - Desktop
Symitar Scripts
-
The credit union uses Symitar Episys to extract data through scripts.
Member facing Symitar users run scripts to access or manipulate account information for members of the credit union. -
1 Product Manager
1 Designer & Researcher (me)
6 Software developers (depending on the script) -
Member facing Symitar users are not typically software engineers and need a way to understand how to use certain ripgrep (RG) scripts without special training.
All the scripts that were designed for member facing users were each designed by a different developer following no systems of design elements and no design best practices. -
Recreating each script with a defined design system familiar to the users (in this case I used design elements that exist in other internal tools). Update the scripts and test them with users before launching them.
Another change was to eliminate abbreviations and add information that gave users clear direction about what they are doing and what will change on the users behalf (if anything). -
I would meet with the Product manager who would explain to me how the script should function.
I would then mockup a wireframe using the design system elements that are used in other internal tools (for user familiarity) and from there, the PM & I would run a few usability tests to validate our design decisions.
Handoff included discussing the interactions & user research data with developers. Often time developers would know even more opportunities to condense user interaction creating the most efficient solutions possible. -
Product managers would often not respond to my email with a mock up and later I would find that they just handed off the beginning stages of the design to developers and called it good.
There were so many scripts to redesign, it was hard to get to them all in a reasonable timeframe
Script redesign was not a priority for the credit union even though a better user experience was cutting down mistakes to members account information and creating a quicker visit to a branch or phone call to the service center.
-
The success of consistent and intuitive scripts seemed to be found here:
Users (customer service representatives) were less overwhelmed and stressed about relearning a new script every because they were already familiar with the design elements and functions.
Users made less mistakes to members accounts, and were able to clarify with the member what changes were made to their account.
Members felt more confident with their interactions over the phone and in a branch because it took less time to complete a task and was coupled with a clearer understanding and confidence from the customer service representative of what was completed to their account.
Member Facing - Mobile
Cryptocurrency
-
The credit union’s new CFO felt a need for a popular cryptocurrency feature within the already existing mobile application.
-
3 Product Managers
1 Designer & Researcher (me) -
Financial institutions were seeing a rise in cryptocurrency trading and buying. The credit union wanted to include a feature to it’s existing mobile app that would allow members to engage in less risky purchase, trade, and sale of cryptocurrency.
The problems we encountered were:How do we educate users on investing in cryptocurrency
Members often banked with the credit union because of they trusted the credit union, but investing can be a gamble
How could we design this feature to avoid getting lost in the app like many other widgets
-
To maintain trust and avoid major risks, members could buy and sell, or trade the least volatile currencies at first, potentially introducing more options later.
To avoid this feature getting lost in the widget void of online banking, I proposed we stick to the design system that was being utilized and mimic the design to match that of the personal banking feature with the option to toggle between the two features but maintain a similar experience as personal banking because the user is accomplishing a similar task.
-
the beginning stages of this process included meetings with 3 product managers and 1 designer (myself).
We discussed user flows, information architecture within the already existing application, and surveys to members of the credit union looking for their interests, and knowledge on the subject.
Survey included:How many people already use another cryptocurrency app?
Who would be willing to participate if the credit union offered something like that?
How much money do they currently have invested in cryptocurrency and how much would they feel comfortable investing?
What are their fears and why would they be interested or not interested in tis feature offered by a credit union?
-
Finding a way to include the feature into the app without adding it in as another widget
Getting survey participants in a way that comply’s with legal since we wanted to hear from all credit union members but we also wanted to target those who would invest their money
The concept was new and risky, would this create a level of distrust from our membership or would it create what users want to see in their financial institutions by offering features that are new and popular?
This effort/push was made on behalf of the credit union’s brand new CFO who was not familiar working with such a small company and we did not know if the new hire would continue to stay with the company or not so we were unsure if this product would see the light of day
Education on cryptocurrency was a lot of content for a mobile app. This was a read challenge for me to understand how to include it as it seemed like a whole feature within a feature
-
Maintaining similar experience as personal banking
No widget
Simple addition of feature or removal of feature in the existing mobile banking experience
Successful architecture because we maintained the already familiar and existing system
