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.
Roles: User Research, User Experience Design, Visual Design
TheLadders wanted to make a push into the mobile space, but on a phone the standard behavior of searching and applying for a job didn't translate into a user-friendly experience. With a shift in platforms we used this opportunity to create a new experience for job seekers and recruiters.
The two main hypotheses we formulated were simple: users want to know when new, relevant jobs become available, regardless of where they are. And once they find a good job, they want to reach out to that employer or recruiter, from their phone, easily.
Based on the problem, who we were solving it for, and the constraints of mobile, we used our "living" set of user personas. These were created on institutional knowledge from years of customer outreach, reflecting real user needs.
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)
Still + video capture
Microphone/speaker (speech to text)
Integration with native apps - contacts, email, calendar, reminders, phone, text messaging
Small screen size
Lack of tactile feedback
Not always online - (users can be offline i.e., in a subway tunnel)
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.
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.
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.