The woman looked at resumes mainly to find a person’s job history, so she wanted a “job obituary” format. For a recruiter, it is much more convenient to favor candidates with experience most resembling that of the current assignment. It is much easier to reduce a candidate to simply the sum of his/her previous jobs.
This is a good resume, but it is good in only two contexts. First, when opened as an email attachment, the resolution onscreen is almost perfect, and even the “job section” stares the reader directly in the face. Second, while this resume might not be liked by HR and recruiters, I think that techies would love it. It provides much more information than the typical resume and arranges the skills by function. For a “database admin” job, the first thing an HR person would look for is previous experience under the “Jobs” section. But the technical manager might be more interested in knowing the kinds of databases a person has worked with, and what sort of administrative tasks that the person has performed. So the tech manager would want to find experience by function rather than by job.
There are two intended types of readers for this resume, and both read the resume in almost opposing ways. The HR scans the resume; the hiring manager looks a little more closely. The question boils down to how to make a resume that satisfies both the scanner and the person willing to spend more than 10 seconds looking at it?
This is a question frequently raised in usability and discussed by Alan Cooper in his book “About Face: The Essentials of User Interface Design” Different users have different goals, and it is sometimes impossible for a design to accommodate more than one persona at once. One solution might be to provide levels of customization on a website according to a user’s specific goals. Or a website could have some parts which are “high resolution” (to use Edward Tufte’s phrase) and some parts which are “low resolution.” Maybe a button can allow the user to switch between two views: general and detailed.
For the resume, one answer might be to “lighten up” the resume and include more in the cover letter. Another solution might be for the “lite resume” to include “url’s” for further information.
One problem the woman had was that my resume subverted her expectations about where information ought to be. Because the format was unconventional and she’d never encountered it before, she was momentarily flustered. On the other hand, if half of all resumes looked like this, it would probably not bother her at all. I still feel that the original resume organized job information in a superior way. But that does not change the fact that the resume scanner would have to read this one a little differently, a little more carefully.
As a website gains in functionality and content, there may be a need to redesign the GUI entirely. This may not be an easy task to do, especially if one is dealing with static pages that are not stored in a database. But there is another more subtle problem: will the user accept the change as good? Even if the redesign were better, it is not clear whether users will perceive it or so. Print media likes to redesign in one fell swoop without telling anyone. But that strategy might not work for websites. Instead, incremental changes to the GUI might allow users to continue to use their stored knowledge of how to use the website. Maybe the GUI changes can be deployed so slowly that no one ever notices the changes.