The third part in a multi-part series about the "Lean UX" approach to product development at TheLadders.
We created the app because it was clear our customers needed an on-the-go solution for their job search. What was unclear was exactly how we could best deliver value to them. We had some hypotheses about that and did some quick tests – both on the jobseeker and the recruiter sides. These tests provided essential direction and built empathy around the specific beliefs, goals and challenges of the users our product was serving. But how to move forward?
Start with scenarios
Armed with a better understanding of users’ needs, it was time to take a stab at what the product would look like. This moment can be paralyzing, but I like to conquer it by designing scenarios. This means imagining what each screen would look like during a single complete session in which a typical job seeker uses the app. This approach helps you understand how each part of the system needs to be threaded together to create a simple experience from the user’s point of view. Once the broad strokes are established, I can circle back and consider the implications this has for the overall system, and what special conditions and states need to be considered.
As you can imagine, there are a few ‘typical’ types of these scenarios. For instance: I've just downloaded the app while waiting in line at Starbucks, and entered some information so I can get a list of jobs. Or, I’m waiting for someone so I open the app to quickly check on the latest jobs and save some for later. Or, I’m on the couch at home later and I want to go back and take a closer look at jobs I saved earlier. You get the picture. Here’s an example of a scenario, and some early designs for it:
The next natural step was to get feedback on the guesses we made with these scenario sketches. We distilled a set of tasks for user testing (i.e., Open the app and get to a list of jobs; Save a job to look at later; Find the saved job – etc.) Thanks to awesome tools like usertesting.com – and InVision– I was able to put my wireframes into a tappable, mobile-web-accessible prototype, designed a test, and had real users testing my interface within hours. We ran through a few cycles of this design work in a two-week period.
Meanwhile, the engineers needed to get started. One thing about native app development is that the interface and the back-end are interdependent. So where with web work, we’d start working on the back end while the design is still coming together, this is hard in mobile. With the core feature set and interface in flux, we asked ourselves which elements would be core to the app no matter what features we put in. We knew there would be a screen which displays the details of a job, so our engineers began plugging away on the infrastructure required for this bit while I continued to flesh out the overall flow of the application.
Create a game plan
After a week or two of iterating on sketches and testing, we took a step back and took inventory of the ideas and features the designs described. We created a user story for each feature the design presented and put it in Trello. We agreed as a group that, unlike the web – where we could iterate quickly – an iOS app required a complete, delightful experience, because the ability to update is out of our hands – it’s on the users, who notoriously rarely update. And users are fickle – they leave you one star even though they have an outdated app – and that one star is hard to recover from.
We gathered data, examined facts and debated passionately about what we thought should be in the first version or out. We whittled away to find a clear focus on the core of the application. This bit is important: we all agree – as my product manager Ben writes – that a simpler app is a stronger app. Clear focus and purpose serve everyone. So “what is essential?” became our most pressing question. In the end, we arrived at two lists: essential functionality and then a list of desired features we thought users would need but we weren't sure.
We made what would prove to be a critical decision: we’d launch an ‘alpha’ version, representing an atomic but complete user experience (in our case, the ability to find and save a job) – and bring users into the app. We’d develop the rest of the app alongside users, measuring the success of the features, and fluidly re-prioritizing the remaining features based on their needs.
We worked feverishly for a month developing the alpha. I immediately began visual design while also working out the broader, systemic underpinnings of the application. I kept an inVision prototype up to date which the whole team accessed and used as a living spec. I tested it on unwitting colleagues and friends any moment I could find. We did more rounds on usertesting.com. Finally, we were ready to release the alpha, and put real users on it.
Early visual designs of the app
In my last post, I’ll tell you all about an innovative approach we took during the last 6 weeks of development, in which we iterated while a a group of carefully selected customers from TheLadders used and provided feedback about the direction it was taking.
Want to work with people like Michelle at TheLadders? Check out our open positions.TheLadders, the premier mobile and online job-matching service for career-driven professionals. When it comes to design and photography, her eye for detail and artistic talent make her a natural. Follow Michelle and TheLadders Deve team at @zhaus and @TheLaddersDev.