by Lisa Murnan
Tools
On one hand, it’s a good idea to keep up with the newest tools (like Sketch & InVision right now). On the other hand, it’s a pain to learn new design software every couple of years. And you might not be able to use the latest and greatest at work, so it’s difficult to get practical experience with a new tool. For example, Sketch is only available for Mac right now, and my company only uses PCs, so I can’t even download Sketch to practice with it at work. Plus my company just invested in several Axure licenses a couple of years ago, and everybody is happy with the Axure wireframes/prototypes that we produce. Why would they want to invest in something new right now?
And it really doesn’t matter that much what you use to convey and present your ideas as long as whatever tool you use works. The tools and technology change all the time, but the output doesn’t.
It does matter from a practicality standpoint if the company you work for or want to work for has a certain tool that it uses and expects all its UX designers to know and use. But once you know one design tool really well, it’s pretty easy to pick up new ones. It’s sort of like knowing Microsoft PowerPoint then switching to Google Slides or Keynote.
In my 23 years of designing user experiences, here are the tools that I find indispensable, that I use daily:
Wireframing/prototyping software, like Axure (before Axure I used Visio, before that Dreamweaver, before that HTML).
Adobe Photoshop (or anything that will let you take screenshots and crop/edit images).
That’s pretty much it. Sometimes I need to write something, so I use Word or Google Docs. Sometimes I need to create a presentation, so I use PowerPoint. Chrome is my browser of choice. I use tools like Skype, Jira, Confluence, Trello, Slack, etc., based on what projects I’m working on and how that particular team chooses to communicate. The tools change but the work doesn’t.
6
STAR Approach
Behavioral interviews are the big thing these days. Google, who was notorious for asking crazy brainteaser questions and requesting job candidates’ college GPAs (even when they were 20 years out of school), switched their approach to behavioral questions because they found (through analyzing data as only Google can) that behavioral questions were a much better way of assessing whether a candidate would be a good fit or not.
Laszlo Bock from Google told the New York Times, “The interesting thing about the behavioral interview is that when you ask somebody to speak to their own experience, and you drill into that, you get two kinds of information. One is you get to see how they actually interacted in a real-world situation, and the valuable ‘meta’ information you get about the candidate is a sense of what they consider to be difficult.”
Behavioral questions, which we’ll cover more in Chapters 12 and 13, usually start with “Tell me about a time when…” and ask you to relay a story about when you failed, struggled, or disagreed with someone. Good times, right?
Since you’ll already be stressed out because you’re in an interview and you have no idea what sort of angst from your past they’re going to ask you to dredge up, it helps to have a secret weapon you can use to quickly collect your thoughts and structure a coherent answer to any question.
Enter STAR.
STAR stands for Situation, Task, Actions, Results. It is a great way to structure a story quickly.
Situation
Setting the scene with details about the company, the project, and the timeframe.
Task
What was your role on the project or in the particular situation?
Actions
What were the steps you took and what was your thought process during each step?
Results
What was the outcome of the situation and what did you learn from the experience?
Here’s an example.
Question
“Tell me about a time when you faced a major obstacle at work?”
STAR Answer
First, set up the Situation/Task.
My first contract with ABC Company was in 2011 and I was brought in as the UX Lead for the LemonTree website.
The product owner was a guy named Ted, and everybody warned me about how difficult he was to work with. There were stories about my manager getting into legendary shouting matches with him during meetings and the other UX people on the team made little comments to me about how he was “challenging.” They all seemed very happy not to be me.
I was dreading the whole thing.
Next, talk about Actions.
I decided right then that I was not going to fall into the same sort of power-struggle trap that others had fallen into. I had been down that road in the past and it never went well.
First, I went out of my way to collaborate with him and listen to his ideas (which were actually really good) and to share my work with him as I was going.
Second, I always ran things past him before a review meeting with UX management or his manager or other executives so that he wasn’t taken by surprise in front of other people. This meant by the time I showed design ideas in meetings, he had already seen them and weighed in on them and even contributed to them, so we became a united front in review calls, and he would usually defend the design versus shooting it down. If he did have issues with the design, he would state them very respectfully and constructively.
Third, I never threw him under the bus. If I had issues or concerns about anything, I reached out to him and chatted about them privately before they became a bigger issue.
Then, talk about Results.
We ended up developing a great relationship, and he talked me up to all the guys on the business side of things and introduced me to them and trusted me to set up meetings and collaborate with them without him. He knew I’d keep him posted on my progress and that I’d let him know if I had any questions.
The screens we designed always tested great in usability tests and went through major executive reviews with flying colors, and I believe it’s because the team was so open and collaborative.
My first contract ended at ABC in 2012, but in 2013 they called me back and asked if I wanted to take on another project, this time for the OrangeCandy product line. And guess who was the product owner? Ted. He had asked to work with me specifically. And once again we designed some great stuff that I was really proud of.
This may look like a long answer but it goes by quickly when you’re telling the story.
You can use the STAR approach to answer any situational-type interview question and also to structure the case studies in your portfolio.
Resume
I recently reviewed the resume of someone who wanted to switch from product management to a career in UX design. Although he had all the right jargon in there, the whole thing rang hollow. It was just so generic. It read like a series of job description bullet points versus a summary of his experience and accomplishments. I imagined a hiring manager picking it up, glancing at it, then putting it in the circular file.
You need to make your resume stand out from the generic UX resumes. This is especially true at the junior level, when you’re trying to prove that you do indeed know what you’re doing. Some UX designers make the mistake of jazzing up their resumes with cartoon images of their faces, big swoops of color, and giant fonts. This is not the way you want to stand out. Stand out with the quality of your content. Focus on your accomplishments versus your duties. This can be hard for a UXer – we often don’t have impressive numbers to throw around like someone in sales or product management (“increased sales by $5M in one year!”), so we need to get more creative with it.
Hiring Manager Alison Green, who runs the popular blog Ask a Manager, gives the following helpful advice:
“To get at this stuff, try asking yourself: What did you accomplish in this job that someone else might not have? Did you make improvements or do something that got better results than your employer had been getting before? If you were asked what made you really great at your job, what would you say? What m
ight your boss or coworkers have said made you really great? Somewhere in there are qualitative accomplishments – and, ideally, a track record of getting things done.”
Focus on micro-accomplishments versus macro-accomplishments. If you can’t say that your design solutions were responsible for an x% increase in conversions, talk instead about how your user research uncovered some interesting trends that the team wasn’t previously aware of, or how you introduced a new way of brainstorming on the team that resulted in a lot more design ideas up front. Get specific.
A bullet point like “Conducted interviews with current customers to uncover pain points/likes” doesn’t say much of anything. We don’t even know if you were any good at it. But if you say something like, “Conducted contextual interviews with security analysts, resulting in important observations about their work environment that directly influenced our design,” you’re painting a picture of why what you do matters.
Here’s an example from my own resume. I had: “Collaborate with product management and engineering to define and design innovative user interfaces and user experience solutions for Company A’s web and mobile applications.” Anybody reading this would say, “Well, duh. That’s what UX designers do.”
I replaced that sentence with these three sentences: “Tackle challenging design problems in a highly complex environment. Redesign business-critical web apps used by security analysts in Company A’s Counter Threat Operations Centers to investigate and process security events faster for clients. Collaborate with product management and Counter Threat Unit on next-gen design for the SaaS-delivered
I know the wording isn’t perfect, but the new sentences convey that I design complex, business-critical applications that help employees do their jobs faster. I even managed to work the word “SaaS” in there (a buzzword on so many job postings these days). This rewrite is so much better than the original generic blah blah blah bullet point.
Here’s another example:
Before: “Led UX design on many digital projects including Company B’s authenticated customer portal.” Yawn.
After: “Led UX design on many digital projects including Company B’s authenticated customer portal, which improved the user experience for millions of customers.”
I didn’t have any specific metrics, but I know it was better than it was before, and the “millions of customers” detail was important, it showed that my work impacted a lot of people.
One more:
Before: “Communicated solution approach through user flows, site maps, and wireframes and prototypes.” Boring.
After: “Worked collaboratively with user researchers, content strategists, and visual designers to create innovative design solutions. Our mortgage app, which boiled the whole mortgage loan process down into four simple steps, got rave reviews from Mortgage and eCommerce executives. The head of eCommerce even traveled in person to present the design to Company C’s CEO.”
Can you tell how much more engaged and invested I sound? Doesn’t it sound so much more real?
Ok, now you try. Don’t feel like you have to change every single bullet point in your resume. Focus on your most recent position, plus at least one bullet point from each past job. Show that you’ve accomplished something everywhere you’ve worked.
PAST NON-UX JOBS AND TRANSFERABLE SKILLS
If you are switching from a career in sales or product management or development or whatever to one in UX, do not panic and hide all your past jobs and create a “functional” resume that just lists out your skills and whatever UX experience you have.
Most hiring managers hate functional resumes because they make it look like you’re hiding something from your work experience. Your resume should always include a chronological job history.
Besides, those past jobs serve as a track record of your accomplishments and experience, and prove you are a professional that should be taken seriously. And there are probably some transferable skills that you can highlight in those job descriptions. Maybe you did some focus groups or surveys or market research or competitive research (all align with user research), or print design or game design (align with information architecture, interaction design, and visual design), or front-end development with CSS/HTML/JavaScript (align with interaction design), or data analytics (align with usability testing). Maybe you talked to customers regularly in a sales or customer support job, and you passed along their feature requests and pain points to product management. Build a bridge between these skills and UX skills.
ATS
Most companies today use an Applicant Tracking System (ATS) to screen and score candidates’ resumes. ATSs are just searchable HR databases that help recruiters and hiring managers sift through large pools of applicants quickly. It’s not unusual for one job posting to get 200-300 applications since it’s so easy for people to apply online these days with tools like LinkedIn’s “Easy Apply.”
When you apply for a job online and attach or copy/paste your resume (or send a stored copy of it through LinkedIn or Monster or Indeed), it is probably going into an ATS. A candidate profile is created for you at that point, and all your information is parsed into categories (like Experience, Education, Skills, etc.) and goes into that profile.
Recruiters and hiring managers can search their ATS by keyword. Keywords are weighted based on the specific job description. This means you’re going to need to customize your resume for every job you apply for. Oh my god, no, you say. What a huge pain in the ass! Yes, it is. Bye bye, Easy Apply.
DECONSTRUCTING KEYWORDS
I just went onto LinkedIn and typed “UX Designer” into the Jobs search bar, printed out the first six matches, and highlighted the relevant keywords.
One job description said “interactive design” and another said “interaction design.” One said “User Experience Testing” and another said “usability testing.” One said “S.A.A.S.” and another said “SaaS.” One said “user-centered design” and another said “User Centric Design.” Some spelled it “wireframe,” others spelled it “wire-frame.” Two said “Adobe Creative Suite” while others just listed out the individual programs, like “Adobe Illustrator” or just “Illustrator.” One even had “Abode Illustrator.” It’s enough to boggle the mind, isn’t it?
I’m not sure how smart ATSs are, plus the functionality varies from software to software (Taleo’s capabilities are different from Bullhorn’s, for example), so I don’t know if they understand that “wire-framing” is the same thing as “wireframing” or “S.A.A.S.” is the same thing as “SaaS.” I just can’t bring myself to intentionally spell words wrong in my resume to match a job posting, so I’m going to spell them correctly and hope for the best. I gotta think a company will miss out on a lot of other great candidates, too, when the recruiter types “Abode Illustrator” into the search box. And do I even want to be a designer at a company that can’t spell Adobe?
Anyway, if the job posting is referring to an important job requirement in a certain way, mirror that in your resume where you can. You don’t need to focus on every word, just the words and phrases you think they’re going to be searching on. For example, I wouldn’t bother trying to figure out how to incorporate “outstanding communicator” or “rockstar” into my resume but I would make sure I included industry-specific keywords that were in the job posting, like “prototypes,” “usability testing,” “wireframes,” “Sketch,” “InVision,” and “Agile.” Use exact keywords, down to the tense (i.e. if the job description says “wireframes,” use that versus “wireframing” or “wireframed”).
A note about tools, since I just mentioned Sketch and InVision. My wireframing/prototyping tool of choice is Axure. I’ve used it for years and I love it. But I know enough about Sketch and InVision to be dangerous, precisely so I can include them on my resume. If I needed to get up to speed on Sketch and/or InVision quickly in order to start a new job, I have no doubt I could crank through some YouTube tutorials and a Lynda.com class or tw
o and know enough to start working proficiently in them. I might not know all the nuances of how to collaborate with other team members using them, but I could pick that up quickly enough.
I’m telling you this because almost every job posting I looked at during my research specifically asked for Sketch. They often worded it as, “Proficient with wireframing tools such as Sketch or Balsamiq,” which technically would also include Axure, but if somebody is putting a keyword into the ATS they’re going to put in Sketch, not Axure.
It’s also okay to edit your job title as long as the roles are essentially the same and you’re not giving yourself a promotion. For example, in my current job my official title is Principal UI Engineer, but I tacked on “UX Designer” because that’s really what I do. It’s not my fault that my company wants to give everybody in Engineering an engineering title. If your title is “Interaction Designer” or “Information Architect” and all the jobs you’re applying for are “UX Designer,” consider changing your title on your resume, or calling yourself a UX Designer in your Summary.
That being said, if you are a developer who is also doing some front-end coding and dabbling in UI/UX stuff because there’s no UX designer assigned to your project, it is not okay to change your job title to “UX Designer.” But you should absolutely include the UX work you’re doing in the bullet points under your job title.