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.

Advertisement

When is “good enough” good enough?

If there’s one thing that I struggle with (and I’ll bet the house that I am not alone), it’s determining when something I’m working on is at a point where it’s “good enough for government work” (as the saying goes). Whenever I work on anything — whether it’s a work task or an extracurricular project — I always want to put in my best effort. As my personal mantra often goes, always put in your best effort — I don’t care if you clean toilets for a living. Ideally, my goal is perfection every time.

The problem is, perfection is an unrealistic standard. I’ve written about this before, and I still believe it. We’re human, after all, and a big part of being human is that we are rarely, if ever, perfect. I’ve often said that perfection as a goal is okay, but perfection as a standard is unacceptable. Sure, every once in a while, a bowler will bowl a 300 game, or a baseball pitcher will pitch a perfect game, but neither can be expected to do so every time out. Setting perfection as a standard is impossible, and anyone who sets perfection as a standard really needs to rethink their priorities.

For me, this is a constant struggle. I want to do the best job possible every time. However, there are often factors that work against me: deadlines, schedules, task management, work load, lack of knowledge or experience, fatigue, and so on. Additionally, my work often coincides with something else; a teammate is often counting on my part in order for him or her to proceed with their task. We don’t work in a vacuum; we’re often part of a team, and we need to work together. This is true even if you’re an individual contractor; your customer often expects to see results.

So how do you measure when something is “good enough?” This is often subjective and hard to answer, but I’ll take a crack at it.

I’ll use one of my favorite (and oft used) examples: baseball. As I mentioned above, a pitcher isn’t perfect every time. He’ll often give up a few hits and walks. He might even give up home runs on occasion. But was his performance good enough for his team to win? A play-by-play announcer will sometimes say, “he didn’t have his best stuff tonight, but he kept his team in the game, and it was good enough to get his team the win.”

So with that, I’ll often use measures like these: did my team get the win? Did my teammate (or customer) get what (s)he needed from me in order to do what they needed? Did my efforts meet the requirements? Did my teammate accept my results? Did my efforts get the job done? And, most importantly to me, did I give it my best effort, given any impediments (time constraints, fatigue, degree of difficulty, experience — or lack of — with the task, etc.) that might be in my way?

If I’m able to answer yes to questions like these, then in all likelihood, I can say yes, my efforts were good enough.

Tools are not documentation

I’ve been running into an issue that I’m not sure how to get around — mostly because it’s somewhat political, and I don’t like to play the political game — and it’s frustrating. Because the issue is work-related, I am intentionally skimping on the details, but I’ll give you the gist of what I’m dealing with.

I’m trying to document a procedure for engineers to obtain temporary administrative access. In order to do so, the engineer needs to fill out a form to request the access. I’m trying to write about how to find and complete the form.

I spoke to the form’s owner (this is where the political part comes in). I explained what I was doing. However, he keeps insisting: “it doesn’t have to be documented, because the form is the documentation.”

He showed me a screen shot of text on the form that explains how the particular request works. The text made a lot of sense, and it would have been ideal to fulfill at least part (if not most) of my needs. I decided that I would create a reference to it. So I looked around the form for it… and could not find it anywhere.

He finally told me that “you had to click a specific button on the form to view the text.”

How was I (or anyone) supposed to know that? (Answer: you couldn’t.) Just by that alone, he contradicted his statement that the form is documentation. (It isn’t.) I wrote about this earlier; he is under the (potentially) dangerous assumption that everything on it is obvious. (Disclosure: the form in question is exactly the same one that I wrote about in the previous article.) He keeps insisting that the form is the documentation. But in spite of that, he gets frustrated that his department continually fields questions about how to do things that could be handled by the form — if it was properly documented. if the form actually was the documentation, it violates a major principle of technical writing: documentation is like a joke. If you have to explain it, it doesn’t work.

Now, I will mention that I like the guy. He’s personable and pleasant, and I do enjoy talking to him. But he is stubbornly clinging to his belief that his tool is the documentation. I try to explain to him that it isn’t, but he won’t have it. And I have to admit that I’m not sure how to handle it.

I pinged the project manager to get her thoughts on how to handle this (I’m still waiting to hear back from her as I write this). She has a better rapport with this person than I do, so she might have some insight as to how to handle this. Nevertheless, I think this is another case where you need to keep an open mind to improve a product, and realize that tools are not necessarily obvious in how to use them. Even a hammer can do more than just drive a nail.

#DataSaturdays #13 Minnesota — I’m speaking! #SQLSaturday

My speaker train continues to roll! I was informed yesterday that I’ve been selected to speak at Data Saturday #13, Minnesota on October 16!

I’ll be doing my presentation about how to speak the language of technology to those who don’t understand it.

Again, this is a virtual event; I will not be traveling to Minnesota. Use the link above to register for this free online event. Hope to see you there!

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.

September CASSUG Monthly Meeting #Networking @CASSUG_Albany

Our September meeting will again be online. NOTE: you MUST RSVP to this Meetup at https://www.meetup.com/Capital-Area-SQL-Server-User-Group/events/280614945/ to view the Zoom URL!

Our September speaker is Kathi Kellenberger!

Topic: What is DevOps and Why Should DBAs Care?

Our online meeting schedule is as follows:

• 6:00: General chat, discussion, and announcements
• 6:30: Presentation

We usually wrap up between 7:30 PM and 8:00 PM.

Please RSVP to this Meetup using the link above, then use the online event URL to join (note: you MUST RSVP for the URL to be visible). We will send out a meeting password as we get closer to the event.

Thanks to our sponsor, Datto, for making this event possible!