As someone who has done a lot of interviewing over the years, and as a participant in the IA Institute Mentoring Program, I’ve looked at countless resumes and work samples. I am currently reviewing another such set of documents, and was about to start writing them an email with my comments, but realized that I’d basically be providing very similar feedback that I’ve provided to many other mentees. (I just can’t get over that word – sounds a bit strange, no?)
So, I thought I’d instead just post my thoughts here so that others may also benefit. Here, then, is the most common feedback I provide when reviewing someone’s resume and work samples:
The user experience of your documents can be a make-or-break factor
If I were looking at the resume of someone I’d be considering for, say, a carpentry or welding job, I’d be less concerned about a less than stellar resume design. (No offense to carpenters or welders, btw.) But when I am considering someone for a position whose very role will be about creating the most seamless connection between user and system, the design and presentation of these documents at the meta-level becomes a key focus. Why? Because the care that they took in, say, naming of their resume file is a direct reflection of the attention to detail they will be providing to the design of user experiences in general.
These are some of the most common mistakes I come across and what I would recommend doing instead:
Mistake: Submitting files, especially large files, as attachments
Even in the world of Gmail with limitless storage, lots of people are still using archaic systems such as Lotus Notes, with limited storage. By sending a huge file (i.e. maybe containing a prototype), you are essentially clogging their inbox as well as the inbox of the people they forward it to.
Additionally, once you’ve sent a file, you are married to that version of the file. In other words, if you notice a problem with the file (i.e. a typo) after having sent it, there is no way you can fix it.
Recommendation: Send links, not attachments
This is not only a much more elegant way of submitting content, it also allows you to make fixes after the fact. Just as importantly, it ensures that everyone you send it to is looking at the same version.
To be clear, I’m not talking just about resumes. Everything you submit should be done with a link, preferably a compressed link (I recommend using the is.gd link compressor), to ensure that the recipients client doesn’t clip the URL.
This, of course, means that you need to have a web space where you can post your files. In my opinion, a personal website for anyone working in UX is an absolute must, so if this is an issue for you, you should be setting up your own web space forthwith.
Additionally, you should be applying the same UX best practices to this URL as you would in the normal course of your work. Here is the nomenclature I recommend for resumes:
Having “resume” twice may look redundant, but it’s critical that the name of the resume file itself is user-friendly, which leads me to the next mistake I often come across.
Mistake: Generic, Meaningless, Confusing file names
I don’t know how many times I’ve recieved resume files titled “resume.pdf” That may seem self-explanatory to the person sending the resume, since they likely only have one of them. But the person on the receiving end usually has piles of these, which renders such a file name virtually meaningless and forces me to rename it. Not good.
Recommendation: Make your file name portable and autonomous
You should assume that your file may move through many different hands and across many different email applications. For that reason, you should first name your file conservatively from a portability perspective, meaning that you should always replace spaces with underscores (remember, when sending your file as a link, it will be part of the web address.)
More importantly, your file name needs to autonomous. In other words, it should be named such that your employer, or some 3rd party that has never met you, should be able to recognize what it is when it’s sitting on their desktop or whatever. So, if I were submitting a collection of work samples in a PDF file, the nomenclature would be something like this:
Mistake: Assuming that people actually will be reading your resume
When you’re working on your resume, it can be easy to forget that, while you’re paying attention to every syllable in the document, which you should definitely keep doing, most people who are looking at your document are likely very busy and likely looking at lots and lots of documents just like yours.
Recommendation: Design for scannability
When Steve Krug talks about users scanning rather than reading web pages, the same holds true for resumes. When I read resumes, I usually only give it maybe 30 seconds of my time during the first round, scanning for phrases that pop out, looking not only at the specific content but also at how content is organized. In line with that, these are some of my recommendations when it comes to designing (not just writing) resumes that pop.
- Put a summary at the top: This is particularly critical if you’ve got a multi-page resume. What would you tell your reader if you instead met them in an elevator and had less than a minute to summarize your skills? This is what needs to go right at the top.
- Make headings meaningful and easy to scan: Try just reading the headings in your resume. Do they include your job title? Do they crisply communicate what you’ve been up to for the last several years?
- Keep job description summaries short: Assume that the reader will only look at the first two bullets, maybe only the first bullet. Never have more than four.
- Make sure your resume breathes: Don’t use type that is too small and don’t be afraid to make good use of white space.
Finally: Think about the story of the documents you are submitting
I don’t know how many times I’ve received a folder containing a bunch of files, such as wireframes or specification samples or whatever, without any kind of instructions or supporting descriptions of what I am looking at and how I should be looking at them. Imagine how an end user would react to being presented with web content in this way. At the very least, you should always include a document that introduces the artifacts you are submitting. My recommendation, however, is to go one step further and to actually produce a single document in which you collect the various artifacts you are presenting, and include an overall introduction to the documents (perhaps describing when and how they were created), and then introduce each artifact, preferably with callouts highlighting key elements of interest in the artifact.
There are of course many more recommendations I could make about the UX of resumes and work samples, but hopefully these will be useful to someone who currently is in the process of applying for a job.