TheLadders, iOS/Android Apps

Job Search by TheLadders for iOS and Android helps match the right candidate to the right position. Build a profile based on where you're looking, what you want to do, skills, salary requirements, and the app matches you to open positions based on your criteria.

Role

Senior Product Designer

The Challenge

TheLadders faced a challenge when it came to adapting their job search and application process for phone users. The conventional approach did not result in a user-friendly experience. However, with a change in platforms, I saw this as an opportunity to change the way job seekers and recruiters interacted on the platform. By seizing this opportunity, I aimed to create an innovative and seamless experience that would cater to the needs of both parties involved.

Hypotheses
I had two main ideas: first, users want to be notified about new and relevant job openings, no matter where they are. Second, once they find a good job, they want an easy way to contact the employer or recruiter using their phone.

The Research

We used a "living" set of user personas, which were based on the problem space, the users we were solving for, and the limitations of mobile devices. These personas were created using extensive knowledge from years of interacting with customers and represented the actual needs of users.

We then tweaked them to paint a picture of how they would use the app. For example, Rashad was in his car at lunch time, scanning the list for new jobs. He finds a few he likes and wants to look at more closely later. But he sees one in particular that he wanted to get a lead on now, so he takes action.

We also looked at the advantages and disadvantages of designing for the phone:

• Users are often interrupted, and complete tasks in stage

• In some instances it is easier to consume than create

• Instead of keyboard/mouse, users have other ways to input information:

  • Gestures + Multi-touch

  • Location information (compass, GPS, accelerometer, gyroscope)

  • Bluetooth

  • Still + video capture

  • Microphone/speaker (speech to text)

  • Integration with native apps - contacts, email, calendar, reminders, phone, text messaging

• Constraints:

  • Small screen size

  • Lack of tactile feedback

  • Not always online - (users can be offline i.e., in a subway tunnel)

Design Studio
With this information we began a series of design studios with our cross-functional team - engineers, product managers, designers, and stakeholders, sketching ideas in groups. We reviewed and selected the most promising ones for a tappable prototype to test.

Learnings
After conversations with a few of our users we learned both of our hypotheses were true - users were excited about the possibility of learning about new job matches on the go, and most said they would expect to be able to reach out to the job poster via the phone. But we also found users had a high level of skepticism that they'd actually hear from anyone, and that their most desired feature was the ability to save the jobs. 

We had anticipated these needs, but hearing it from users helped us understand the severity of their needs, and unified the team around empathy for the user, rather than seeing these simply as features to be added.

Within a week we had defined our problem, created a common understanding of possible solutions (hearing everyone's voice), validated our hypotheses, and gained valuable insight that helped us prioritize and focus the development of the app.

Getting to 1.0

For this project, our minimum viable product would be version 1.0 that we could release to the app store. While our engineering team began building the core services of the app we simultaneously launched a longitudinal study. We did this for a few reasons: get the app in front of users early, observe use over a sustained period of time (six weeks), and finally to build, measure, learn (iterate) while evaluating satisfaction along the way.  

After we screened and selected a pool of test users, we began a series of weekly sprints. These sprints consisted of interviews of the user to gain feedback and insights, followed by iteration, and finally planning and reprioritization for the following week. Having these users working with us as we were building also allowed us to test riskier hypotheses early on, validating (or invalidating) our assumptions much sooner than in a traditional, non-lean approach.

Learnings
At the conclusion of the longitudinal study there were a number of findings. Highlights included discovering our job sorting algorithm needed to be rebuilt and moved to a new platform, an engineering-intensive task but able to be done concurrently during the six weeks allotted for the study. We also evolved how the "like" feature worked, and how that interaction related to the recruiter side of our platform. Other findings were more general, including general usability issues, detractors (features that users wanted but were not included in v1, whose absence would not detract from the overall experience), and finally what delighted them.

Following the first release there were several subsequent updates, culminating in version 2.0, which included a visual refresh, new features and functionality, and an Android version.