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.

Advertisements

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.

Don’t like reading terms and conditions? It’s not just you

During my lunch break, I came across this article in the New York Times. It talks about privacy policies for a number of companies — and the vast majority of them are nearly incomprehensible. According to the metrics in the article, comprehending privacy policies requires a minimum of a college degree — and even then, they may not be understandable. As mentioned in the article, the policies were not written to inform the public (read: you) as much as to protect the company. It brought to mind a research article that I read in grad school. It had to do with legal documents, the language of legalese, and how it was nearly incomprehensible. I don’t remember the specifics of it (grad school was a long time ago), but the gist of it was that these documents were purposely written that way in order that any ambiguous language was eliminated and things were made clear. And when I say “clear,” I mean that definitions were defined and unequivocal. Readable, however, is another story.

I could get into data security and how privacy policies exist for your protection, but that’s not why I’m writing this article. (I’ll leave it to people like Steve Jones to address that aspect.) Rather, I’m writing this because I’m a technical writer (among other things), and document readability is a big deal to me. Indeed, this is a major point of emphasis in both of my presentations about talking to non-techies and documentation, and is one of my biggest document pet peeves.

Readability is a huge deal in documentation. Legalese may be a big deal for making sure definitions are unambiguous, but it is inappropriate for something like, say, step-by-step instructions. When I’m writing instructions, I follow a rule of thumb where if an instruction takes longer than a few seconds for the reader to understand, the instruction has failed. I continue to be appalled by technologists who insist on writing every little bit of detail in their instructions and end up with a “step by step” that is one big black body of text. And I’m continually annoyed when that person says, “it’s right there in the documentation,” but the information you seek is buried somewhere in the middle of the 100+ lines of text that (s)he wrote that takes about an hour to read.

When I talk about documentation and instructing people, one tenet that I actively push is the KISS principle. But even this is not easy to do, and people take that for granted. Indeed, this is what technical writers, UX/UI developers, and instructors do; they are in the business of taking incomprehensible technical language and translating it for people to understand.

Do privacy policies really need to be that incomprehensible? I don’t have an answer to that right now; that might be another article for another time. But what I do know is, if their intent is to inform people, especially the general public, they fail miserably.

The symbiotic relationship between documentation and application development

One of my current projects involves documenting processes for an application that are still under development. As such, much of what I write may change, depending on how processes are changed during the course of development.

At one point, I tested one of the processes so I could determine functionality and document it. In doing so, the process came back with an error message that I wasn’t expecting and didn’t have any user-friendly information, other than a cryptic error code. I contacted one of the developers working on the application and told him what I found. I gave him the error codes I experienced and steps I took to get them. He told me, “you’re coming across bugs that we didn’t even know we had.”

It occurred to me that I was doing more than just documenting the application. I was also acting as a beta tester.

One aspect about writing technical documentation is learning about what you’re writing. In order to write about a process, you need to understand how it works. If you’re documenting an application, the best thing you can do is run the application in a safe environment (such as development or a sandbox), learn how it works, and use it to document steps and capture screens. In doing so, you come across application bugs and even come up with ideas to make the application even better.

I’ve long argued as to the criticality of documentation. It records important information and serves as a reference. However, until this point, it didn’t occur to me that the document development process could have a symbiotic relationship with application development. To me, this adds further fuel to the argument that documentation is critical and required.

Don’t forget to edit your system messages

One of my current work projects is a administrative guide for our application. After a recent status meeting, one of the developers sent me a list of validation error messages that might appear during data imports. I was asked to make sure the validation messages were included with the documentation.

While going through the validation messages, I noticed that they were filled with grammatical, capitalization, and spelling errors. I asked the developer if he wanted me to edit the messages, to which he responded, “yes, please!”

People don’t think about checking output messages for correctness during application development. It is often a part of applications that is overlooked. For what it’s worth, I, myself, didn’t even think about it until I was asked about these validations. Nevertheless, reviewing and editing output messages is probably a pretty good idea.

For one thing, and I’ve stated this before, good writing reflects upon your organization. Well-written documentation can be indicative that a company cares enough about their product and their reputation that they make the effort to produce quality documentation as well. Well-written system messages indicate that you care enough to address even the little things.

Well-written error messages can also ensure better application usage and UX. A good output message can direct an end user to properly use the application or make any needed adjustments. Messages that are confusing, misleading, badly-written, or ambiguous could potentially result in things like application misuse, corrupted data, accidental security breaches, and user frustration.

Ensure your application development review and testing also includes a review of your system messages. It may be a small thing, but it could potentially address a number of issues. As someone once said, it’s the little things that count.

The relationship between technical writing and application UI

During a recent work meeting, we were discussing an online Wiki-like internal document that I’d written. There was mention of a line that needed to be included. I mentioned that I’d need to figure out how to word it, and where it should go — pretty typical work when editing any technical document.

For some reason, during that conversation, I started thinking about how locating that — and other pieces within the document — affected its readability. That thought made me think about interfaces — how certain UI/UX pieces on an application can influence how an end user views and uses it.

That’s when it occurred to me: there is a direct correlation between technical writing and UI design.

It should be an obvious idea, but for me, it was a revelation. There isn’t a lot of difference between how a document is laid out and how a user interface is arranged. Many design principles between them are the same. The user’s eye path follows the design. How he or she reads the document or uses the application is affected by how the document is laid out or how the UI is designed.

I’ve written before about how design is important. I’ve also written about documentation issues (time and again). Like everything else, technical writing and UI design is a skill. A good technical document and a good user interface both require planning — as it turns out, the same kind of planning — to execute properly.