Improving product applications

Express Account Open (EAO) is a streamlined account open experience that clients can complete in under five minutes. The application targets existing clients looking to apply for a single banking product. The form will pre-fill most of the data entry fields, and skip authentication steps usually required with new clients.

The challenge was to iterate existing complex product applications to allow for faster completion and fewer errors.

Reducing cognitive overload

Based on the complexity of information we needed to collect, our approach was to use a multi step form that included a step counter. This helped ease cognitive overload by breaking up the necessary information we needed to collect.

The flow consists of five main parts: before you begin, client details, product and account setup, terms and conditions, and next steps. We had to account for some conditional screens, that could display based on client scenarios or information entered. Some conditional screens included client sign-in, tax residency status and down-sell offers.

Clients were being rejected in other application flows, and not understanding why. This increased call volume. We discovered the main reason was that clients were skimming over eligibility criteria on the Before You Begin screen. To avoid this, we added mandatory checkboxes to confirm before proceeding. Through testing, clients understood the criteria was important and successfully confirmed the information. This change increased the number of successful applications we processed.

Better data entry patterns

One of the main issues clients raised with older applications was not knowing which fields on the About You screen were mandatory. Existing components lacked clear indicators, and contained placeholder text that made the empty fields look prefilled. Clients assumed fields were accurate and complete, but when they clicked “next”, error messages displayed.

For EAO, since we were targeting existing clients, almost all data was prefilled and thus didn’t necessarily require input boxes unless being edited. This sparked a concept to have two states of field groupings: a collapsed state, and an expanded state.

The expanded state would display when there was missing client data, to help clients identify the fields and complete, while the collapsed state would display the previously entered information. By pre-filling fields, collapsed field groups by default would not trigger error messages since the data was verified from our back end systems upon completion. This meant clients could proceed quickly to the next step if all fields were collapsed.

Other Enhancements

Real time, front end validation

One of my favourite and most challenging pieces of creating EAO was including real time front end validation logic. No existing form had included real time validation, but our team was able to come together and create the solution. We pushed for this enhancement in stakeholder demos, since it helped clients self correct errors before submitting and provided us with more accurate information.

We mapped out possible input errors and messaging to properly build the logic and take note of technical constraints. Our conclusion was to group the logic into two buckets for submission: 1) was it complete, and 2) was it in an acceptable format.

The input logic also ensured client information would be saved at both the component and page level. Through testing, we noticed some clients completed expanded field states without hitting “save” before clicking next. So we updated our front end validation to detect if information being entered was new (first time entry = save) or modified (second time entry = edit and save). Clients would only ever see the simple UI; however, on the backend, we had built a sophisticated web of interaction patterns.

Inactive Buttons

To visually help indicate what was happening with front end validation, we designed an in inactive button. The purpose was to provide a visual queue when there was an error or incomplete data on the screen. We worked with developers and our accessibility lead to ensure we were creating an inactive colour state, instead of a disable button.

Sign In Screen

If clients were coming from targeted ads, digital marketing offers or our pre-sign on site, they would need to sign in before continuing with the application. We made adjustments to the sign in form for better consistency with other experiences and to include real-time validation behaviour. We also added an enhancement to “show password” for easier input; previously only used on our mobile app.

Branch Locator

The current branch locator hierarchy seemed disorganized so we updated the layout to be consistent with common map UIs (Google, Wayz and Uber). For the search results, we moved them from the right side to the left, so they were positioned underneath the search bar.

For the map, we moved it from the left to the right and changed the location icons from what looked like dialog boxes to pins. We also included logic that allowed for default and selected states of the icon, so clients could more clearly see where locations were on the map.

Annotating screens for delivery

As part of the design process at CIBC, we create UIDs (User Interface Documents) to describe interaction patterns and help team members understand expected system behaviours. I improved existing layout templates to be clearer and leveraged the collaborative features of InVision, to share UIDs across the team.

This new layout worked well in demos and was easy for team members to consume. A bit of extra work, but we were then able to share common component labeling across our documents (user stories, copy deck, code kit) which made QA a lot easier.

Creating a design system

Looking at our team’s product roadmap, EAO would be the first desktop responsive project to launch with new site branding. At the same time, our development team was transitioning from using Ember to Vue. A lot of new learning, we built a Design System Kit for our developers and future product teams alike to reference.

I worked closely with our developers to build an atomic library class and style library. This meant devs would code each “element” of the library (atoms, molecules, components) once and then through my speck sheets, I would call out the components (yellow boxes) instead of specking everything again on the screen. This reduced the chance components would be built twice, or have varying styles if built by different developers.


In order to deliver the experience, we used agile development methods to delivering the flow in parts at a time. The concept was that the UX wireframes would serve as functional mocks for our devs to componentize page layouts and our QA to test functionality. At the same time of code development, the visual design specks would be built by screen/section, so once the functional testing was complete, visual specks could be applied. This process made reviews and iterations much easier, we caught bugs early on, and speed up QA testing since we were testing in parts ahead of the end to end flow. Once everything was pieced together, the QA team only needed to run end to end test cases since all other defects were closed.

After launch, we saw an increase in successful application completions and total conversion rate of 63%. This was a huge increase compared to our typical application conversion rate of 27%.