Any application developer will (and should) tell you how important end user testing is for their product development. It’s an important part of the development lifecycle. Developers need to know if their applications actually work, if they work the way they’re intended, and if their interfaces can actually be used. Without user testing, developers put blind faith in what they produce, and they have to assume that their applications are perfect every time, all the time — which, as we all know, always happens. User testing is critical in ensuring that you create a quality product.
So how often does your documentation go through user testing?
I’ve said many times that document development needs to go through the same steps as application development, and this is one of those steps. It is (sadly) common for documentation to be released without being checked for accuracy or usability. This is another way in which document development gets absolutely no respect, whatsoever.
If you’ve written, say, a set of instructions, one of the best things you can do is to give it to someone to make sure (s)he can follow it. How (s)he follows it readily tells you how well it was (or wasn’t) written, what does and doesn’t work, what adjustments need to be made, and so on.
It may not even entirely be the wording that needs adjustment. How easily did the person find information within the document? Was it there but not easily found? Was it overlooked? User testing not only can determine content accuracy, it can also serve the same purpose as UX/UI in that it can determine how effective object placement and document layout is.
And like application development, user testing your documentation determines what adjustments need to be made before it’s released. Additionally, user testing isn’t just critical for development; it’s important for document maintenance as well. Documentation that hasn’t been adjusted for changed environments makes for inaccurate information. Much of that can be caught through user testing.
I’ve said time and again that document development needs to be treated the same way as application development. User testing is an important step in that life cycle. It determines that your document quality is improved when it is released. Without it, you run the risk of releasing bad, poor quality, or inaccurate documentation.
A friend of mine (you know who you are) posted this to his Facebook this morning. Ostensibly, it’s in response to the growing controversy about the New York State governor (I won’t go there; that’s not what this is about, and I still despise politics), but my friend’s post was so compelling that I thought it was worth sharing.
As a professional communicator, I can’t tell you how many times someone either delivered a talk or a document and became frustrated when (s)he didn’t understand why his or her message did not get conveyed. Granted, in some cases, it might be that the sender is not a native speaker of the language and doesn’t know it well enough to convey his or her message. For those people, I’ll cut them some slack.
However, I am continually frustrated by people who insist that (s)he wrote a great document, only to find that what (s)he wrote was so obfuscated by detail, technical jargon, lack of organization, an avalanche of information, poor command of language, lack of understanding about design, or other reasons. This is the kind of thing that keeps me employed as a technical writer.
I’ve written many times before that it’s often the sender’s responsibility to ensure the message is clear. For example, I’ve come across too many instances (and I still continue to) in which a technician, writing a document, keeps insisting on including every little piece of detail in his or her document. And I continue to pound into people’s heads that reading is work!!!
So to my friend who posted this this morning, all I’ll say is, thank you for supporting my passion and my mission. This is exactly what drives me to do SQL Saturday and Data Saturday talks. And I’ll continue doing so until people get the message.
If you’re an application developer (or at least you used to be one, like me), how many times have you come across an old piece of code that you wrote and said to yourself, “what the f*%k was I thinking?!?” You say to yourself, I can write that much better now than I did back then, and your instinct is go back and change everything that you’d previously written.
The same holds true for documentation. I recently had an experience that reminded me of that.
Indeed, when I went through my slide deck, I was hit with a case of “what the hell was I thinking?” Many of my statements and references were outdated. I found that I could rewrite much of what I’d originally written, making them more efficient and readable. Some items were unnecessary, and I eliminated them altogether.
I spent a couple of days rewriting my slides. When I was finished, I discovered that I liked the new slides much better than my old ones. I took the new slides and made some minor modifications (mainly removing the SQL Saturday LA branding so that it was more generic). If you’d like to see them, you can download them from my Presentations page.
So the moral of the story is, no matter how good you think something is, it can always be better. Don’t be afraid to review and edit something you’ve created. You might find that you like your new version even better.
Yesterday, a good friend of mine texted me, asking me to send him my resume. This particular friend works for a major nationwide consulting firm. I won’t say which firm, but I will say that it’s a household name. In his position, he is often in a position to hire, and he is well-connected.
After reviewing my resume, he texted me back again, saying “let’s talk. I have some ideas that might make your resume even better, and I want to make sure those changes are implemented before I pass your resume along. Do you have time to talk tomorrow?”
I got off the phone with him a little while ago, and what he had to say was eye-opening — and in our conversation, I managed to improve my resume even more.
His advice (and I’m paraphrasing here): “what projects are you the most proud of? As a hiring manager, that’s something that stands out to me. Your work experience looks good, but everything you mention is general day-to-day activities. You don’t really list much in terms of a specific project you worked on. For example, something like ‘I designed such-and-such app that helped people do their work more efficiently by whatever-it-did-to-help-them, saving the company millions of dollars’ is something that would stand out to me. What are you the most proud of? Make sure you highlight that in your resume.”
I did raise a concern. I told him, yes, there is a project that immediately pops into my head, but it goes back many years; in fact, it’s a project I worked on for a company that goes outside of the past ten years. He told me, “that doesn’t matter” (he also relayed to me a project that he was proud of that took place over twenty years ago). “I’m proud of that, and I still include that in my profile.”
I had my resume file open in front of me during our conversation. While we were talking, editing ideas started forming in the back of my head.
His suggestion was to include these projects in my work experience, but I decided to leave that section alone. Instead, I decided to rewrite the Career Summary section of my resume. I wanted to do it this way for a couple of reasons: one, this appears at the top of my resume and would be the first thing that prospective employers read, and two, rewriting the Work Experience listings would have been a lot of work, and could have potentially resulted in document restructuring issues.
In terms of projects in which I take pride, I immediately wanted to mention a server inventory database that I built years ago; whenever anyone asks me about a professional project of which I am the most proud, this is the one that I always think of immediately. I also wanted to mention my involvement with recovery efforts after 9/11 (my Disaster Documents presentation is based on this experience), so I included that on the list as well. I also wanted to include a project that was much more recent, so I included a user guide that I wrote from scratch, including developing the Word template for it (additionally, I wanted to highlight that it was for a SaaS application). Finally, I also wanted to make mention of a project in which I learned about MVC concepts (unlike the other projects, this one does appear in my Work Experience section).
There were also a few other things I wanted to do with my Career Summary section. A while back, I came up with my own personal tagline, but it did not appear in my resume. I wanted to make sure it was included. Additionally, whenever I submitted my resume, I was finding that I was experiencing confusion on the part of prospective employers. I was (and still am) targeting primarily technical writer positions, and I was often questioned, “with all this technical experience, why are you targeting tech writing jobs?” I wanted to restructure it in such a way to explain that I was drawing upon tech writing as a strength, without sacrificing the fact that I had a technical background.
Before I made my edits, the Career Summary section of my resume looked like this.
When all was said and done, this is how it came out.
Additionally, I had to make changes to other sections of my resume, entirely for formatting purposes. I wanted to ensure that it would fit on two pages. I consolidated a few sections of information that, while helpful, I didn’t think would be as important.
I made the changes, updated my resume files (Word and PDF), and resent it to my friend. As of this article, I’m still waiting to get his feedback (he texted me to say he was busy, but would look when he had the chance), but personally, I like the way these changes came out.
(Edit: I heard back from my friend; his advice was to keep the accomplishments to one line each. In his words, “make it punchier.”)
You don’t necessarily have to do this within your Career Summary section; this was how I decided to approach it. If you can incorporate these highlights into your work experience listings, then by all means, do so.
I want to mention one thing when adding “proud accomplishments” to your resume. There is a fine line between talking about accomplishments you’re proud of and bragging about things to stroke your ego. Keep in mind that the purpose of a resume is to get you a job interview. Talking about projects you did that made a difference can help with that effort. Bragging about things you did (or didn’t do) will not. Nobody cares about your ego; they care about what value you can bring to their organization.
So what are your thoughts on these changes? Feel free to comment on them, especially if you’re a recruiter or a hiring manager.
I had a conversation today with a recruiter — technically, it was an interview, but the way we spoke, it was more of a conversation between an agent (her) and a client (me) — who gave me some advice regarding my resume. I came away from the conversation with a few insights, and I’d like to share those insights here. This is not the first time I’ve written about resumes. I continually learn something new about them.
We left the conversation with her giving me a homework assignment: revamp my resume to incorporate what we had discussed.
Probably the biggest takeaway was to rethink how I was presenting my resume. I shouldn’t have the mindset of a job seeker telling prospective employers to hire me. Rather, I needed to approach it as a marketer. I’m marketing a product. The product I’m marketing is me.
This mindset is important. When you’re trying to present yourself to an employer, you feel a need to impress them with your extensive experience, everything you’ve done, and the many reasons why the employer should hire you. But if you’re marketing yourself, the thought process shifts. Instead, you’re advertising yourself and your skills. “Hire me! Here’s why!” She told me that it’s okay to not put everything on your resume — not lie, mind you, but rather, not throw in the kitchen sink when putting your resume together. Just highlight the important selling points. If they want to know more, they can refer to your LinkedIn profile — and maybe even call you in for an interview (which, of course, is the purpose of a resume).
I found this to be profound, because this is a point that I espouse as a technical writer, and yet I don’t practice what I preach when it comes to my resume. I am a believer in not necessarily including everything on a document. And yet it never occurred to me to apply my own technical writing skills to my own resume. Don’t try to provide every little detail. If they’re interested, they’ll ask for more (and if they want more, they can look at my LinkedIn profile).
I mentioned ageism as a concern, and a possible reason as to why I haven’t had a job nibble in seven months. (I believe ageism exists in the job hunt; it is illegal, but is nearly impossible to prove.) In the same vein of not needing to include everything, one of the takeaways was to only list positions for the past ten or so years. One of my concerns was that my experience before 2009 would likely reveal my age, but at the same time, it was all professionally relevant, and I didn’t want to leave it off. She suggested an idea that had never occurred to me: list the jobs (employer and title), but leave off the dates. Just say “here’s where I worked before 2009.” Again, if an employer wants to know more about those positions, check out my LinkedIn.
As an afterthought, after I’d removed the dates from the older positions, I still had a potential age identifier on my resume: my educational experience included my dates of graduation. Sure enough, in my latest resume revamp, my graduation dates will be removed. Employers just need to know I have a Masters degree; they don’t have to know when I got it.
The recruiter also asked me another question: what accomplishment at each position are you proudest of? I have to admit that that was a good question. She said that it was a question that should be asked for every listed position, and the answer for each was something that should be included on the resume.
I was told, be your own client. Market yourself. When it comes to marketing yourself, you’re your own blind spot. Only when it was pointed out to me did I know that the blind spot was even there.
This afternoon, I saw a tweet from James Phillips, who posted this:
It reminded me of what I think is an important point when you’re interviewing for a position. I responded with this:
This is a point that I emphasize in my job hunt presentation; in fact, I made mention of this in an earlier article, and I think it’s important enough that it’s worth emphasizing again. When you’re preparing for a job interview, make sure you have at least two or three questions prepared for the interviewer (I’d even prepare more that that; note that you don’t have to ask all of them). I’ve also mentioned this during Thomas Grohser’s interview presentation. I’ve sat in on his presentation a number of times (sometimes at his request), and I make sure that I bring this up as a talking point.
If you’re interviewing for a job, one of the worst things you can do is NOT ask any questions at an interview. I’ve heard several stories of people who blew their interview because they did not ask any questions — and for good reason.
When you’re interviewing for a position, keep in mind that you’re interviewing the company just as much as they’re interviewing you. You want to ensure that the position is the right fit for you — that it’s something that interests you, something you think you can fulfill, and the company culture is the right fit.
Asking questions is also a signal to the interviewer. It demonstrates that you are interested in the job and the organization. Not asking questions not only shows that you’re not interested, it also shows that you aren’t taking the interview seriously. This could prove fatal to your job interview.
That being said, it’s also important to ask the right questions (I actually wrote about this a while back). The best questions are those that demonstrate that you’re willing to be a team player for your prospective employer. For example, one question that I always bring with me to every interview is, “what is your biggest issue, and what can I do to help?” It demonstrates that I’m interested in the company, and that I’m willing to help resolve any issues that arise. Try to avoid questions that are self-centered (e.g. “what’s in it for me,” “what’s the salary range,” etc.). (That said, you’re going to want to know about the company, so try to phrase your questions in such a way that it doesn’t sound like, “what’s in it for me?”)
Whenever I prepare for an interview, I’ll research the company, and I always prepare appropriate questions in advance, such as “how can I help you solve your problems” (shows that I’m a team player), “what challenges does your organization face” (shows I’m interested in the company), or “what does your team do for fun” (shows I’m interested in team dynamics).
A resource I’d suggest is a book or website about good interview questions. There are a number of them out there (here’s a link to a few books on Amazon). Go to your local library, buy your own copy, or search Google. All of these provide good suggestions for appropriate questions to bring to a job interview.
Asking good questions won’t necessarily guarantee that you’ll land the job, but not asking questions nearly guarantees that you won’t get the job. Prepare questions in advance, and be prepared to ask questions as things come up during your interview. Don’t blow your interview by not asking any questions.
After this weekend, Christine wrote this ‘blog article. I haven’t yet had a chance to fully process it (as I’m writing this, I haven’t had my coffee yet, and my brain is still in a fog), but what little I did process, I found interesting.
I intend to scrutinize this more when I’m a little more awake. And I suspect I’ll be making some adjustments to my presentation.
INTRO: Recently I attended a presentation where a commonly held belief was repeated and I feel the need de-bunk this. The speaker stated “75% of applications are rejected by an ATS (applicant tracking system) and a human never sees them…”
First, I want to point out that recruiters will tell you this is false. As the main users of ATSs, recruiters have extensive experience and years in talent acquisition, and will tell you they hear this all the time and they cringe upon it’s utterance. But if you want to know my opinion on why this “myth” has infiltrated the job seeking world, scroll past all the research and jump to the end.
MY RESEARCH: Secondly, let’s track down the origin of this false statistic. The speaker I heard it from cited topresume.com. So I did some digging:
I’ve come across my share of bad design, and I’m sure you have as well. I’ve especially come across some egregious examples as a job applicant.
I came across one that particularly set me off. While poking around Indeed, I found a technical writer position for GitLab that interested me. Of course, most people who work in IT are familiar with GitLab, so they have a reputation. I read through the description, and it sounded interesting, so I clicked the button to “apply on company site.”
The page talks about the technical writer roles and responsibilities. It talks about the hiring process, it includes a salary calculator, and it even talks about benefits, including stock options.
Nowhere on the page was there any link to actually apply for the position!!!
If you don’t believe me, check out the link and see for yourself. No wonder why they need technical writers. I understand and appreciate GitHub’s reputation in the IT community, but this page is seriously making me question whether or not I really want to work for them.
GitHub is far from being the only offender. I came across another page that, even after they asked me to upload my resume, it still asked me to manually input my work experience. (Even worse, these were required fields; there was no way around this. What if you’re a student with no work experience?) After I hit Submit, it came back and told me there were errors. It had cleared out all the dates I’d entered (I had entered months and years), and it insisted that I entered days. Seriously, raise your hand if you actually remember what day you started or ended a job from years ago. I have enough trouble just remembering the month or year. It made me question how well their automated formatting really worked (if it worked at all). Once I filled those in (with the best guesses for days), it told me there was another error. I clicked the message, expecting it to show me where the error was. Nope. It just told me there was an error. I had to search the entire page to figure out what it was complaining about.
I’ve come across too many forms like this during my job hunt. I also remember coming across some very badly designed forms years ago from previous job hunts — some that were so badly designed that they discouraged me from applying for the jobs.
I’ve talked about making documentation easier for the end user, and this is far from the only article I’ve written about how bad design is a detriment to anyone who needs to follow instructions. UX/UI needs to be as painless as possible for the end user. If you’re a vendor, bad design can drive away customers. If you’re an employer, you run the risk of discouraging qualified applicants.
Like good documentation, good form design needs to be well-thought-out and well-designed. Don’t be the organization that lost customers because your forms were too arduous to use.
My wife and I have an anniversary coming up, so I started planning a getaway trip to celebrate. (Because of the pandemic, we decided to keep the trip short — only one night, and we’re not venturing very far — only about an hour’s drive from our home.) While I was making my travel plans, I started poking around my own TripAdvisor profile. I had posted a few reviews, and I thought I’d post a few more. I figured my experiences and opinions could help other people looking for travel information, and it’s entirely possible that, by the time you’re finished reading this article, I’ll have written a few more reviews.
One of the biggest reasons why I started my ‘blog was so that I could write about my own experiences for the purpose of helping people. Helping other people is one of my great passions, and while I can’t always help physically or financially, I can help by providing information. It’s what I do professionally, and it’s what drives me as a professional technical communicator.
However, you don’t have to be a professional technical communicator to help provide information. There are countless forums out there, covering nearly an endless number of topics, in which you are able to provide your feedback. You’re probably tired of hearing automated support lines that say “your feedback is important to us.” But feedback is important. Feedback is data. Whatever feedback you provide helps to make products and services better.
How often had you looked something up (e.g. an answer to a technical problem, a hotel review, suggested driving directions, etc.) and became frustrated because you weren’t able to find any information? If you’re an application (or any type of IT) developer, have you ever been frustrated because you asked for feedback about your product, and no one would give it to you? That feedback would’ve been valuable in debugging and improving your product. This is why QA testing is a big deal, and is usually a critical step in development life cycles.
This isn’t limited to just IT professionals. It applies to just about anything in which information is involved. If, for example, you were making travel plans and wanted information about a destination, have you ever been interested in, say, a bed and breakfast, but you couldn’t find much information about it, and no one had written any reviews about it? Those reviews would have gone a long way in providing information about that place.
A lot of us brush off the messages that say “your opinion matters.” The thing is, it really does. Don’t be afraid to express your opinion or to provide feedback. What you say can help someone make a better decision, help improve a product, or possibly change the course of someone’s business for the better.
Now, if you’ll excuse me, I’m going to go and write a few more TripAdvisor reviews…
It’s been a while since I wrote a COVID-19 update, so I think this is Part 16.
This morning, I had a text conversation with a friend who gave me a badly-needed kick in the butt.
A little background information is in order here.
I’m not going to lie. I have been very discouraged by the job hunt (going on nearly three months, now). It seems like every place that I’ve applied has rejected me — to the point that my job hunt morale has taken a big hit. I can count on one hand the number of interviews I’ve had, out of the many dozens (and counting) of applications I’ve submitted. My job situation has been a major source of stress, along with a few other things (that I won’t get into here) that have added to it. The only thing that has kept me going is my LLC. I have a couple of clients that have been keeping me busy, but it’s still not yet enough for me to pay my mortgage. I address acknowledging your own emotions at the beginning of my job hunt presentation, and I, myself, fell into the same trap.
And, of course, I have not been helped by the COVID-19 situation.
My friend — a former co-worker at my previous job — told me, in a nutshell, to get off my duff and get busy again. He reminded me of a few things that, as it turned out, I badly needed to hear: I need to learn new things, I need to keep learning and stay on top of things, I need to keep plugging away, I need to keep working, and possibly the most important reminder: I have the smarts, the talent, and the wherewithal to do great things. Don’t throw that away.
Our conversation reminded me of the many good things I do have going on, and either want to continue doing, or want to restart. My LLC has been a source of professional and educational experience during a time when I badly need it. I’d started a few endeavors during this COVID-19 crisis, including starting my new business, starting a Couch-to-5K program (which has been on-hold lately because of health issues — not COVID-19 related) and teaching myself French. There are some other things that I either started a while ago or in which I’ve been active, but have also fallen by the wayside: teaching myself BI, teaching myself GitHub, and getting back into my music, including my songwriting endeavors. I also want to make sure that I brush up on my development skills that have become rusty over time.
Some people are able to stay strong throughout this crisis (which seems to have no end in sight), while others need an occasional boost. No matter who you are, it’s easy to lose sight of things, and it’s important to have support to keep that going — which includes friends who’ll give you the occasional kick in the butt when you need it. One of the casualties of the COVID-19 crisis is that we’ve been so isolated that we don’t see our friends (other than immediate family within your household) as much as we’d like or need. Your friends are your support system, and good friends will get you back on track when you need it.
So, to my friend with whom I spoke this morning, if you’re reading this, thank you again for that kick in the butt. You likely helped me more than you know.