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.

When does “making it pretty” become “bad design”?

Within the past week, I came across a couple of examples where designers, in an attempt to make something “aesthetically pleasing” ended up creating a bad design.

Image result for Sloan EBV-304-A SOLIS Water Closet Electronic Single Button
In the dimly-lit stall, I couldn’t see the graphic to flush.

The first example, strangely enough, came from a public toilet (don’t worry, I won’t go TMI on you). The flush mechanism was similar to what you see here. It was dark in the toilet stall, so I couldn’t see the little graphic of the finger pressing the button (that you can see clearly in this picture). It looked like one of those auto-flush mechanisms, so I expected it to flush when I stood up. It didn’t. I tried pressing the top of the mechanism and waving my hand in front of it. No dice. It wasn’t until I found the little button along the front edge that I finally got the thing to work. I don’t know how long it took me to figure that out, but I’ll estimate that it took me somewhere between fifteen and thirty seconds — far longer than it should’ve taken me to figure out how to flush a toilet.

How do I get water out of this thing?

The second example happened recently at a friend’s house. The photo you see here is the ice and water dispenser on his refrigerator. I put my water bottle underneath, and naturally, ice came out of it. I then tried to get water. How do I do that? I looked for a button to toggle between ice and water, but couldn’t find one. My friend told me to press the button above the ice dispenser. I pressed the top panel with my finger, expecting my bottle to fill with water. Much to my surprise (and my chagrin), water came out not from under the button and into my bottle, but rather above the panel I was pressing, splashing water onto my hand. Apparently, what I was supposed to do was press the upper panel with my water bottle so that it would dispense into my bottle.

To the people who designed these things: how was I supposed to know that?!?

These are more examples of what I consider to be bad design. It seems like artisans are making more of an effort to make products visually appealing. But in their efforts to make things “pretty,” they’re ignoring making them functional.

Years ago, I remember seeing signs in a local park — “park here,” “keep off the grass,” etc. (I tried to find pictures of them, but have been unsuccessful.) Whomever made the signs went through great efforts to make them look pretty — the person used wood and tree-themed graphics to dress them up and make them look “rustic.” However, the person concentrated so much on making the signs “pretty” that (s)he completely ignored making them readable! The signs were impossible to read. You could not tell what they said. Thankfully, the signs have long since been replaced, and personally, I think the sign-maker should have been fired.

And if you think bad design isn’t a big deal, let me point out that bad interface design has been a factor in some fatal plane crashes, as well as some other major disasters.

People might argue that, “well, of course they’re functional! You just have to know how they work!” Therein lies the rub: you have to know how they work. Making something functional isn’t just a matter of making something that works; it needs to be obvious as to how it works! This is one of my major pet peeves when it comes to design. As someone once said, good design is like a joke. If you have to explain it, it isn’t any good.

Playing in the sandbox is important for documentation

While working on a user guide, I realized that I had administrative rights to the application I was trying to document. That was all well and good, except that I was trying to write a non-admin user guide, and I needed to know how someone who didn’t have admin rights saw the application. Fortunately, one of my co-workers sent me an application URL and a testing user login I could use that simulated exactly what I needed.

That brings me to today’s article. Many application development environments make use of a sandbox, or some other development, environment where a developer can play to their heart’s content — that is, some place where someone trying to test or develop applications can play with the app without having to worry about breaking anything important. That same testing environment is just as important for a technical writer.

Much of my work as a technical writer involves putting myself in an end user’s shoes. I’ll often go through an interface and document the steps a user might use, what a user might see on the screen, and the effects of certain buttons and links. One of my most frequent questions when I work on documenting an application is, “what happens when I click this?” After I do so, hopefully my next response isn’t “oh crap!”

This is why a tech writer needs access to a testing environment. Like application developers who need to test within a safe environment, a person documenting the system needs to be able to document the system and be able to do so knowing that (s)he won’t adversely affect the application by playing with the system.

I wrote previously that a tech writer can help an application developer, and vice versa. Indeed, the tech writer can function as an in-house QA analyst. In order to write good documentation, the writer needs a realistic environment in which (s)he experiences what an end user might see. Having a sandbox environment in which a writer can “play” provides exactly that type of environment. As an added bonus, not only does this allow the tech writer to produce better documentation, it allows that person to provide feedback regarding the application, which ultimately results in a better application.

When you make it hard for your customers to respond

This morning, I had an issue with my LinkedIn account. I was trying to reply to a message, and I kept getting “Send failed.” That was all I got — there were no error codes, additional information, or symptoms. I poked around LinkedIn’s Help section, and came across this page for dealing with messaging problems. I didn’t go as far as to clear my cache, but I did log out and back in, and I tried it in a different browser, all to no avail. In the middle of contacting LinkedIn’s support, the problem mysteriously “fixed itself.” If you work in tech, I don’t have to tell you how frustrating it is for an issue to mysteriously “fix itself.”

However, the issue I had, in and of itself, is not why I’m writing this article. When I heard back from LinkedIn, I got a message saying “go to this page” (the one I’d already found) and use that to troubleshoot. In response, it displayed the interface you see above. As you can see, they only gave me two options: “yes, I’m good,” and “no, I still need help.” The problem was, my response was, neither. No, I didn’t need help at that point, but I also wasn’t completely good, either. I wanted to inform them what had happened in case they wanted to investigate it further. But they did not give me that option. Between those two options, I clicked “yes, I’m good,” which immediately closed the case; I had absolutely no recourse to add more to it. I looked around for ways to send feedback, but I did not find any good way to do it. Replying to the email resulted in a response saying “you responded to an unmonitored mailbox.” The more I looked for a feedback mechanism, the more frustrated I got. The issue quickly went from “I’m reporting a technical issue” to “you guys need to fix your UI/UX.”

I’ve written before about how critical it is to get feedback, and how design can be a big deal. As much as I like LinkedIn as a business networking tool, I felt that LinkedIn fell short on both of these facets.

Let me start with the UX/UI design. I strongly felt that only those two options, especially if answering “yes” automatically closed the case, was a very poor design. As many people will tell you, the answer often isn’t simply “yes” or “no.” (One of the long-standing jokes among DBAs is that the standard DBA answer is, “it depends.”) And even after I clicked one of those buttons (in this case, I clicked “yes”), the interface was confusing. I was brought to a page that said “click to enter more information” (or something like that). The problem was, click where? None of the “links” allowed me to enter anything else, and there was no clearly logical eye path for me to follow. I had no idea what I was supposed to do once I got to that page. I kept clicking different links, trying to leave feedback. By the time I found a link, I wasn’t even sure that I was replying to my original query. I had no idea to what — or even where — I was responding.

I’ve said time and again that if you’re a technical writer — or a UX/UI developer — you don’t want to make your reader or end user work. Reading is work. Making your end user work is a sign of poor design.

Second, this experience made me question just how seriously LinkedIn takes feedback. True, nobody wants to hear bad feedback. I know I sure don’t. But if you want to improve, you need to know what it is you need to improve. How am I supposed to improve something when I don’t know what it is that I’m doing wrong? Not including a channel for feedback — or making it difficult to do so, as I allude to above — is doing a disservice to your organization and to your clients.

Good communication between you and your client is important. Not only does it help your client, it helps you improve your organization, and it builds trust between you and your customers. Making it difficult for your customers to communicate alienates them — and ends up hurting your business in the long run.