The second part in a multi-part series about the "Lean UX" approach to product development at TheLadders.
Last time we met, I introduced the concept of "Lean UX", and discussed how we're putting it to work in the development of our mobile application. We got our arms around the core hypotheses, and did some quick tests with users. Next, we wanted to see how our concepts would shake out with recruiters - because after all, we can't make job seekers happy if they aren't hearing from the people who have the jobs.
The Meaning of "Team" (and why it's essential to Lean UX)
Before going further, please allow me a brief interlude on what it means to be a "team" at TheLadders. We work in a loose agile/scrum approach (more buzzwords!) - which essentially means that cross-functional teams take on a problem statement and solve them independently. While the size of the teams vary, they often follow this configuration: development team (3-5 engineers including Q/A), a scrum master (or tech lead), a product owner, a UX designer, and a Visual Designer. (Additionally, copywriters work across teams.) The scrum master, product owner and UX designer form a sort of trifecta of team leadership, but in general, the entire team collaborates around creating solutions.
Because we've been light on resources, our team is unusually small - and stellar. We have Kat, our fearless tech lead - working on iOS development. She's aided by Thomas - another jack-of-many trades, and Matt - our lightning-fast service architect. These three have been absolutely rocking it at a quick clip, and every challenge has been greeted with a "we'll figure out how to make that awesome" attitude. They also share a passion for user experience, and can often be found observing user testing. Frank is working Q/A - making sure every corner of our app meets expectations; Suz has been coordinating all our uTest cycles, and Laura finagled our algorithms into place just before leaving us to have a baby. Ben is our product owner, whose product instinct and flare for team presentations always make us look good. Finally, I've been covering user research & testing, interaction design and visual design.
When issues arise, we huddle, discuss, and agree on what we will do about it, following a 'just-in-time' approach, so we don't get distracted with unimportant or impertinent issues. We "stand-up" every morning at 10 a.m., present our progress to executives and re-prioritize our work weekly, and use trello to track our daily development.
As a team, we have established a high level of mutual trust - which is essential, in my opinion, for Lean UX to work. This trust is built in the early days by establishing a shared commitment to the problem, and a shared approach to determining solutions. The early exercises are as much about creating this trust as they are about making sure you're extracting the best ideas from aspect of the team.
Hypothesis Check - Recruiters
So it was in these early days that we took the first week of learnings from job seekers and turned them into ideas for recruiters. We gathered for another design studio. We established our problem, constraints, and who we were solving for.
Problem: As a Recruiter, I'm interested in candidates who may be right for my job but aren't applying because they aren't sure that they'd be a fit.
Who: Barry, an agency recruiter working in Atlanta. She recruits for Technology and Ops - and has 30 open job req(uisition)s. However, she's always looking for good candidates to add to her pool. Once she's reached out to a candidate, no one else from her agency can talk to them for 6 months. She works through her lists of leads in single workflows, mid-morning and afternoon.
And our biggest constraint was that it had to be worked into the current interface on the recruiter website: since our focus was the iOS app, we didn't have the bandwidth to rework major portions of this site.
We drew, created lots of ideas, distilled them into quick sketches, and shared them with recruiters. That second part proved hard.
Some of our ideas, culminated into quick sketches to share with recruiters.Learnings
Ben and I set up a handful of GoToMeeting sessions with recruiters who used TheLadders. Sharing our screen, we showed them a few concepts and asked them some questions.
We wanted to learn:
- Was our hypothesis true – did this problem exist?
- What's the best way to present these job seekers? Are they applicants without resumes? Or simply "people 'interested' in your job"?
- Do recruiters care about the immediacy of the feature (i.e., these job seekers are fresh, they are on their phones looking at your job - NOW)
- What would motivate them to respond one way or another?
- Nope, recruiters don't really seem to have this problem!
- In fact, they have too many applicants, and their time is wasted if they don't have all their details together at once (like a resume).
- Only a certain type of recruiter was willing to overlook an ‘incomplete’ in lieu of having immediate access to a fresh job seeker.
- Worst of all, very few applicants are an obvious and uncontested match right off the bat. The rest of them may or may not be a fit for various reasons - but rarely were they definitely NOT a fit. Even if they were, they were very hesitant to click a button saying so. So getting a response to the job seeker was looking grim.
Humpf! We walked away deflated - but it was a reality slap we needed. We were entering dangerous territory if we presented these job seekers as applicants, and recruiters were judgmental about job seekers not having all their information together. But we also knew (from previous initiatives) recruiters were very anxious to recruit from lists of people who were simply viewing their jobs. This nut was truly hard to crack.
We realized we wouldn't solve this in user testing - we needed to build-measure-learn our way into it. We decided we wouldn't touch their interface, and instead test our way into this territory through email, down the road.
Most importantly, this cycle preempted a long and possibly costly road of imagining, designing, building, and assessing a solution for a problem that didn't exist. It also helped us realize how tricky topic was - and how agile we needed to be to find the right path. Finally, even though we still had some big questions to answer about the core value prop of the app, we gained valuable knowledge about helping job seekers put their best foot forward, and freed up our energy to focus on this part of the experience.
In our next installment, I'll show you how we used all this early goodness to begin sketching out a complete vision for our first generation app, how we brainstormed which features we'd need, drew a line around what we thought the first version would include, and sketched, designed and tested into a high-fidelity mock-up of the full app.
Want to work with people like Michelle at TheLadders? Check out our open positions.