NerdWallet is a personal finance company with the mission to provide clarity for all of life’s financial decisions. I was asked to bring the experience of the mobile app to the next level.
NerdWallet had experimented with native apps in the past, but hadn’t intentionally invested in a mobile-first product strategy. Because of this, the experience wasn’t at the level it needed to be to compete with other finance apps. Improving the experience became a top priority for myself, another designer on my team, and our project manager.
Early on in the project, I took screen recordings of places in the app with the worst UX and performance issues. I edited these in after effects to give the engineering team a view of what it should look like when the issues were removed. This was helpful to get engineers moving on work quickly, while also buying the design team more time to do needed foundational work to improve the app’s overall UX and visual design.
A key part of my work on the native mobile app was building a design system for designers to use. I came up with the strategy for how the system should be organized, built a large number of components, aligned efforts and strategy with engineering, and trained designers in the use of the design system.
Designing for both iOS and Android platforms, we had to consider how we would create consistency appropriately. Early on we made the call to adhere fairly closely to platform-specific conventions for iOS and Android, rather than trying to create a one size fits all component library for both. We believed this would allow us to use familiar UI patterns which would make our experiences easier for users to navigate. Features would also be faster to develop because we could tap into system capabilities rather than building everything from scratch.
My approach to the design system was informed by the Atomic Design Methodology. I defined basic styles like typography, spacing units and color first, then built basic components like headers, footers, cells, and inputs using these. These base components were then used throughout the app in more complex layouts.
The design system proved to be very helpful as we built features. It made for faster more consistent work. For instance, one designer Jason, was able to layout a large multi-page home ownership experience in just two days. He estimates it would have taken him one to two weeks otherwise.
It also reinforced good practices and made it easier to make decisions. For instance any team who build an onboarding flow would tap into the onboarding pattern we defined which enforced progressive disclosure for questions.
To make the most impact as we rolled out changes, we identified key places in the app to update first. The app launch experience was one of these places. We wanted to convey feelings of trust, stability, and performance with each app launch.
I led the charge on this project. I shopped the idea around, assembled the dream team which included a motion designer, an engineer, and myself. I created animation concepts alonside the team, art directed, and oversaw the project during development.
The work we had done to improve the app was getting noticed internally, and the design system was speeding up design work, but there were still internal problems to iron out. Some designers were designing for desktop first and trying to make designs ‘fit’ on mobile. PMs were planning features that didn’t account for native mobile’s capabilities or constraints. People throughout the company used terms which confused the native mobile app, and mobile web site with each other.
I led a presentation on how to work mobile-first to address these issues. To make this presentation successful, I felt it was important to have representation from each org working on the app. so I assembled a panel of experts from Product, Design, UX copy, and engineering to give their viewpoints on how to work mobile-first. We shared our thoughts, our work and answered questions. Over time, I noticed people adjust how they planned and designed features on the native app.
I’m happy with the work I did here and much of this project went well, but there were a couple of things I’d change if I could do it again.
I’d make a stronger case for doing the foundational work up-front all at once. Due to resourcing constraints, we did this work over the course of many sprints, carving time out as we went. This approach meant the project took much longer than it could have otherwise.
I’d build more constraints to the system. We did a good job defining the foundational styles and components, but there was still quite a lot of room for designers to create one-off instances of similar layouts using these components. Building more mid-level components and exposing less of the foundational ones could help solve this.