There are lots of buzz words flying around in product development these days, but what they are and how they are applied can be hard to grasp. I’d like to pull the curtain back and share how we’ve been applying “Lean UX” in product development at TheLadders.
My team has been working on an iPhone application for our job seekers, which is due to launch in the coming months. As Lead User Experience Designer on the project, I have collaborated closely with my team, applying a “Lean UX” approach – which TheLadders is known for, thanks to the great work of Jeff Gothelf and Will Evans, my predecessors here. In this multi-part series, I’ll share with you how we got through the early, foggy stages of product definition quickly; how we built out the guts of our app while constantly testing with users; and a cutting-edge long-term study we’re running with real users for the last two months of development, while we refine the last set of features.
First: What is this “Lean UX” you speak of?
Inspired by Eric Reis’s Lean Startup, in a nutshell, “Lean UX” is an approach to design that emphasizes cutting waste by experimenting your way toward results as quickly as possible. “Results” are often defined by some indicator of business viability or customer satisfaction – so this often means getting something in front of customers that we can learn from. In traditional (“waterfall”) design, a problem is defined, then a solution is thoroughly designed and specified before anything is built. With Lean UX, the problem is defined, reduced to its core, and then we sketch, talk, and prototype in quick succession to make something to get in front of customers for feedback. We bring these learnings back to the shop, retool what we need to, then put it out there again, iterating like this until we have enough information to go back and take a real stab at the larger solution.
We began with a hypothesis, an understanding of constraints, and some overall design principles.
Our hypotheses were simple: we thought that users want to know when new, relevant jobs become available, regardless of where they are. We also thought that once they find a good job, they want to reach out to the employer or recruiter – from their phone – with ease.
Because any good app is usable within the first 30 seconds – and it can be hard to get people to come back once they put it down – we identified other important problems we’d encounter, and broke the entire problem into 3 parts: First use by a new member, core functionality, and re-engagement. We decided to focus first on the core of the application – discovering jobs and taking action on them – and created some ideas.
Design studio is a (fun!) team exercise, where everyone in your cross-functional team (in our case: engineers, product managers, designers, and stakeholders) generates ideas in the form of sketches of the actual interface. The process is preceded by declaration of the problem you are solving, who you’re solving it for, and any guardrails, or constraints, you must work with.
In our case, we drew ideas for Rashad, a “proto-persona,” or sketch based on institutional knowledge from years of customer outreach, who we felt may reflect real user needs. We painted a picture of Rashad using the app: he was in his car at lunch time, scanning the list for new jobs. He finds some he sort of likes and wants to look more closely at later. But he sees one in particular that he wanted to get a lead on now, so he takes action.
Before starting, we also reflected on the advantages and disadvantages of the designing for the iPhone:
- Users are often interrupted, and must complete tasks in short bits
- It’s easier (and preferred) 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, iCloud, phone, text messaging, twitter, passbook, maps, voice memos
- Small processor size
- Small screen size (difficult for older folks and fat fingers)
- Lack of tactile feedback (another reason typing is hard)
- May not have internet – (users can be offline i.e., in a subway tunnel)
With this, we drew. And we created lots of ideas.
We reviewed them all, and selected a few, which, thanks to POP app, we were able to photograph and organize into a simple, tappable prototype to share with users on a phone.
TheLadders was conducting a public event the next day, so we had a great opportunity to do exactly that. We wanted to know: (1) Do job seekers need to know about jobs on the go, and if so, what sort of support do they need? and (2) Would reaching out to a recruiter about a job they’re interested in, on their phone, solve a need they have?
Through conversations with a handful of users, we learned a few things. First, both of our hypotheses were true – users were pretty excited about the possibilities of learning about new job matches on the go, and most of them said they would expect to be able to reach out to the job poster via phone. However, we also learned that they had a high level of skepticism that they’d actually hear from anyone, and that their most desired feature would be an ability to save the jobs.
To be honest, these weren’t mind-blowing learnings; we had anticipated these needs. But hearing them from users helped us understand the severity of the needs, and unified the team around empathy for the user, rather than seeing these as simply features in a backlog.
Within a week, we had defined our problem, created a common understanding of possible solutions (and heard everyone’s voice), validated our hypotheses, and gained valuable insight that would help us prioritize and focus the development of our app.
We took this information back to the office and imagined what the recruiter side of things would look like – after all, we work in an ecosystem, where what happens on one side affects the other.
In the next part, I’ll share how we explored this part of the problem, and then took all these early experiments into higher-fidelity product development.