At the end of the year, administrators and employers review data for their retirement plan participants.
My team included business leads, an impact manager, a tech lead, an architect, developers, SMEs, a requirements analyst, and a visual designer.
Interaction Designer
Nov 2017 - Feb 2019
To understand this landscape, I researched the domain and discussed individual user needs with stakeholders during cross-functional requirements gathering meetings. Many included users of this process and support reps that work with plan sponsors.
After the plan sponsor and Nationwide administrators review and submit, the data is sent for required compliance and non-discrimination testing. Mistakes can result in penalties or a plan becoming disqualified, which would be unfortunate for the employees!
This data is used to identify plan participants and determine enrollment statuses, vested balances for participant accounts, and more.
This data is used to identify plan participants and determine enrollment statuses, vested balances for participant accounts, and more.
Our team aimed to completely revamp the existing experience, improve areas of confusion, add more useful information, and update styling.
I first focused on understanding the issues with the current workflow.
In order to reduce errors in the long term and allow for greater flexibility in how employers choose to review and submit their data, the business decided to add pay date level data to this process.
With up to 52 pay dates in a year (e.g. weekly pay), the amount of data we needed to incorporate in the design was multiplied by up to 52 times.
Several additional meetings were conducted to sort through these requirements.
To make sense of all this complexity, I created a diagram of all the different paths and scenarios. This was very helpful in getting everyone on the same page and allowing them to see where all the pieces of the puzzle fell. Feature numbers and related requirements such as notifications and reports allowed stakeholders to easily reference their requirements documents.
I then started the tedious process of mapping out the actual interaction flow. Challenging nuances arose such as determining what to do in the middle of the process, when the user needs to wait overnight for the report to generate before proceeding to the next step.
I conducted user tests with 6 users in various roles to determine what worked or didn't work with the initial design. Through these tests and subsequent team discussions, various usability issues and conflicts were revealed.
We updated the flow with more explanations for warnings and error messages and less alarming red. We also reduced unnecessary buttons and took the user back to the landing while the report was generating during the overnight flow.
While the report for a department is generating during the overnight flow, we also removed the ability for a user to enter the process for that department. This simplified the interaction and reduced the need to create additional messages and errors.
Though ultimately dependent on technical capabilities, we proposed that ideally the reports are generated on the fly (not in an overnight flow), so that the user would not have to start the process, stop and wait overnight, and then return to complete it.
We created updated designs according to the current site standards for the plan sponsor (employer) website.
The same process also needed to be available for internal Nationwide associates and administrators to provide support, so we created high-fidelity designs according to the administration site's standards as well.
Landing page
Final salary confirmation
Review and edit census data
Edit census data on-screen
Edit employee
Edit census data in Excel
Currently, this project in development with many different developers working on it. I support them by providing explanations for the designs I have created and facilitating discussions on additional scenarios and nuances that are discovered along the way.
I think this design process could have been smoother if I spent more time planning and gaining a better understanding of nuances early on. For example, after creating the flow diagram, I could have spent more time reviewing it first with business as well as the design team to discover alternate cases and scenarios. This would have reduced time spent focusing in particular directions and backtracking.
Ideally, we also would have had an opportunity to conduct more rigorous research to better understand user needs. This would be able to give more conclusive information to base design decisions in addition to the opinions of different stakeholders.
