UX Designer // 3 Week Project

At the project kickoff, eRetirements was a website that helped users determine their retirement location. It offered city information and personalized recommendations formed by user self assessments. The founder’s inspiration for the website came from his parents’ unhappiness with their retirement location. They had failed to consider enough factors of day-to-day life beyond the climate and outdoor amenities.

After working with a prior Designation UX design team, eRetirements built the self assessment feature to differentiate their MVP. Their goal was to expand the website into a comprehensive guide for retirement relocation. The client challenged my team of three to design a profile dashboard, partner comparison, and retirement roadmap. We needed to integrate these new features with each other and the rest of the website.

As our second client project, we were already familiar with identifying initial key assumptions. With eRetirements, we had to sift through past UX deliverables, current user behaviors, and proposed concept prototypes. We categorized insights validated by research versus assumptions with insufficient testing. Defining the scope of what we did and didn’t know would help us to determine what we needed to find out.

The potential pool of users starts with the large Baby Boomer population of approximately 76 million people. More than half are already aged 65 or older. An extra 10,000 people per day will continue to retire through at least 2030. Yet, only 55% of Baby Boomers have retirement savings and only 22% are confident that they are doing a good job of saving.

These types of statistics led our client to target users who had already made financial preparations for retirement. Of the Baby Boomers with retirement savings, 58% have $100,000 or more. When they are using financial advisors, 78% have $100,000 or more. Users were considering relocating or buying a second home as they explored recommended cities. Our client defined eRetirement’s current user base as a roughly equal split between two types:

• Users more than ten years from retirement browse content to get inspiration as they are still early on in the process.
• Users within a few years of retirement research details of specific cities as they are looking for confirmation.

He also defined another possible user existing:

• Users need detailed instructions to plan for retirement as they are currently lost after taking the self assessment.

He relayed to us that when he asked users what they would do with their assessment results, most replied, “nothing.” This assumed desire for direction led to his proposed idea of a retirement roadmap.

• Past insights:
• Users loved adjusting personal preferences and controlling the amount they disclosed
• After taking the assessment, 80% of current users engaged with the city content
• Design team assumption:
• The assessment should be a step within the roadmap instead of the main call to action

To wrap up our meeting, we prompted our client to give us an initial hypothesis for eRetirement’s current state:

Our users need a comprehensive and customized resource to know where to retire because it’s a very complicated and personal process.

We conducted ten remote interviews with users at different stages in the retirement process. They were anywhere from ten plus years away to working part-time to already retired. Half planned to retire within a few years or were approaching that window. All were in their 50s or 60s, with a generally even distribution across these two decades. I wrote the interview script for the team to use as a guide. We began with exploratory questions to understand users’ perspectives of their retirement needs. Then we progressed to more focused questions about the proposed features. We needed to find out if users even existed that were in need of detailed directions. If they did, does the roadmap concept address that need?

Money was the most consistent factor we heard across our interviews. It is difficult to predict how long someone will live and how much they will need to have saved for retirement. As a result of this complex component, almost everyone we spoke to used financial advisors. And those that didn’t, possessed career skills to do it themselves. They didn’t want financial advice from eRetirements. Users already met this need on their own.

Since six of our users were already familiar with the current website, they gave us unprompted feedback on their assessment experiences. They bolstered the value of the assessment’s custom recommendations. But they wanted to push it even further. Users wanted more control ranking categories or prioritizing answers. They also needed to understand why they received their specific city results. Every interviewee had a spouse they needed to consult with while planning. Some included other loved ones as well. Users needed to communicate their individual preferences to be able to make mutual decisions together.

All our users had their own method of planning, with common ideas. They often started more than ten years away from retirement. After assessing financial considerations, users would explore places that might match their personal preferences. Word of mouth from family and friends was a popular form of inspiration. They researched an area’s cost of living and housing prices first. Users wanted to try it out before buying. They needed to visit and demo places, whether that was an extended vacation, part-time living, or renting for a year or two. There is a desire for confirmation before taking the step to move.

The desire for a continued purpose was our users’ most urgent quality of life concern. Users were adamant about applying themselves. They wanted to stay active, get involved, and give back as much as possible while they were still able. Most users had specifics in mind of what they already enjoyed. They wanted snapshots of the communities from the cultural variety to available activities. Would that location have opportunities for them to keep up with their personal interests?

It started to look like the concept of a standard roadmap wouldn’t be specific or flexible enough for our users’ different experiences. But we still wanted to map the common steps we heard about the retirement journey. This helped us to visualize the interplay between factors to consider, tasks to complete, and the passage of time. We identified user needs the current state attempted to address as well as needs the future features would attempt to address.

We found that our client’s initial hypothesis was solid. But after synthesizing our interviews, we updated the problem to be more accurate:

A multitude of considerations contributes to each person’s purpose in their retirement. Retiree couples need a way to balance and discuss their own priorities with those of their partners as they explore and validate their decisions in retirement.

We developed design principles to reinforce insights about our users throughout the project:

With a narrowed direction, we explored precedents to eRetirements’ new features. Task management websites jumpstarted our roadmap brainstorming. We were using a kanban board, KanbanFlow, to organize our internal scrum sprints.

From these examples, we identified a few takeaways to consider during iterative prototyping and testing:

• Present visual overviews of process and progress
• Limit cognitive overload with sections and subtasks
• Allow direct manipulation, such as drag and drop

With the need for detailed directions still inconclusive, we focused on validating the roadmap through concept testing. I led our brainstorming session by sketching while documenting the discussion. This allowed us to then divide up drawing our paper concepts for efficiency. In total, we tested 15 versions with ten users through three rounds. We experimented with each of the following ways users would gather information:

• Task management instructions
• Direct or indirect word of mouth
• Retrospective documentation

If none of our broad options resonated with users, we could conclude that they weren’t interested in the roadmap. Yet, if any of our prototypes resonated with users, we could begin to shape the roadmap’s form. Additionally, we got feedback on other features incorporated in our sketches.

1. Users wanted the dashboard before the roadmap, otherwise, they felt overwhelmed.
2. Users liked the phases and partner division to help the process feel more manageable.
3. Users expected to build their own mixture of custom and common suggested tasks.
4. Users proposed task details with guidance on how to complete the provided tasks.

We confirmed the need for the roadmap and had a direction for its form. Next, we built an interactive prototype in Axure. We created versions of features for A/B testing to determine users’ preferences. Through concept testing, we learned it was important to not give too much information at once. The dashboard became the key touchpoint in consolidating access points to existing and new features.

After numbering our roadmap’s phases in paper prototypes, we named the phases in our digital prototype. We used our brainstormed journey map terms of prepare, explore, validate, and decide. Testing exposed the word validate as objectionable. We responded by conducting a card sort with ten users through Optimal Workshop. Taking 27 suggested retirement tasks provided by our client, users grouped the tasks and named their groups.

One user compared the two layouts to the differences between snowboarding and skiing. Snowboarding has a more difficult learning curve but is easier to master. Users were slow to notice the phases at the top. But with a fuller board, the tabs would keep the page consolidated. Skiing is easier immediately but is harder to master. Users were quick to understand how everything related and liked moving tasks between phases. But with heavier use, the page length would create the need for lots of scrolling.

After weighing the pros and cons, we chose the skiing version for initial ease of use. Users appreciated starting with an empty slate. They preferred building their own roadmap using the add task pop up, where suggested tasks lived in a drop-down. Users liked their partner’s board hidden from view at first, so it wouldn’t influence their thoughts. Again, users didn’t want to edit their partner’s side.

During our final client meeting, we handed off our deliverables and gave recommendations for the future of eRetirements. Building on insights from testing, these ideas are the next logical steps. But we did not test the degree of detail that worked for users.

To further increase personalization, users could rank the assessment’s individual questions within categories. Coinciding with this could be a side-by-side comparison of partners’ answers. The assessment could also include extra questions to determine the users’ position in the process. They could receive a custom roadmap starting point and adjusted suggested tasks.

To further integrate the roadmap, suggested tasks could link to the content that already exists on the website, such as city pages or blog posts. This could improve access to resources throughout the website. Suggested tasks details could also consist of guidance on how to complete these tasks.

To further increase personalization, users could create custom cities and contribute to city pages. Users familiar with the current website reported that they liked the incorporation of more cities and more detail on city pages. From concept testing, users wanted to learn about others’ experiences of activities and their communities, such as through reviews or photo blogs.

If we had more time, I would have taken better advantage of the prior UX design team’s research. We applied their insights, but we could have examined their dashboard and comparison prototypes’ depth of detail. Although testing a lot of concepts helped us to find our solution, we could have tested more developed concepts, informed by their designs. I learned to be mindful of assumptions based on user demographics. We applied a tech solution that was outside the box for our audience’s problem. We didn’t dismiss it before testing because of our users’ assumed tech-savviness.

While working within a smaller part of an existing website, it was important to sort validated insights from assumptions. Specifying this distinction was an expansion of my design process. We then categorized assumptions with insufficient testing into those belonging to our client or the design team. This was essential to communications with our client, so we stayed on the same page during the project. To read more about my design process evolution, check out my previous projects, Ven.u and Simple Slice.