My Role
Working with the product team, I led the creation of the designs as well as the information architecture of the HTML implementation of Card App.
The primary objective of the project was to recreate the functionality of Card App with as little change as required to account for the difference in context.
Since this was a product specifically requested for embedding within external products, there were unconventional constraints on the design patterns that were available to us.
My role involved defining a flatter navigation structure, understanding the specific contexts of use and defining the designs for most of the key pages of the product.
This was a high priority project that had to meet client deadlines, so the first version had some rough edges around navigation that we planned to smooth out over later sprints.
Context of Use
The objective of the Card App HTML implementation is to allow modular insertion of the project into external banking websites and apps.
A mockup of Card App inside the Wells Fargo mobile banking site is shown below for reference. As seen below, the entire 'Card App' frame is embedded into an external site.
(Note that this is not a real Wells Fargo product and this example is used just to indicate branding and fit.)
Due to technical and security considerations, the frame cannot fully interact with the external webpage, meaning common navigation cues like pressing the 'Back' button went to the previous page of the parent site.
Our early testing showed that implementing top level navigation cues such as a hamburger menu confused users trying to use navigation outside the module.
Responsive Design
We chose to use responsive design with 2 main layouts - mobile was one, and desktop/tablet was the other.
We chose to use a single breakpoint due to time constraints on the first release of the project.
Below is some of the data we collected on screen resolution usage across the world to inform our threshold values for each layout.
We used a width of 480px as our mobile breakpoint to account for newer iPhone sizes.
Within each breakpoint, we used fluid sizing of most components to ensure a consistent and pleasant viewing experience for most screen sizes.
Testing covered standard sizes between 360x640 and 1920x1080 resolutions.
Information Architecture
Since Card App is an independent mobile app, the information architecture is allowed to be deeper and less constrained by external factors.
Due to Card App HTML being an embedded product, we had to create a wider, yet shallower map of the product. The objective became to reach any functionality in no more than 2 clicks.
The wireframes below represent the summarization of how we decided to initially bucket the different features of Card App.
As seen in the wireframe, the initial layout had all the top level tabs on the left similar to a dashboard.
Flattening the Hamburger
Since a lot of other banking sites and apps use a hamburger menu, adding another to the embedded Card App module would introduce redundancy and confusion.
This meant we would have to remove the Hamburger menu which was the core navigation pattern in the app.
With the objective of keeping the mobile interface as close to the original as possible, we created a few designs to try and find the best desktop representation.
This was our first attempt, but the top level tabs were confusing on websites that had multiple levels of horizontal tabs.
The vertical menu on the left didn't work well on narrower displays, and didn't resolve the issue of not being able to use hamburger menus on phone representations.
The final version had a horizontal separator bar at the top, then a minimal menu bar with just an overview and the different cards you had.
Putting this final design in front of users resulted in the least confusion when interacting with the embedded module.
Navigation Modals
Despite the usual drawbacks of modals used for information-dense flows, we elected to use modals for some of our inner features for a couple of reasons.
A modal can be closed to instantly return to the previous context, no matter how deep in the flow the user is. This is one of the ways to avoid giving the user a need to press the browser 'Back' button, which cannot interact with our embedded page.
A modal also gives the user a contained sense of focus. Since some of our journeys went down a few levels, we wanted to make sure our user's attention is kept on the journey. Closing the modal would give a definitive sense of exiting the journey.
Modals presented the least amount of confusion when presented to users, compared to full page journeys with breadcrumb trails.
The screens below demonstrate an example where we combined a couple of mobile views into a single desktop view.
We chose to have the transaction list and details in the same view on desktop to allow a simpler transaction browsing experience.
If viewed on mobile, the same screen would display a transaction list, which would show you the transaction details screen on selecting a transaction.
Branding System
We created a branding guide to define and maintain the customizable properties of the design. An example of the defined branding properties are below.
Note that the default brand color was updated to blue from orange to adhere to WCAG AA 2.1 accessibility standards.
Design Choices & Key Pages
A comparison of Card App is provided against the mobile webview version to easily understand the key differences.
-
Notifications and Messages were moved from the hamburger menu to the colored title bar. This bar was to help differentiate between the module and the external website or app.
-
A horizontal menu was introduced to toggle between 'Overview' and individual cards. At a high level, this allows the user to easily switch through the different 'Card Details' pages without losing context on top level navigation.
-
The horizontal menu was created due to the assumption that most Card App users have 1-2 card products and wouldn't have to scroll much. The average number of cards per user today is 1.1.
-
The total spend is the only number present in the mobile view - tapping 'View More' now presents the categorical view. This was to prevent cluttering of the overview section.
-
A dynamic 'action required' section was created just below the graph. This section is one that is being built out to promote new feature adoption.
Landing Page
A comparison of Card App is provided against the mobile webview version to easily understand the key differences.
-
All the top level changes present in the Landing Page are present in the Card Details page. The dynamic prompt will remain at the same relative location.
-
Card management and viewing card details have been moved to the card's box for better discoverability and access.
-
The card's name has been added to the page for easier recognition.
-
Most functions from the previous menu have been given buttons below the card.
-
Transactions and My Merchants have been given their own cards for an easy overview. This was done to reduce journey depth as well as reduce the number of items in the card menu.
Card Details Page
Takeaways & Conclusion
At each stage of designing the wireframes and product, we tested the main flows of the product. Due to budget constraints, we tested with 10 in-house employees who weren't regular users of Card App.
The above designs were finalized after a walkthrough with a couple of clients by the product team.
My key takeaways from this project would be:
-
Never underestimate the importance of context of use. If your product is being used in an ecosystem of other products, users may not experience it as intended.
-
Always test. Showing test footage is one of the best ways to convince a teammate of a user issue.
Overall, the design was successful as users tended to navigate the module without relying on the browser 'Back' button. Top level functions were no more than 2 clicks away.
This project is still far from over, as Card App plans to expand into the web domain. As usage metrics pour in, there will be opportunities to adapt and refine the existing flows.