THE company

Indeed is the world’s number 1 job site. They help people get jobs. I worked on the job alerts team, which accounts for a significant percentage of the site’s daily active users.

Problem Summary

Indeed sends out hundreds of millions of job alerts every day, but when users needed to manage their job alert settings, they had to use an old, outdated, poorly-designed page that offered very little utility. I realized very early that if our team wanted to improve the overall experience of job alerts, we’d have to lay the ground work in the subscription management area to unlock their full potential.


Users needed a way to fine-tune their job alerts to fully meet their job search needs, and the product needed to be brought up to the new design standard that the design systems team was developing. The dev team set out on updating the back end code, and I started working on updating and expanding the job alert subscription management experience.


I started by studying the current experience. I wanted to understand everything the user could accomplish in this experience, the needs the product managers felt should to be addressed, as well any additional benefit I felt like we could provide. Initially I was presented with a handful of smaller tickets in JIRA describing all of the changes the PMs wanted to see implemented. I realized that it would be better for all of us if I took those tickets and rolled them all together to design a holistic, cohesive experience, instead of trying to add one small feature after another. The PMs agreed, and gave me the go ahead to approach this as a total redesign. We agreed that it would be easier for me to design a full experience, and then to break the eventual experience down into stages that we could build with the development team.

Next I conducted a competitive analysis. We weren’t the only ones doing job alerts or subscription management, so I took a look at competitive and comparative examples to get a sense of the types of experiences users were already encountering, and the types of mental models and design paradigms that had already been established. One of the primary considerations I determined we needed to make was combining management of email alerts and mobile push notification alerts. We weren’t doing a lot in the mobile alert space at the time, but it was clear to me that we needed to, and that my design should be robust enough to accommodate those and any future forms of alerts we’d come up with in the future.

After the competitive analysis was done, I began documenting all the ways users could arrive at the subscription management experience. Normally I would dig in to which of our established personas this redesign would be targeted at, but this was one of those rare instances where literally every user would need to be able to use this experience successfully. I knew we wanted to encourage users to manage their job alerts from the job alert email, but they could also get there from any page on the site via a dropdown in the global navigation. At the same time, I had already developed some ideas around making subscription management more obvious in other places around the site, from the homepage to after the job alert sign up experience.

Once I finished the competitive analysis, it was time to dive in to user stories. I documented the ones that we were currently covering, and then came up with ones I thought we should be offering. I used these to inform my approach to the redesign.

As I was doing this work I noticed that users could sign up for a job alert with filters from their search applied to the alert, but there was no indication that these filters had been applied, and after the alert was created there was no way for the user to see which filters had been applied or to change them. If they wanted the same search with different filters, they would need to create a brand new alert from the SERP page. I felt like this was a glaring missing piece from the current experience, so I was determined to make it a cornerstone of the new experience.

After I felt like I had a strong grasp on the user needs as well as the business needs, I started exploring multiple ways to solve the problems the team agreed on. I mocked up several directions, then met with other designers, design systems team members, design managers, and product managers throughout the process to arrive at something we all felt looked good, worked well, solved the user’s needs, and fit within the new design system.

Once I had a firm direction that had buy in from all of the related parties, I met with content strategy to refine all of the language used in the new layouts; from button labels, descriptive text, alert messaging, and anything else content related.

After the content review was finished, I took all of the screens and started putting together a clickable prototype using Sketch and InVision. I had internal users test the prototype to make sure it was ready to be tested by external users.

I worked with one of our user researchers to develop a remote user testing strategy leveraging my InVision prototype and to better understand how successful the new design would be, and any elements that were confusing or challenging to potential users. Once we got the results, I made some minor changes to the designs based on the feedback received from the users.

Finally, the design was ready for handoff to the dev team. I worked closely with them throughout the development process to make sure my design vision was realized.

Initial design explorations


Final design concept

mobile design concept