Nationwide App
Launched October 2018
Nationwide was split across a seemingly infinite number of business units. Products, like the app, were funded the same way a consulting project is funded. The UX team had an extensive intake process with high impact and high budget projects taking priority.
Nationwide's structure can be felt in its digital experiences. Different business units may have dramatically different flows and those systems don't talk to each other any more than the people who built them.
This was different. We built an app, from the ground up, for the customer's situation. All of your Policy Information would be in one place, all of your Bills would be in place and all of your Claims would be in another. No more digging, opening a legacy web view or even another app to access information.
I was an interaction designer at Nationwide but I also inherieted the Lead role. This meant doing the day-to-day IC work while managing output and handoffs for my Visual Designer, Copywriter and Front-End Developers.
I led the UX team and partnered with a Scrum Master to plan sprints, prioritize tasks and generate billing hours (we operated as internal consultants).
I was the only person on our UX team that was communicating with 7 separate development teams, the design leadership team and our business leaders (including the Chief Marketing Officer).
We started with an incredibly open ended blue sky app design. Similar to some of the other products I've worked on, this vision was more or less a final view of what the UX team thought the app should be.
My job was to build the foundational design system and work with the engineering teams to get us to that vision.
If it looks like it was built in the mid 2000's, that's because it was built in the mid 2000's. All of the information you might need was there but to do anything useful you'd have to dig two, three or four layers deep.
The app was designed to be extremely modern (at the time) with simple, straightforward information presentation but it was designed as a whole vision without a ton of thought around engineering requirements and optimizations.
My big goal here was to find and document reusable patterns and variations before we started building front-end components.
I was in lockstep with our engineering teams, so much so that our design system became a library of shorthand symbols. This became essential near the end of the project. We were too busy and time was at a premium.
Rather than creating distinct pages with placeholder data, I could have a conversation with the team and draw those symbols on a whiteboard. The engineers could start building the page and I could design it in parallel.
The thing I love about this app is that it's scalable. It doesn't matter how if a customer has dozens of policies, each one can stack.
If we ever needed another bucket, we could add a screen. That flexibility came with the responsibility to push back on business units that wanted their own page.
We barely launched the app before we had stakeholders from across the company asking to be involved in new updates. It was an exciting time and it inspired our business partners to think bigger.
This was a hugely visible project in a large company so some positive takeaways were important. We made huge strides in our app reviews, our primary metric and we had plenty of room to grow.
Development teams
Stakeholders
App Store rating increase 3.3 ★ to 4.5 ★