Nationwide

Flagship Mobile App

This case study is also available as a PDF. Enjoy!

Download the PDF

Understanding a development driven process.

Nationwide Insurance asked me to lead some of the most talented people I've ever worked with as we redesigned and launched the flagship mobile app. I was the advocate for the customer with 7 development teams, a short budget and very little time.

We launched a beautifully modern experience so customers could pay their bills, file a claim and share their insurance ID cards. And it was modular so the business could easily deliver new value.

My role

As the UX Lead and Interaction Designer, I managed relationships with our agile development partners, defined the agile iterations, planned evaluative testing and managed timelines for myself and my team.

My team

At Nationwide the user experience design team is primarily consultory. We were 100% billable and, like an agency, if we lose a client because we don't deliver, we need to find a new client to pay our salaries.For this project, design discretion lies with the business. The process is driven heavily by the development teams and the goal is to get something out of the door.

Why we did it

Nationwide is a very business centric company. The business funds projects and the success is measured in dollars and cents. The customer was rarely talked about. This was our chance to change that, to show leadership that a focus on customers can return an investment.

Once the leadership bought into the vision we had to deliver, not just something but something that proved this was the right approach.

How we did it

There were 6 separate agile development teams, hundreds of stakeholders from Product Managers to the CEO watching our progress. We had to work quickly and intentionally, minimize missteps and provide transparency at every step to avoid extra catch up meetings.

I discovered early in the process how crucial good communication with our stakeholders would be. We didn't just have to communicate our designs and decisions but we had to provide tools for those teams to work semi-autonomously. Every hour I spent in standup and doing QA meant an hour I couldn't build wireframes.

Building relationships

Each Product Manager became my best friend. I spent most of my time sitting with development teams and building iteration schedules for my design team.

We used Trello to track our time commitments, deliverables and prioritize work for the teams. Without centralized technical leadership I became the liaison between all of those teams. If there was a question, it generally went through me and, like a telephone operator, I'd redirect the question to where it needed to go.

Getting a lead on the development

We had little time, little budget and our leadership had little patience for delays. With our development teams we created a manageable scope but that meant design had to be at least somewhat defined before starting. It wasn't so we had to work quickly to get ahead.

I split our time between discovery sprints and delivery work. We had to prioritize the work that needed to be done soon but if we didn't work ahead, we'd burn ourselves out trying to keep up.

Creating an app structure

We divided the app into 3 main sections. A data view was a chunk of information, a scroll collection was a collection of data views and an action view was where a customer could do something.

By creating a modular system components could be swapped out, displayed or hidden based on development logic. Designing the pages became easier since we delivered components and the developers put the pieces together.

Focusing on the basics

We tore down the old app and started over so we had two options, either focus on delivering all of the previous functionality or deliver the most important parts first and quickly scale up.

We chose to prioritize the most important functions. Customers could file a claim, pay a bill, see their policy and view their ID cards. For most customers this was enough to justify downloading the app and for us, it was a manageable expectation for a first release.

Development driven design

Up to this point in my career I didn't have the luxury of sitting with a developer. That changed quickly and drastically. I built our app design practice and I made it a functional part of the development process.

Everything we did had a purpose. Everything we delivered was used and we skipped documentation or presentations because we simply did not have time to spend on those. This meant my days were spent with the development teams solving problems. Our process was as lean as it gets.

Scaling new features

With a design system in place, we could add new features with little effort. The UX team could focus on the high value problems, rather than the things we've already created.

Occasionally I would deliver sketches to the teams rather than wireframes. This finally allowed us to spend time doing discovery for new features rather than focusing solely on delivery.

Testing what we can

With all of the work going out at a break neck pace, we had little time to validate our ideas. Our research team was also billable which presented me with the issue of convincing our partners that we should de-prioritize work to test with customers.

That didn't go over well. What we ended up doing instead was usability testing in the lunch rooms. The sample sizes and the diversity of experience could have been better but we were able to resolve some usability issues and we did it without spending any money.

Building a system

We didn't always have development teams. That was part of a re-organization part way through the project.

We hit a point where one or two designers couldn't possibly keep up with the work that was being prioritized by the teams every week. I realized it was far more efficient to build a design system once and shift our deliveries from wireframes and mockups to components and conversations.

Reflecting

This was my first time leading a team, it was my first time on an agile team and it was my first time as a "billable resource". I didn't dip my toes in, I jumped head first in the deep end. It was a challenge but it prepared me for some really great insights down the line. I had exposure to more business focused meetings and I had to defend our work not just on the basis of the customer but with dollars and cents and business strategy.

Thanks for reading

This is the end of the case study but I'm currently looking for new opportunities.

Say hi before you go →
← Go back
Say hey →