Nationwide App
Launched October 2018
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.
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.
Unlike some of the other projects I've worked on, my team was heavily divided into the localized UX team and the stakeholders.
I led the UX team and partnered with a Scrum Master to plan sprints, prioritize tasks and generate billing hours (again, because we operated as 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).
In a normal week, I'd have regular conversations with nearly all of my stakeholders. Needless to say, my calendar was packed.
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.
Design systems can be super useful for designers. In this case it was essential as a shared language or shorthand for building screen components.
Near the end of our final push, I didn't have time to make screens with placeholder data. In some cases my "designs" would be a conversation, a written list of components on the page or a flow with components represented as boxes and arrows.
This was far from the ideal but I could write a list or build a quick flow while walking between a soul-crushing amount of back-to back meetings. It worked incredibly well for our situation but I wouldn't recommend it.
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.
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.