In the Summer of 2021, I had the amazing opportunity of being a UI/UX Designer at the Royal Bank of Canada. The RBC Employee Webforms redesign was a project that I worked on towards the latter half of my term. It is a tool where employees across the bank come to apply for company credit cards to cover work-related expenses.
This was an interesting project to work on because the last time that this platform was updated was before I was even born! Working closely with Product Managers and under the guidance of a Senior UX Designer, our overarching objective was to align the platform with modernized and streamlined company UX standards.
For the first 2 weeks of the project, I was the sole designer responsible for deriving initial audits, flows, and wireframes.
I was responsible for auditing and producing flows and wireframes, as well as designing the final version of the landing dashboard, form selection page, and renewed form experience (desktop & mobile).
Since 1999, the bank’s internal credit card application portal has remained the same whilst several other internal services have received UX overhauls. This has caused friction regarding credit card applications between employees and their managers due to accessibility concerns, usability difficulties, and long backlogs.
I felt that it was the perfect opportunity to cross-pollinate with other divisions of the bank and gain exposure to new design challenges.
We are looking to update RBC’s internal employee credit card portal to better align with the bank’s other internal platforms and services. We are seeking a designer to formulate and visualize usability improvements. 💳💼✨
Whilst the team was still acquiring a lead UX designer on contract (Mishelle Menzies), I was responsible for piloting the UX redesign process via UX consultation and visualizing the changes that the team drafted. Upon Mishelle’s arrival, I would then hand off the progress and continue working under her leadership to complete the redesign effort.
After my initial onboarding meeting with the team, I took time to review the notes I had gathered from a heuristic standpoint. This prompted me to conduct a UX audit of the platform in its current state to identify issues, assign them priorities, and conceptualize solutions accordingly. Designing wireframes and prototypes was an iterative process that evolved with each meeting as we had to consider the logistical and formatting restrictions of card provider policies.
This UX redesign effort sought to benefit RBC employees, specifically those who are applying for company credit cards for work-related expenses, or are looking to make changes to their existing card credentials (i.e. address).
Since the team developing the platform were also its users, we were able to distill user objectives throughout our initial meetings to be that of the following:
The main reason for users to come to this portal is to be able to quickly and easily find the credit card application form that they need and be able to fill it out with no issues.
Like tracking a package, we know users want to stay updated on the status of their applications. This is to avoid unnecessary communication between employees and their managers.
To avoid request backlogs due to a manager’s planned absence from work, they require the ability to delegate request approval authority to another member of the bank.
After going over key findings on employee behaviours during our team meetings, I fabricated a user persona for our target user, an RBC manager, who would be using the platform to both request cards, and approve requests.
As an intern, my unfamiliarity with the existing cards webforms platform was actually advantageous for conducting a heuristic platform audit.
The platform was operating on a severely outdated back-end architecture, which was largely separate from other internal company services. This has made it difficult for developers to keep the webforms portal up to date.
Like several other internal services, the login process took me to an SSO page. Almost immediately a separate window had popped up and had failed to load. In trying to find workarounds, I eventually discovered that the webforms platform was only compatible with Internet Explorer, which I felt was a huge impediment since most employees had become accustomed to using more common browsers like Chrome and Firefox.
After navigating to the Forms tab, which happened to be the only relevant tab, users were quickly presented with all the possible form categories and card-types in the form of a sub-tab bar. When users navigate through this sub-tab bar, they are further presented with another layer of all possible forms that they can fill out. I felt that this was a moment of high cognitive load, and was not time-efficient for a user who had to scan every available option before finding the form they needed.
The “Status” tab contained a data table, which albeit outdated, was rather effective and straightforward in presenting the user with information regarding approval statuses of their submitted forms. The “Search/Report” tab on the other hand was confusing and awkward as it presented users with the same data table, but with an additional option to sort, filter, and edit its subheadings.
My assumption for the existence of “Search/Report,” which I later confirmed with the team in a subsequent meeting, was to allow users who’ve submitted a large number of forms to be able to organize them.
After familiarizing myself with the platform and grasping a better understanding of the information architecture, I began looking at specific pages and interface components that I felt were potential pain points. I then organized my findings based on their severity of usability impediment (see table below the following set of images).
A user should not have to navigate through several levels of tabs to find a single form to fill out. There are also several moments of redundancy and outdatedness.
Users are not told whether they complete certain actions, such as submitting a form. Especially given how outdated the platform is, users may feel unassured.
Compared to other internal tools, there is a clear need to make some visual updates. Lack of structure and spacing leads to very small text on larger screens.
Now understanding where core issues persist, I began drafting some ideas with a predominant focus on simplifying navigational hierarchy and improving the form filling experience.
It was clear that the form filling process needed some treatment. This meant developing form components with a level of consistency and readability. Usability-wise, this meant providing users with the ability to confirm their inputs, as well as message prompts to let them know that their form was successfully submitted.
By removing redundant tabs, I was able to flatten the user flow from 3 navigational levels down to 2; meaning users could access their desired form more efficiently. However, albeit functional, I felt that there still persisted a moment of high cognitive load when specifically selecting the type of form. Additionally, by hiding an entire set of forms behind a second tab, there was the concern that some users may accidentally request a card from the wrong company or not even find the right form to begin with. This became the main focus for our second iteration wireframes.
To find the most intuitive solution, we asked ourselves “what would someone ask when they are applying for a credit card?” This prompted us to approach the form selection process from a different perspective; one that was not initiated by company/type, but rather by a user's desired action.
This guiding principle was what defined our next set of wireframes, which were built around a dashboard approach that gave users quick and easy access to all functions related to finding, filling out, and checking the status of forms. This meant that all core actions are visible within a user's initial landing viewport; whereby additional information is available with scroll.
When comparing this new approach (of leveraging a user’s knowledge of intent) to the existing one, users will no longer have to scan through all available forms before finding the right one.
The option to adopt a multi-step form was brought up during one of our meetings to address the potential issue of users finding the forms to be excessive in length; which would then lead to lower conversion rates. Backed by some preliminary research showing that multi-step forms led to higher conversion rates, our team collectively agreed that breaking down each form’s different sections into bite-sized portions and progressing through it with a “next” button seemed logically sound and user-friendly.
However, something about how straight-forward this approach was seemed “off” to me.
After taking a second look at several of our research sources, I realized that they were all within the context of consumer-sided interactions; particularly product checkout processes. This prompted me to revisit a crucial and concrete fact: which was that our objective didn't revolve around selling employees these credit cards. The larger focus from the beginning was to provide a streamlined experience to efficiently apply for company credit cards to cover work-related expenses.
From this re-evaluation, I hypothesized that the idea of a “conversion rate” was irrelevant from our design context. In fact, the multi-step form approach may even lead to additional usability hindrances. For example, if an employee realizes they made an error at the form confirmation page, they would have to go back, make the change, and then linearly progress through each step before returning to the confirmation screen. On the other hand, a single page form enables the user to simply scroll up and down to scan and make changes to their inputs; without having to click multiple times. Moreover, understanding that our company was a bank meant that our employees (in most cases) already have some form of background knowledge regarding credit card applications.
Of course the best practice and next step would have been to confirm this hypothesis via a round of user testing, but unfortunately, my scheduled term at the bank expired prior to the project’s deadline.
When it came to the question of visual design updates, our primary focus was giving the platform a major facelift by preserving a notable level of consistency with the company’s open-source design system.
However, given that the webforms portal wasn’t consumer-facing, Mishelle and I found some wiggle room to explore customizing some select components that we felt could improve the overall user experience without straying too far from company design standards. This meant some of our design decisions had to be quite intricate.
One key feature that was missing from the component design of the existing platform was that of visual feedback. To make field input components more dynamic and responsive to a user’s actions, there needed to be different states. We also bumped up the padding of these components to increase clickability on larger screens.
Removing the outdated tabs and using our new conversational approach to form selection allowed us to dramatically simplify navigation logic. We used cards to organize information and establish consistency with spacing. Moreover, drop shadows were used to bring emphasis to important actions, as well as to denote a subtle sense of neumorphism (i.e. credit card).
Our focus on redesigning the table component was to establish responsiveness, clear organization, and legibility. Henceforth, we followed the box model and Material Design guidelines when it came to considering responsive cell padding and height. Additionally, we used a zebra background fill to bring contrast to each row.
Putting all of our previous work together, Mishelle and I collaboratively designed a few key pages and flows; notably the dashboard, form selection, and form pages. A couple of quality-of-life features were also prototyped, such as the form confirmation screen, as well as message alert modals and success notifications.
In the last week of my term, I had the opportunity to experiment in designing a mobile version of the webforms platform. In this case, the limited screen size in addition to guidelines established by the bank’s internal design system rendered a multi-step form approach more favourable.
Overall, it was an amazing experience getting to work with new colleagues on this project. It was really interesting to reflect on the vast amount of variables and design considerations that need to be made even in common user experiences like filling out a form.
Being able to present my progress regularly during our meetings allowed the entire team to be in the same loop; and concerns could be raised earlier.
By actively listening to each other’s ideas, Mishelle and I were able to work together seamlessly and efficiently to ensure we were on schedule.
Choosing between a single vs. multi-page form taught me that design-thinking is contexually-based on target users and their desired objectives.
Speaking up and asking questions to familiarize myself with company card policies played a pivotal role in avoiding design incompatibilities later on.
Although this was an internal project on a short timeline, user testing would have been extremely beneficial in supporting our design hypotheses.
Designing the mobile version was an inherently different experience and required more thought than simply relocating and resizing components.