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.

Bad web forms — how to drive people away from your site

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 subsequent link took me to this page.

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 company logo on a shirt

I was poking around VistaPrint‘s website the other day (this is the site I use to make my business cards). Of course, with any business that sells promotional items, I was greeted with the proverbial “try your logo on this product” popup window.

One of the items that came up was shirt designs. I decided to have some fun with it, and came up with the design that you see above.

I thought it came out pretty well! I decided to order two shirts, one for my wife and one for myself. I plan to wear it whenever I go to the gym and whenever I attend networking events, or events where I’m presenting, such as SQL Saturday.

If you like this shirt, you can order one, too; just click this link! I’m not getting any money for shirt sales. My payment is you walking around advertising my business!

Alas, I don’t yet have a large marketing budget where I can buy a hundred shirts and give them out for free. Hopefully I’ll get to that point, but I’m not quite there yet.

Communication lessons from air disasters

I’ve always had a morbid fascination for air disasters.  (Don’t ask me why; I have no idea.)  I’m fascinated by shows such as Air Disasters, Why Planes Crash,  and Mayday: Air Disasters.  Whenever I hear about a plane going down, I’ll start thinking about what happened, clues, what might have caused it, and so on.  There are times when I think I should have gotten a job with the NTSB.

Greg Moore has some publications in which he talks about lessons learned from aircraft accidents; his book partially discusses these lessons.  He also has an excellent SQL Saturday presentation titled “Who’s Flying The Plane?” which talks about lessons learned from air disasters and how they can apply to IT.  Go check it out if you have a chance; Greg gives a great presentation!

For the purposes of this article, however, I want to concentrate on a particular topic: how communication — or, the lack of — either contributed to or was the root cause of a disaster.

Last night, I watched an episode of Air Disasters that talked about the plane crash that took the life of professional golfer Payne Stewart. The plane went down after the cabin depressurized (the cause of which was never determined), the crew became incapacitated, and the plane ran out of fuel. What made it interesting to me was that bad documentation might have been one of the contributing factors to the accident. After the cabin lost pressure, the crew likely consulted a checklist, as is standard procedure for nearly any cockpit activity or incident. The checklist was poorly written and unclear. What should have been the very first instruction was, “put on your oxygen mask.” It was not. By the time the crew got to that instruction, it was too late; they were overcome by hypoxia.

It reminded me of a tenet that I preach in my documentation presentation: if, in a step-by-step instruction, an instruction cannot be understood within a few seconds, it has failed.

I also remember another Air Disasters episode that focused on Avianca Flight 52.  In January of 1990, the plane, a Boeing 707 carrying 158 people, crashed on approach to Kennedy Airport in New York after running out of fuel, killing 73 people.  There were numerous communication issues during the flight.  Had any one of them been addressed, chances are the disaster never would have occurred.

How often have you been involved in some kind of activity where things were miscommunicated?  How well did those activities go?  I’m guessing that they didn’t go well.  How often have they happened when deadlines were approaching?  What was the mood of your organization?  I’ll guess that it was likely one of high stress and low morale.  And during that time, how smoothly did things go?  Probably not very.  I’ll bet that plenty of mistakes were made.

I’m painting this picture within a business environment.  Imagine what these conditions are like when people’s lives are at stake.

The number of disasters that have occurred from poor communication are countless; entire studies have been dedicated to the subject.  Indeed, numerous solutions and subcategories related to miscommunication have been devised.  The airline industry developed the process of crew resource management.  Extensive research has been done on the phenomenon known as groupthinkEven simple measures such as checklists have been studied and implemented.

The moral of the story: good communication, including documentation, is critical. The consequences of it can have adverse effects. At best, bad communication can disrupt your business. At worst, it can cost lives.

Rethinking my resume

I learned something new today. But first, here’s a little background behind it.

Let me start by saying that I resent that job searches these days are performed much more by machines than humans. During times when I’m employed, I get irritated by emails resulting from bots that do keyword searches on my resume and constantly spam me with job inquiries for which I have no interest. Likewise, I also make no secret that I hate spam recruiters.

That said, now that I’m not currently employed and I am job hunting, as much as I hate robotic resume scans (and believe me, I still do), it’s the nature of the beast. If I want to get my resume seen by the right people, I need to be able to play the game.

Whenever I’ve updated my resume, I’ve always written it thinking that a human will look at it. These days, I need to design it with the mindset that a machine will look at it.

I was struck with that realization today. One of my networking contacts connected me with a career counselor. We spoke for about fifteen minutes over the phone this afternoon. He encouraged me to send him my resume for a review. I sent it to him, feeling confident that it would be well-received. But when he replied back, he hit me with a dose of reality.

First, he told me that my resume was not ATS (applicant tracking system) compliant (a brand-new term for me). He gave me some tips for redesigning it. Additionally, I searched Google for ATS compliant Word templates, and found this site, which includes a link to free templates. As soon as I find one I like, I intend to use it to redo my resume.

Additionally, I’ve noticed that a lot of online applications ask me to upload my resume, and when I do, it parses it into their system. And more often than not, it does not parse it correctly, which frustrates me. It did not occur to me that redesigning my resume not only makes it better to parse, it also makes it easier for potential employers to find. This may have been sabotaging my job search, and I wasn’t even aware of it.

Second, he also informed me that I had overused the word “professional” — something else that had escaped my attention. It’s the equivalent of saying “um” when you’re doing a presentation — you’re not aware you’re doing it (and I probably do when I do my SQL Saturday presentations) until someone else points it out.

Little pieces of advice like this will help my job search — and hopefully, I just improved yours, too. I’ve practically made a career out of adapting to my environment, and I realized today that that includes my job search. No, I still don’t like that my resume is searched by machine. But that’s the nature of the game these days, and if I want to succeed, I have to play it, whether I like it or not.

NY subway map: Designing out of the box

I came across this link on the New York Times website that talks about how the current New York City subway map was designed. I found it to be fascinating. It was a neat article about how the design came about, and how thinking out-of-the-box resulted in ideas that made it better.

Out of curiosity, I looked for previous iterations of the NY subway map before it was overhauled starting in 1979. I came across this map from 1978 on NYCSubway.org. Although I don’t actually live in NYC, I know it well enough to be able to get around and survive. I don’t know about you, but if I tried to use this map to get around New York City, I’d probably be totally lost. I only vaguely remember how rough NYC subways were at that time (for some people, that bad reputation endures to this day), but it wouldn’t have surprised me if this map contributed to subway rider angst.

A number of things struck me as I went through the Times‘ interactive article.

  • Designing out of the box: Some of the design techniques included, among other things, designing lines by riding the subway with eyes closed and sketching how they “felt,” eschewing “straight-line maps” used by many other subway maps to reduce confusion, and combining parallel routes into trunk lines.

    I think it goes to show how much can be accomplished with unconventional thinking.

    Much of this out-of-the-box thinking emphasizes a concept that I espouse as a technical communicator, which is…
  • Less is more: As I’ve said time and again, reading is work. If a document needs to be understood within seconds, and it takes more than a few seconds to comprehend a document, it has failed. Innovations, such as the aforementioned trunk lines, strategically using varying colors and fonts, and eliminating superfluous landmarks, contributed to making the map easier to follow.
  • Documenting history: I also found the interactive article to be a neat history lesson about the NY transit system, map design, and New York history in general.

Any time that I take a trip down to the City, I take the NYC subway map for granted. I now have a greater appreciation of it, and I’ll probably be thinking about it the next time I hop a NYC subway.

And for those of you who are planning a trip to New York City, hopefully, this makes your planning somewhat easier!

A picture is worth (writing) a thousand words

On a recent project in which I was documenting an application, I found myself hitting yet another case of technical writer’s block. I sat in front of the screen, staring at the application — sometimes, for hours — and came to the realization that all I was doing was blankly staring at the screen. I tried different techniques to stir up ideas as to how to tackle writing the documentation, but no matter what I tried, the words just wouldn’t come. Even just trying to figure out a document structure — never mind actually trying to describe the application — was proving to be elusive.

It was at that point where I decided to give up on trying to write a description of the application functions and turned my attention to grabbing screen captures. I went through the application’s menu structure, built a document heading hierarchy based on it, and started working on the application images I’d just captured. I took the time to clean up the images, including altering them to eliminate any client or user data (replacing them with “dummy” data), and formatting them for my document. Once I was satisfied with the result, I inserted it into the document, proceeded to the next screen capture, and repeated the process.

A funny thing happened during this process. First, I found that my document was expanding in content. Granted, it was mostly graphics, but it was, nonetheless, content. Second, I’m finding it easier to come up with ideas for descriptions and text content. Third, I’m no longer blankly staring at my screen; I’m finding that I’m actually productive. Finally, I’m finding myself having fun with the process!

This is not the first time that I’ve performed this process while writing a document. Indeed, I’ve often worked on documents in which I found myself in a writing rut, shifted gears to work on graphics, and discovered the spark that I needed to write the text.

It’s an age-old saying that “a picture is worth a thousand words.” Most often, this phrase is geared toward the perspective of the reader. However, what is not as appreciated is that this cliché is applicable to the document developer as well. If ever you find yourself in a writing rut, try working on the graphics. It might just be enough to spark ideas and get you out of the rut.

Don’t tell me how to build the clock! Just tell me what time it is!

This article’s title comes from something that a former manager used to tell me all the time — often enough that he seemed very fond of saying it. Nevertheless, it’s an important message. This is not the first time I’ve written about this issue, but it’s something that occurs all too frequently. It is a problem in technical and business communication, and the issue is something that bears repeating.

I was reminded of this during our daily status update meeting this morning. The gist of this regularly scheduled meeting is that everyone has a short time — usually no more than a minute, if that — to provide a brief update of what they have going on. The key word here is brief.

One person proceeded to go into detail about some of the projects he had going (he has a tendency to do so). He’s been pretty good about keeping his updates short and to the point, but he wasn’t always like that. It took several long meetings and complaints to the manager to get him to tone it down.

For whatever reason, this morning, he reverted back to form. He started getting into details about his projects that, while important for the projects themselves, were unnecessary for status updates. It got to the point that I stopped listening to what he was saying and pretty much just zoned him out. I don’t know how long he took, but I’ll guess that he took three times longer than anyone else. Or at least it seemed that way.

This is something that everyone does (yes, I admit to doing it, too — ironically, even this very article may be too long). And it is a big problem in communication.

A part of the issue stems from human nature. We all have a limited attention span. The length of that attention span varies, but for the purposes of this discussion, let’s assume that it’s short — say, no more than a minute (sometimes, that might even be too long). If we’re communicating something, we need to make sure that it’s short and simple — and it had damn well better be efficient.

This is why people in roles such as technical, business, UX/UI, media, and marketing communication have jobs. They are in the business of taking large amounts of information and boiling it down into a format that most people can understand.

Whenever I’m writing a user or step-by-step guide, I follow a general rule of thumb: if an instruction cannot be understood within a few seconds, it has failed. That’s when I go back and rewrite the instruction.

Most of the time, people don’t want — or don’t need — or don’t care about — details. Unfortunately, too many people trying to communicate ideas don’t understand this (and worse, they often don’t care). As a result, horrible documentation (or, in some cases, absence of) is pervasive.

Too many people don’t understand that reading is work. It takes effort to read and comprehend documentation. One of my big pet peeves is any time someone tells me, “it’s right there in the documentation,” yet when I look at it, the information I need is buried someplace where I have to fight through the noise of other irrelevant text to find it.

This issue is the basic tenet of my presentation about talking the language of technology. People don’t want detail. They just want the information they need. If they need more information, they’ll look for it.

Good communication makes it easy for a recipient to quickly get whatever information (s)he needs. Don’t make someone have to work to understand communication. Don’t tell someone how to build a clock. Just say what time it is.

For every action, you need a reaction

I came across yet another example of bad interface design this morning.

After I logged into my computer, a pop-up window appeared. It was my Docker application, telling me that an update was available and ready to install. Okay, I said to myself, and clicked the button to proceed.

Except… nothing happened.

I clicked it again. And again. And again. I mashed the mouse button. Nothing. I decided there was a problem with the interface, went on with my work, and forgot all about it. At one point, I saw a Docker window appear, saying updates were being applied. Okay. Again, I went back to what I was doing.

I didn’t think anything of it — until I looked at my taskbar several minutes later. All along the taskbar were several new — and identical — icons that I hadn’t seen before, roughly one for each time that I had hit the mouse button. When I clicked each icon, I was greeted with a window that said “installation failed.” Well, almost all. The second-to-last one I clicked said, “installation succeeded.”

Yet another example of horrible design rears its ugly head.

As an application end user, if I click something where it says “click here,” I expect — and demand — that it does something. It doesn’t matter what it is. Granted, I would prefer that it performs the action that I expect when I click it, but even if all it does is change the mouse pointer, display an “in progress” icon, or display an error message, I expect some kind of response that indicates that my action did something.

An action that results in nothing is a huge pet peeve of mine, and, in my opinion, is extremely horrible design. A click that does nothing tells me that the application is doing exactly that: nothing. Having an action with no response is not only annoying, it can be potentially dangerous. What if — hypothetically — clicking a button resulted in lost data, but there was no indication as such?

A reaction is a form of feedback. If I click a button, a reaction — even if all it is is an in-progress icon — tells me that the application is doing something. If I click a button, and it does nothing, then I expect the application is doing nothing. An action without any reaction results in frustration on the part of the end user, and potentially dangerous side effects if the application performs an action that the user doesn’t expect.

If this is how you design your UX, then you need to rethink your design. When it comes to interfaces, every action must have a reaction.