UX lessons I wish I had learned earlier: Job Searching
By: Jeremy Bird
Tags: Job Hunting, Job Interview, UX, Portfolio, Careers

LESSON #24: Be strategic about case studies both in your portfolio & in interviews.

I struggled for a LONG time with portfolio reviews during interviews. I knew how UX hiring managers like to understand the how & why behind the what, but the problem I struggled with is how to take a 6–9 month project and summarize the what, how, & why into just a few minute summary. I almost always ended up sharing too much info and going over the allotted time. It not only was long, it was ineffective. Invariably, trying to cover too much resulted in running out of time to cover (or bring desired emphasis) to more important topics.

Through the kindness of trusted confidants, experimentation, and a tireless determination to become better at interviewing & job seeking, there are 3 key pieces of advice I’d share if you feel like you get interviews but are struggling to land the jobs you really want.

1. Be strategic & focus on what you want an interviewer’s or portfolio viewer’s key takeaways to be.

So many of us take a chronological approach to presenting case studies. Often we even try to teach the reader/interviewer about the UX process along the way. Nearly everyone writes or presents case studies this way. The problem is that this is like hunting a duck with a machine gun, yet the vast majority of designers still do it.

Go rewatch a presentation from your favorite UX leader. They have a specific agenda — specific takeaways — in mind. Yes, they do share some background information and because great presenters use storytelling to make their presentations so it can feel chronological, but if you analyze those presentations closely you will find that they follow the rule of 3.

“Divide your message into three chunks. What are the benefits of your service? What are the main things you want the audience to walk away remembering? Most people don’t have the memory (or attention) to remember five or six main points; however, three is a number we are uniquely attuned to recall. Steve Jobs was famous for using the Rule of Three in his presentations. In 2011, he described the iPad 2 as “thinner, lighter, and faster” than the first. These three adjectives were massively effective; they said everything the audience needed to know. It was much more successful than if he had announced ‘20 ways the iPad 2 is different from its predecessor.’” — Scott Schwertly, “The Rule of Three for Presentations”

One thing that dramatically helped me improve my case study effectiveness in interviews was to break up the main idea I wanted to convey to my audience from each case study into 3 main points. Often this consisted of three key results we achieved, or 3 main skills this case study highlighted (catered to skills I know from my research that the employer is looking for). Then, tell the story of the project from that point of view. If it doesn’t prove one of your main 3 points, don’t share it.

For example, if one of my points were focused on showing the value of discovery research and how my insistence on including engineers in the research saved our project, I might say something like the following:

“On one project I worked on, we were trying to improve the amount of jobs that could be done the same day they were assigned. From a prior user interview we learned that we didn’t know as much about the users circumstances as we previously thought, so it was clear we needed to do a little observation. I insisted on bringing one of our senior engineers with me. This was met with a little hesitation, but I was able to make it happen. During one of our ride alongs with a service worker, we learned that a particular field we were basing our scheduling algorithm on was almost always wrong and could not be relied upon. This was a connection only the engineer (with his knowledge of the code base) could have made. We also learned many other things that day that ended up resulting in not only a better user experience, but in achieving the business goal much more completely. Had we not done the research and had the engineer not been present, our project almost certainly would have failed to increase same day jobs. As a result of our taking time to research, we saw an increase of same-day jobs by 37%.”

Notice that I only told enough of the story for them to understand the problem we were solving, prove my point, and what the result ended up being. It was focused on what I wanted the takeaway to be. Not a travel log.

2. Use the Star Method.

I discovered the Star Method many years ago when I was interviewing with a couple Fortune 50 companies who recommended it as part of their interview coaching sessions. It has been a game changer for me. I used to really struggle with how to summarize case studies of my work. Hiring managers wanted to understand “the messy middle” but I found that when I went into the messy middle there was just too much to cover. I almost always took longer than the time allotted. I’m certain I also bored my interviewers to death.

If you find yourself in a similar boat, I’d highly encourage you to give the Star Method a try. It has drastically helped me focus and narrow in on the most relevant details without sacrificing details on “the messy middle”.

You can check out this article for more details, but the basic idea is that you summarize your project into a 4-point arc using only 1–2 sentences per section. The outline goes like this:

SITUATION — set the stage. Give any basic background information needed to understand the context. TASK—describe the problem you set out to solve and what your goal was in the situation. ACTION—what action you took to solve the problem. What are the most important takeaways from the “messy middle” for this audience to understand. RESULT—what results came from this project? Quantifiable metrics are great here. This is also a great place to summarize cultural impacts your work had.

You will not get it perfect at first. In fact, you will likely find that even trying to summarize, you will likely have a difficult time distilling each section into 1–2 sentences. Keep at it, though, and you will get much better. I’d recommend when you first start using the STAR method, to first write it down and practice reading it out loud. Do NOT just wing it as tempting as that might be. You need this to be second nature.

For example, here is an example of one of my first attempts:

Situation

In my previous role, I was put in charge of working with a strategic partner to add support for a new kind of towing job to our web & mobile dispatching platform. Task

The goal was to help them increase the number of “same day” tows so they could better deliver on their Service-Level Agreements. As part of the request, we were asked to include their 93-step inventory form in our mobile app for the drivers to fill out before picking up each vehicle. Action

I was concerned by the user experience ramifications this would introduce into our app so I scheduled an onsite visit for myself and one of our Senior Technical Architects to ride along with a few tow truck drivers and observe the process from beginning to end. On these ride alongs, we made 2 key observations:



1. The inventory being filled out by drivers accounted for about 60% of the total time at a job site.

2. The lot attendants filled out the exact same inventory after the vehicle was delivered that the tow truck driver had just filled out. When I inquired of our partner as to why they were asking for the inventory to be filled out twice, they responded that they wanted to make sure vehicles didn’t get damaged during loading/transport to the tow yard. Result

Armed with this knowledge, I proposed that we solve their problem through adding damage reporting onto our robust photo-taking which already had geo-tagging capability. This would allow them to determine if additional damage had been caused en route without requiring drivers to spend an extra 5–7 minutes filling out a duplicate inventory. They agreed, upon the condition that we add 5 inventory fields that were important to be collected at the scene. Naturally we agreed. 5 is much better than 93. This not only improved the user-experience of the tow truck drivers, but also resulted in: • 23% increase in same day tows.

• Reduction in average pickup time from 9 minutes to under 4.

• Improved data accuracy and reporting. The key was to show how eliminating frustration of the mobile app users would also help the Company achieve the outcome the business was already focused on. This would not have been possible without user research.

As you notice, 2 of the sections are much longer than 1–2 sentences. Still, I could clearly describe the situation, task, action, and result in just a few short minutes. This was a MAJOR improvement over prior attempts. As you get used to describing projects in this way, it will get much easier.

3. Make the key takeaways really easy to find.

Once you have your key takeaways defined, make them REALLY easy to find. This includes your resume & portfolio in addition to interview answers.

One way I’ve found extremely valuable to do this is to summarize case studies using the STAR method on your portfolio. To see an example, check out my portfolio landing page. On my resume, I strip this down to a summary of “Task” & “Results” sections of key projects. An example of this can also be seen on my portfolio site.

Since I took that approach I have received LOTS of compliments from recruiters. Many don’t even click through to the detailed case studies. (They get all the information they need to want to interview me just from the landing page). My application to interview ratio has skyrocketed since I took this approach. Summarizing succinctly and calling out results you achieved makes recruiters and hiring managers want to speak with you (which is the one and only goal of a portfolio or resume.)

4. Choose the right length, for the right situation.

Recruiters and hiring managers are extremely busy people. They don’t have time to read a 10 to 20 minute case study. Accordingly you need to help them find the most relevant information in the least amount of time.

All use cases of a case study are not made equal, either. There are 3 main reasons someone would review your portfolio. It is important to understand and address each one.

IS THIS PERSON WORTH LEARNING ABOUT?

When a sourcer, recruiter, or hiring manager is screening resumes and portfolios, they are essentially just scanning quickly to determine if you are a good enough fit to justify more than a 10-second glance. You need to grab their interest quickly and help them find the most relevant case study to review. IS THIS PERSON WORTH INTERVIEWING?

Once you have convinced them to actually read a case study, they likely are only going to skim it. At this stage their question revolves around whether you will be someone worth talking to and/or presenting to the hiring manager. Do you have relevant experience? Do you know how to solve problems? Do you understand before you solve, etc. Do you have relevant or comparable experience? If they can find the answer to these questions quickly by skimming, you are very likely to get an interview. IS THIS PERSON WORTH HIRING?

You have already proven yourself a good enough fit to interview. Most likely at this stage the hiring manager is taking a 2nd look at your portfolio to look for evidence of how great a fit you would be (almost certainly after having spoken with you). They are probably trying to decide between 2 great candidates and reviewing the case study you presented for a final time. This is where they DO care about details. Maybe something was unclear from the interviews and they are looking for evidence that you’re the right one to hire.

To be the most successful, you need to attract the right employers. To do that you need to provide a good experience for users of all 3 of these use cases. I have found that the best way to do that is to deliver a 10-second, 1-minute, and 10-minute experience.

Your 10 second experience should focus on grabbing their interest quickly and make them want to learn more. To do this, you need to answer the question: “Why should I care” or “How will this person help me solve my company’s problems.

Your 1 minute experience should focus on landing the interview. Here your goal is making your case study scannable. You can assume they’ve already decided which case study they want to review. If someone spends 60 seconds scanning your case study, will they get the takeaways you want them to? (Hint: this is worth user testing).

Your 10-minute experience is what most of us typically focus on when writing case studies. The key here is to focus on including ONLY the detail needed to convey the details of your KEY TAKEAWAYS. Think of this as a more in-depth, show-and-tell version of your 10 second “STAR Method” summary. Resist the temptation to make this a chronological diary of everything you did on the project. Your 10-minute case study experience should still revolve around 3–4 key takeaways from your project. Leave them wanting to learn more.