My first #STCSummit: the debrief #STC23 #TechComm

This article is going out a little later than I’d hoped, but better late than never, and I wanted to get this out while stuff was still fresh in my mind.

After taking some time to recover, I’ve returned home from my first STC Summit! I’ve wanted to attend this event for some time, and I’m very glad I did!

I flew down on a Sunday, checked in, and took some time to decompress from my travels. (It took two flights and stops in two different cities before I arrived in Atlanta.) Even before the two-and-a-half days of sessions began, I connected with several people and even got into some deep discussions related to my upcoming presentation later that week.

I met a lot of people at this event, including STC leaders and other attendees. As it is with any conference event, networking is a huge part of it, and I did my share. My list of LinkedIn connections expanded significantly during the week! I also brought a stack of my business cards, thinking that I would have plenty to hand out. As it turned out, I should’ve brought the entire box. By the end of the conference, I only had two cards left. Personally, I like my business cards, and they’re always a conversation piece whenever I hand them out. I love the reactions I get when I give them to people!

There were a number of things that I took away from the Summit. Among them:

• Jack Molisani, one of the people I met, had an article he had written about beating the ATS. I make no secret of the fact that I absolutely hate ATS. But regardless of how I feel about it, ATS is reality, and job hunters need to deal with it.

• Jack also offered to review my resume. While I thought my resume was pretty good, I also recognize that there is always room for improvement, so I took him up on it. He gave me suggestions that didn’t even occur to me. Among them: list what I do at the very top, right-justify dates on my experience and education, use san-serif fonts to save space and for better readability, don’t list proprietary systems (genericize them instead), and make my accomplishments more actionable (e.g. “saved the company millions of dollars by…[doing this]”).

• Jack also introduced me to Dr. Craig Baehr, the editor of Intercom magazine. We spoke about possibly writing an article in which they feature STC members (like me!). I told him that I was definitely interested, and would be in touch. I hope I can live up to the standards!

• There were a number of sessions that spoke to me. I attended Amanda Patterson’s presentation about creating a taxonomy. I have to admit that information organization is an area when I could use some brushing up, and I found her presentation to be quite informative. I also attended Swapnil Ogale’s session about building an online portfolio. I have to admit that this is an area that had not occurred to me, and it’s definitely something I want to build. I’ve put in for jobs where employers ask me for writing samples, and I would send them a link where I keep a few PDF files. This session taught me that an online portfolio can be just as critical as a resume. I intend to set aside some time to build such a portfolio. The next time I’m asked for writing samples, I’ll be able to send them here.

• I would be remiss if I didn’t talk about my own session. My job hunt presentation has been one of my best sellers as of late. I think this is one of my better presentations, and everyone I spoke with afterward said that I gave a good presentation. I’m happy to help people out as much as I can, and hopefully, attendees will have gotten something out of my session.

• As part of the Summit activities, a resume review session was also offered. During my presentation, I encouraged people to sign up for it and get their resumes reviewed (a point that I mention during my presentation).

Of course, Summit wasn’t just about presentations. Conferences are also about people. I’ve attended enough PASS events that I have many friends I look forward to seeing, and STC Summit gave me an opportunity not just to network, but to make new friends as well! I succeeded in doing so; over the course of the first couple of days, although I had only just met most of these people, I felt just as comfortable around them as I do with people whom I’ve known for several years! I had no problem attending social events, spending time, and sharing meals with them!

They did have some evening social events planned, but I wasn’t able to partake because of my own plans. When I told people that I was heading to Atlanta for this event, several of my friends who live in the Atlanta area contacted me about getting together. I had dinner with four different friends over three nights. It was great getting together with friends whom I either haven’t seen in many years or don’t get to see very often, and it just added to my great experiences during my trip!

I decided to take Amtrak home, rather than flying. I enjoy traveling by train, and I wanted to take my time going home. It allowed me a chance to see parts of the country that I never get to see, as well as meeting more people on the train. My journey home, which took almost exactly 24 hours, included a three hour layover at Penn Station, which allowed me a chance to get myself a decent dinner in midtown Manhattan before catching my connecting train home.

I’ve spoken four times at PASS Summit, but this was my first time speaking for an STC event. This was important to me. Although I have been heavily involved with PASS, SQL Saturday, and a number of related events for several years (including co-founding a local user group), STC is much more closely related to what I do professionally, and speaking at STC Summit is something that has been on my bucket list for a little while. That item has now been fulfilled. That doesn’t mean I’ll rest on my Summit laurels; I fully intend to apply to speak at this event again, and I very much look forward to the next time!

Advertisement

User testing is important — for documentation

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.

When information is overlooked

I went grocery shopping the other day. I picked up what I thought were two identical bottles of salad dressing (in the photo above). I remember thinking how strange it was that they put the same bottles of salad dressing in two different spots on the shelf. Nevertheless, I took one from each side and tossed them in my cart. It wasn’t until much later, after I was home, when I looked in the pantry, saw the two bottles sitting together on the shelf, and realized that one was organic, while the other was not.

To be honest, I really couldn’t care less as to whether a food product is organic or not. I usually buy the regular product because it tends to cost less and usually has a longer shelf life. (Personally, I believe the purported health benefits of organic products are minimal and overhyped, but I digress; that’s not what this is about.) But what I am wondering is how I was blind to the fact that one said “organic” while the other didn’t.

I’m sure there are cognitive and behavioral studies as to why people are blind to certain pieces of information, but that’s a topic that goes beyond my level of knowledge or expertise. (Before anyone says anything about information bias, I will mention that while I do tend to buy non-organic products, I really don’t have a strong bias one way or the other.) Rather, what I’m writing about is the fact that information can and does get overlooked. So what do technical communicators and UX/UI designers do to combat this?

For starters, I’ll say that the fact that information is missed is a matter of when, not if. Using myself as an example, I’m the first to admit that I often have the attention span of a flea, and as such, I’ll often skim, as opposed to deeply read, documentation that isn’t my own. As such, I’ll often overlook information. Granted, many people are more thorough than I am, I’m sure, but I guarantee that everyone will miss at least one thing. We are humans, not computers, and we are not capable of scanning, parsing, and processing every little bit of information that comes our way, so it’s unlikely that we’ll absorb or retain everything that’s thrown at us.

This brings me to another of my mantras: reading is work. (You can put this on my gravestone.) Reading requires effort. The more effort that is required, the more something is likely to be missed. One of my biggest documentation pet peeves is anytime someone says “it’s right there in the documentation,” but when you look at the documentation, the information is buried like a Where’s Waldo puzzle. Nobody can be expected to find information like that, and people who insist that that is valid documentation are not, in my honest opinion, technical communicators. Bottom line: if you have an important piece of information, don’t expect it to be read if you bury it within bad design or a large black paragraph swath.

However, that wasn’t the case with the bottle of salad dressing. The bottle was clearly marked. Yet I didn’t notice it until I got home. So what can writers and designers do to mitigate missed information? I don’t know if I have the answers, but I do have some ideas.

For starters, placement matters (good designers understand this). I admit that I was confused that these bottles were on opposite sides of the same shelf. Maybe this wasn’t enough. Placing them on separate shelves likely would’ve helped. Or, maybe separating them a little from the other group of bottles (the documentation equivalent would be utilizing whitespace). Maybe even placing the bottles in a separate section dedicated to organic products might’ve made a difference as well.

Another idea would be to use different appearances, such as varying fonts, graphics, or colors. As you can see in the above photo, both bottles use white labels and feature a picture of a peach. That design led me to believe the products were identical, but yet, I completely ignored the fact that one said “organic” while the other didn’t. We often comprehend visual cues before text, so changing the picture or the label color likely would’ve been enough for me to differentiate them at a glance.

I’m sure there are other ideas as well, but the bottom line is that information can and will be overlooked. By considering better information design, the chances of information being overlooked can be minimized.

When information is removed (or, Never Assume It’s Obvious, Part 2)

I have an app for my local convenience store that I use to purchase various items, including, among other things, gasoline. On my way home this afternoon, I decided I needed to put gas in my car and stopped at the store to do so.

To use my app to buy gas, I need to input the store number (usually not a big deal — it automatically detects my store location, and does a good job of it) and the pump number. I opened the app to input the pump number, then looked at the pump for the number… and looked, and looked.

Hey, what happened to the pump number?

I looked at the pump. The number was nowhere to be found. Upon closer inspection, I saw a clean square area on the pump — where the sticker identifying the pump number was once located.

I looked at the other pumps. Same thing. No identifying numbers on the pump. At this point, I had spent several minutes trying to figure this out, and I was starting to get irritated.

I finally noticed it. The only place where you could find the pump number was on the sign above the pump (similar to the picture above).

Let’s be honest, people. How many of you would’ve thought to look UP to find the number, and not on the pump itself?

The app has a feature that allows me to send feedback. I finished filling my tank, got in my car, and used the app to send a very irate message. I’m not going to lie. I was (and still am, as I write this) very irritated. There is absolutely no way that it should’ve taken me several minutes to figure out the pump number.

Additionally, the stickers didn’t just have the pump numbers; they also had the store number. I mentioned that the app does a good job of identifying what store I’m shopping, but what if it isn’t working for whatever reason? (Note: I’ve had that happen before.) Also, it serves the purpose of confirming that the store number that appears on the app is correct.

I’m hoping that the store was looking to upgrade the stickers on the pump, but of course, I didn’t (and still don’t) know if this was the case. In the meantime, the fact that they removed information from the pump made it more difficult for me to do what I needed. What I feel, however, is that whomever made the decision to remove the numbers — a horrible decision, in my honest opinion — decided that the numbers on the signs above the pumps were enough, so the numbers on the pumps themselves were no longer necessary.

I wrote earlier to never assume that anything is obvious. This doesn’t just apply to documentation; it applies to everyday objects as well. Not including this critical information someplace where it can easily be seen (numbers on the sign above the pump does NOT count as “easily seen”) is a blatant example of information ignorance and horrible design.

Never assume it’s obvious

When I was in college, I remember a professor who seemed fond of saying “it’s intuitively obvious.” I don’t remember a lot from that professor (other than that he was a good professor and a good man), but I vaguely remember my classmates making fun of that line, partially because he used it often, and partially because it often was not “intuitively obvious.”

How many of you remember way back when the “this beverage is hot” warning labels started appearing on coffee cups? Many of us (myself included) ridiculed it, responding with, “duh!” But of course, there is usually a good reason behind the story. Now the hot beverage warning label is ubiquitous on nearly all hot beverage cups, and most of us don’t give it a second thought.

I was reminded of this yesterday as I worked on a project. I won’t go into the details (I don’t like to share details of an in-house work project), so I’ll give you the high-altitude view of it. I’ve been trying to solve a problem where multiple people are asking IT Support for assistance, and IT Support is overwhelmed by requests. IT Support does have a website where many of these questions can be answered, but it seems that people either don’t know it exists or don’t know enough to look for the answers there.

I went poking through the website. It did seem to have the tools necessary to answer many questions, as well as resolve a few issues I’m working on. It then occurred to me — the very fact that I was poking around the site to figure out how it worked. In other words, it wasn’t entirely obvious as to how to get the answers from the site. It occurred to me that what was missing was a user guide for the site. I’ve been pitching it to several people, as I believe it’s a good idea, and I think it will resolve a number of problems. Nevertheless, I’ve gotten a little bit of pushback, along the lines of, “of course it’s obvious how to use it,” and “we have links everywhere that explains how it works.” (Also, IT Support, as just about any department, tends to get somewhat protective — understandably so — of its assets and material.)

So if it’s so obvious, then why are you getting overwhelmed with questions?

As a technical writer, “never assume it’s obvious” is one of my biggest mantras, and I think it should be for anyone involved with technical communication, UX/UI design, teaching, or documentation. Simple instructions can often be overlooked (how many times do I have to say that reading is work?!?), and people from other cultures may not always understand the language or context that you’re writing, so that’s something else to consider.

Never, ever, assume anything is obvious — because more often than not, it isn’t.

It’s not them, it’s you #Documentation #ClearCommunication

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.

Heading graphics: it’s not just about good looks

I’ve been building Confluence pages as my initial projects for my (still-relatively) new employer. I’ve been building landing pages, coming up with designs and layouts as I go along.

For a couple of these pages, I wanted to come up with graphics — not just to be aesthetically pleasing, but also to give each page an identity. That way, someone visiting them can quickly and easily discern that that’s the employee resources page, or the architecture team page, or whatever page it is.

I’ve said before — and this is something that I preach as a technical communicator — that reading is work. It takes effort to read a piece of text and to comprehend it. If I’m writing a step-by-step guide, my rule of thumb is, if a step takes longer than a few seconds to understand, it has failed and must be rewritten.

Have you ever read a long piece of text (that isn’t a book you’re reading for fun) and realized how mentally tired you felt after reading it? For that matter, do you even want to read such a long piece of text? There’s a reason why people never read terms and conditions that come with applications. Take a look at all that black text, and tell me if you really want to read through it.

On that same note, it’s been often said — and it’s true — that a picture is worth a thousand words. A graphic will often convey information that’s often difficult to put into words.

Some logos are so recognizable that they are iconic: Apple, Coca Cola, Nike, Amazon, and the list goes on. If you come across a web page with one of these logos, you’ll almost instantly recognize what the page is about.

Even when I write these ‘blog articles, I try to choose graphics that are illustrative of what I’m writing.

That’s what I’m after with these Confluence pages that I’m building (they’re internal to the company, so I’m somewhat hesitant about showing them off). An employee can take a quick look at the page and know that (s)he is in the right place.

Granted, heading graphics aren’t always appropriate for every document (resumes, anyone?). However, if they’re used effectively, they can add a lot to a document and maybe even make it easier to read. Good graphics aren’t always about making something pretty; it can sometimes, in and of itself, convey a message.

What a TV ballgame can teach us about design

This afternoon, the 2021 slate of spring training games started for Major League Baseball. And of course, being the big baseball fan that I am, I took to it like a lion to a steak.

I wasn’t thinking too much about design or layout until I heard Michael Kay of YES mention, “I think our fans will like the new clean design of our scorecard.”

At least that’s what I think he said. It threw me for a loop, because I am enough of a baseball fan that whenever I go to the ballpark, I’ll buy a scorecard and keep score during the game. So when he said “scorecard,” I thought about a pencil and paper in my hand (and, usually, a hot dog or a beer in the other). At that point, I realized that he was referring to the score display in the upper left-hand corner of my TV, as pictured below.

It then occurred to me: “wow! That’s a TON of information contained in that one graphic!” At that point, I felt compelled to write this article.

So, let’s break down just how much information is contained here. (A warning to those of you who don’t know anything about baseball: for most of this article, I am going to “speak baseball.” If you’re not a baseball fan, you’re just going to have to bear with me.)

First, I’ll start with a paragraph as to what information is contained in this graphic. Be forewarned: I am about to inundate you with information.

In the top of the third inning, Toronto leads New York, 3-0. There are runners on first and second, with nobody out. Jansen, the Blue Jays’ number 7 batter in the lineup, is facing Wojciechowski, the Yankee pitcher. Wojciecowski has thrown ten pitches, and has a full (three ball, two strike) count to Jansen.

That’s a lot of information to glean from a single graphic, isn’t it? Let’s break it down.

• We’ll start with the score. Toronto 3, New York 0. (I’m sure that will please many Yankee haters out there.) The score dominates most of this graphic. I don’t want to say that’s obvious, but it does take up most of the image, and is the largest takeaway.
• Underneath the score are two names, located under the teams for which they play: Jansen for Toronto, and Wojciechowski for New York. The 7 in front of Jansen represents his spot in the lineup (which would be a number from 1 to 9). “10 P” indicates that Wojciechowski has thrown ten pitches. (Note: since Wojciechowski is an unusually long name, the pitcher’s name and the number of pitches would not ordinarily run into each other like that.)

On the right side of the graphic, we see a couple of smaller graphics.

• Let’s start with the box containing the shapes. We see three boxes, two of which are blue (and the third is gray), denoting baserunners on first and second base. The boxes represent the bases (going right to left, first, second, and third base). The boxes that are blue indicate that they are occupied by baserunners. If the bases were loaded, all three boxes would be blue; if no one was on base, all three would be gray.
• Under the boxes representing the bases, there’s a “3” indicating the inning. The arrow (represented by the triangle next to the 3) denotes whether it’s the top or bottom of the inning. Therefore, the arrow pointing up and the “3” indicates that it’s the top of the third inning.
• Now, let’s look at the “3-2” with the two gray circles underneath. The 3-2 refers to the batter’s count. For those of you who are baseball-challenged, a “count” represents the number of balls and strikes on a hitter. A batter who gets four balls is allowed to go to first base (called a “base on balls” or a “walk”). A batter who gets three strikes is out. So the “count” represents the batter’s status, and is always represented as numbers denoting balls-strikes (2-1, 1-2, 3-2, etc.). Therefore, 3-2 indicates that the batter has three balls and two strikes on him.
• Finally, the two circles under the count represents the number of outs. Each blue circle represents an out (there are three outs in an inning). That these circles are gray indicates that there are no outs in the inning. (And no outs, with a 3-2 count, and two baserunners are a pretty good indication that the pitcher — Wojciechowski — is in trouble.)

The point is that within a relatively small space, a great deal of information can be gleaned. This concept carries over into many concepts of design, including data visualization and interface design. A person who understands how to read that information can obtain a large amount of information from a well-designed graphic.

Whomever it was that designed this score display definitely knew what (s)he was doing. Kudos to the person who designed it. I think this is a great example of how good design can effectively convey information.

Fixing the worst online job application

Earlier, I wrote about what may be one of the worst online job applications I’ve ever experienced (I’d suggest reading that article first; otherwise, this one might not make sense). It got me thinking: what if I had an opportunity to fix this horror show of an experience?

Here’s what I would do.

My first instinct would be to shut down this monstrosity of a system. However, it likely wouldn’t be a good idea to shut down what might be the only means for an applicant to contact the human resources department. That said, this system is so badly designed that it’s likely to deter anyone trying to apply for positions, anyway. That gives me two options: either leave it as is, or implement a simple temporary replacement. Personally, I wouldn’t want anyone else to experience the horror show that I experienced, so I would opt for a simple replacement. The simplest option would be “send your resume, cover letter, and the position to which you want to apply to <such and such email address>.” Or, if I wanted to kick it up slightly, I’d make it a simple form: name, email, and a place to upload your resume.

If I opted for the form option, that would preclude some back-end mechanism to handle it. The simplest option would be to take that form data and put it together into an email that would format it, attach the resume, and send it to an email address. Of course, this opens another can of worms. First, there’s the matter of security. Who knows what viruses or Trojan horses are lurking in an attachment? Most forms like these ask for specific file types — usually a Word doc or a PDF — so I’d only allow those formats. I would also make sure that all security and antivirus functions are up-to-date; if a message does include a virus, at least it can be caught at the email application level, and it would be a matter of the cybersecurity team to investigate it further.

Once the temporary option is in place, and the horrendous system is shut down, I’d look into whether it’d be better to implement a new system out of the box, or roll my own.

Let’s start with rolling my own. I’d likely look into something using a SQL Server or Azure back-end (probably the latter, since everyone seems to be moving to the cloud, although that would require some brushing up on my part, since I don’t have a lot of cloud development experience). I’d probably put together a .NET front-end. Security, of course, would be a major issue to address, since we’d be dealing with applicant data. I would make sure that applicant data can be saved and pulled whenever an applicant applies for positions, eliminating the need for the applicant to continually re-entering his or her information, other than his or her login information. Again, the point is to make it easier, not harder, to apply for positions.

That said, there are a number of turnkey options that might be able to do the job better than I can. ICIMS is a popular SaaS product used by a number of employers. I would also look into other CMS systems that might exist. Other than ICIMS, I’m not sure of other applicant systems that can do what is required, but I don’t doubt that other systems exist that can maintain applicant data quite well. In this case, I’d switch my role from that of a developer to one of an analyst or consultant; what steps would I take to implement such a system? It would depend on the system and the environment.

Regardless of what system is used and how it’s implemented, any of these solutions would be better than the disaster of an application that I experienced.

The worst online job application #JobHunt

In my job hunt experience, I might have come across what may be the worst online job application I’ve ever experienced — so bad that I felt a need to write about it. I will not identify the institution, other than it is a well-known institution in the Albany Capital District. Maybe if a representative from this institution is reading this article and recognizes that it is theirs, they’ll realize what a horrible experience this is, and takes steps to fix this problem — and yes, it is a BIG problem. I consider this a case study in how NOT to set up an online job application.

In my job search, I started looking into specific companies to which I could apply, so I went to this institution’s web site. I went to their careers section, found a few positions that I thought were interesting, and started applying for them. This is where the horror show begins.

Most online applications that I’ve experienced generally have an option for you to create a profile that includes your identifying information, resume, background, and so on. Indeed, I had applied to this particular employer years ago, and they had such a system in place back then. I poked around to see if I could find my previous profile, but I couldn’t find any such link. I figured, no matter; they probably had my old email address back then, so I’d probably have to create a new one.

As it turned out, this was a red flag.

Throughout my past several months of filling job applications, I’ve gotten used to ATS systems that read your resume or LinkedIn profile and autofilled job applications based on your resume and profile. I’ve had mixed success with these systems with varying levels of frustration, but for the most part, they’ve saved me a great deal of time and effort with applying for positions.

Unfortunately, for this employer, there was no such system. I clicked the button marked “Click Here To Apply.” It took me to a page that had this interface.

(At this point, I want to point out the part that says “You may add additional positions to this application.” I’ll come back to this later, but let me say that [1] during this first run-through, I wasn’t thinking about other positions yet, although there were others that interested me, and [2] I did not see this on the first go-round. Those of you who follow my post regularly know how much I emphasize that “reading is work!!!” Again, hold this thought; I’ll come back to this.)

Okay. I clicked Continue. The next screen was the standard HR-ese about EEO and code of conduct. I clicked the requisite box and clicked Continue again.

The next screen asked me to fill out my name, address, email, and various other boxes (“have you ever worked for [name of employer] before,” etc.).

Wait a minute. It’s asking for my name. Shouldn’t it ask to upload my resume or connect to my LinkedIn account? I looked around, and there was no such button or link. Okay. I filled the requisite fields and clicked Save & Continue.

The next screen asked questions such as date available to work, salary requirements, relatives that work for (name of employer), and so on. Again, I answered what they asked, and once again, clicked Save & Continue.

The next screen displayed the following.

I took issue with this question, particularly with the “highest graduate education year completed.” I have a Masters degree, I went to school part-time, and it took me 4½ years to get it, taking a class per semester (and a summer session) as my schedule allowed. So does that mean I click 4 (as in it took me 4+ years), or do I click 1 or 2 (as it typically takes to get a Masters degree full-time)? It did not specify, and there were no instructions. I don’t remember what I answered (I think it was 2), so I went with my best guess as to what they wanted.

Directly under that question was this.

Wait a minute. You haven’t asked me to attach a resume. I suppose it’ll ask me later (I still don’t understand why it didn’t ask me to attach one at the very beginning). I clicked Save & Continue.

The next screen asked about job history.

I already have my employment history on my resume (which you still haven’t yet asked me to attach, upload, or link). You really want me to take the time to fill this in? This screen frustrated me; I’ve been working professionally for thirty years. You really want me to fill all of that in? And why aren’t you autofilling it from my resume (that you still haven’t asked for yet), like everyone else using ATS is doing? The application only asks for at least four years of employment history, but I’ve only worked for a few companies over four years, and it doesn’t tell the entire story of who I am or my professional history.

Nevertheless, the application system had me over a barrel, so I had no choice but to fill it all out. Let me emphasize that the form is not easy to fill out; all dates are drop-down selections (which, I should add, don’t work very well), they don’t auto-format fields such as phone numbers (e.g. they don’t limit area codes to three digits), and you have to fill out the fields for employer, title, job description, and so on.

I don’t know how long it took me to fill it all out. I’ll estimate that it took between fifteen and thirty minutes. It felt like several hours.

It next asked for personal references, if I had fewer than two employers. Since I definitely had more than two employers, and I didn’t feel like filling out more than I had to, I skipped this step. (And I should note: what if I worked ten years for only one employer? Yet another problem with how this application was put together. Whomever it was that put this together was obviously not thinking.) Again, I clicked Save & Continue.

At this point (step 8 of 12, according to the application), it asked to upload documents (resume, cover letter, etc.). It only allowed up to two documents (most other applications I’ve filed allowed for more than two). Okay. I added my resume and cover letter, and clicked Save & Continue.

Finally, it got to the point to review everything I’d filled out (very painfully, I should add). I clicked Save & Continue. Subsequent screens displayed the requisite EEO questions — race, veteran status, and so on. I clicked through the screens. My application was submitted.

At this point, I went back to apply for other positions that interested me. It was here where the employer’s application went from being frustrating to downright infuriating.

Almost all automated job applications send an email acknowledgement, so I looked for one after I finished the arduous procedure. I didn’t see one. After waiting for several minutes and poking around my email, I finally found this sitting in my spam folder.

It sent it as an attachment? No wonder why it was flagged by my spam filter. Since I trusted the sender (or, more accurately, I knew from where it had been sent), I went in and followed the instructions. Okay, fine. I downloaded it and followed the sign-in instructions. It had me sign into their system, where I found this message.

Granted, there was no identifying information (other than my email and the employer, which I blacked out in this screen capture). Now, I am all for data security and ensuring data is protected, but did this message warrant sending a secure attachment and requiring a login? I don’t think it was. I’ve gotten other emails from job applications that included more information that was sent less securely. One other thing I found infuriating was that there was absolutely no reference to the position that I had applied. I’ve been using my email to keep track of applications. How am I supposed to know to what position this refers? In my opinion, this message was not worth sending in a super-secure email. I felt that the mechanism they used to send this message was overkill.

I had seen other positions on the list that interested me, so I went back to apply for them. I figured that the system would take my information from the previous application and use it for the new application.

I figured wrong.

There was absolutely NO mechanism to refill all the information from the previous application. There was no applicant account function, no resume or LinkedIn ATS autofill function, nothing. If I wanted to apply for another position, I had to refill the ENTIRE application manually. Did I mention how painful and tedious it was to fill the application? It might as well have taken several hours to do so.

Now, remember earlier how I mentioned that there was a link to “add other positions to your application”? I did not see that the first time around. The next time, I tried it. The link brought me back to the ORIGINAL job search page. There was NO function to add any other jobs to an existing application. Nothing like that was anywhere to be seen. And if it did exist (and I’m not sure that it does), it is not obvious.

This application system design is so horrendous that it’s saying “f**k you” to applicants. It is doing more to drive applicants away than it is to make them want to apply for positions.

This is not the first time I’ve written about bad form design. However, this problem isn’t just about the form; it’s also about the entire application process. The design planning was poorly thought out, if it was done at all. There is no mechanism for autofilling fields. There is nothing to save applicant data. The forms are not intuitive. And I’m willing to bet large sums of money that either there was no end user or QA testing done, it was done shoddily, or test criteria were poorly defined.

I could keep going, but to make a long denunciation short: whomever it was that put this together has absolutely no business working on UX/UI projects.

The object of well-designed UX/UI and online forms is to make it easier, not harder, for end users. As an applicant, I found this process to be infuriating, not just frustrating. A process this bad will likely deter qualified applicants from applying to jobs. And if this system is that badly designed, these applicants are likely to question whether they want to work for this employer in the first place.