Dashboard design = UX/UI

This is another article that was borne from my experience at SQL Saturday #814.

When I went to my room to get ready for my first presentation of the day, I walked in on the tail end of Kevin Feasel‘s presentation about dashboard visualization techniques.  I caught about the last ten minutes of his session.

And from those ten minutes, I regret not having sat through his session.

Kevin’s presentation focused on dashboard layout and design.  In the short time in which I saw his last few slides, he showed off his impressions of a badly-designed dashboard, and talked about what not to do.  In other words, he was talking about UX/UI — a subject near and dear to my heart.  It reminded me of the article I wrote about poor design a while back.

I wish I had read through the presentation schedule more clearly.  That was definitely a presentation that I would have liked to have seen.  In my defense, during that time slot, I was sitting in the speaker’s room getting ready to do my own presentation.  But I would have gladly spent that time sitting through a presentation that interests me — and this one definitely qualified.

I’ve attended a number of SQL Saturdays, and I’ve crossed paths with Kevin a few times.  If we’re both attending a SQL Saturday, and Kevin is doing this presentation again, I’ll make sure that I’m there.  I don’t want to miss it a second time.

Advertisements

Technical writer’s block

“What no wife of a writer can ever understand is that a writer is working when he’s staring out of the window.”
— Burton Rascoe

“Waiting for the break of day; searching for something to say; flashing lights against the sky; giving up, I close my eyes…”
— Chicago, “25 or 6 to 4”

Those of you who write creatively — whether it’s a book, an article, music, etc. — have all experienced writer’s block.  Even if you don’t write, maybe you’ve experienced it in some form.  Maybe you were assigned a writing project in school.  Maybe you’re trying to come up with ideas for a party or how to celebrate a co-worker’s special occasion.  It even comes up when my wife and I discuss what to do about dinner (“What do you want?”  “I don’t know!  What do you want?”).  No matter what form it takes, the moment when your brain fails to come up with any ideas (sometimes called a “brain cramp”) happens to all of us at some time or another and more often than we’ll admit.  As much as I’d like to post a ‘blog article each day, there’s a reason why I don’t.  A lot of it is because I don’t necessarily write articles professionally and I don’t always have the time to do it, but an equal part of the reason is not being able to think of things to write about.

For this article, I’d like to talk about technical writer’s block — yes, there is such a thing, and it happens more often than you think.  (I don’t know if that’s a widespread term; for all I know, I might have just coined a new phrase.)  However, it differs from other forms of writer’s block in that a technical writer already has a subject about which he or she is writing.  In this case, it’s not a matter of what you’re writing about; it’s more a question of how to write about it.  I can’t tell you how many times I’ve stared at a computer screen for (at least) twenty minutes, only to realize that I spent those twenty minutes just blankly staring at the screen.

Those of you who are technical writers, let’s see a show of hands: how many of you have been given, say, a step-by-step instruction to write about, but have agonized about how to put it together?  Should you list them as numbered instructions?  Should you keep it to simple bullet points?  Is it better to put items into a table and write out definitions for the terms?  People who know nothing about technical writing don’t understand the struggle; they think it’s just a matter of throwing it together and making numbered points from them.  What they don’t realize is that it is not that simple.

For one thing, writing instructions isn’t that much different than writing code.  Both involve logic.  But let’s say you have an instruction to “push the red button” but only if you performed another step or are faced with a specific circumstance.  In structured programming, this would probably take the form of an IF-THEN or CASE statement.  But when you’re writing a document, situational instructions aren’t as clear cut.  There is no standardized method for writing an if-then statement in a step-by-step document.  I’ve seen this situation addressed in different ways; in one job where I was employed as a full-time technical writer, the group include a style with their template that included a small table for these situations: do this for one situation, do that for another.  I’ve seen others where a step is accompanied by a note: “this only applies to (whatever).”  Since there is no standard way to address this, it likely makes writing instructions more, not less, difficult than writing code.

Your audience likely plays a role.  I’ve espoused time and again that you need to know the audience for which you’re writing.  In my first successful technical writing project, I made sure that I put myself in the reader’s shoes, empathizing with the reader.  “How do I write this so I can see what I need to do?”  That strategy made things very clear, and I was able to write a good document.  Unfortunately, tech writers don’t always have this luxury; sometimes, either the type of audience is unclear, or the writer is writing for multiple audiences.  If you know your audience, it gives you an idea as to how to structure and write your document.

As I wrote earlier, design matters.  Of all my experiences with technical writer’s block, this is probably the one with which I struggle the most.  How should things be laid out that would most help the reader?  Where should things be placed so that they best direct an end user?  A document’s design often makes or breaks a successful document.

I just wrote about some of the issues I face.  How to resolve them is not as clear cut, and I don’t have as many answers as to how to address them (that might be worth its own article).  Here are a few ways that I’ve dealt with technical writer’s block.

  • Ask questions.  Clarification helps answer some of the issues with which I have to deal.
  • Get help.  Another set of eyes can sometimes break the impasse.
  • Work on something else.  Working on another task can sometimes spur ideas.
  • Walk away.  Sometimes, you just need to take a break.

I’m sure there are others ways as well that haven’t occurred to me.  How do you deal with technical writer’s block?  Feel free to respond in the comments.

Keeping it simple: it can get complicated

“Everything should be made as simple as possible, but not simpler.”
— Albert Einstein

“If you can’t explain it to a six year old, you don’t understand it yourself.”
— also supposedly by Albert Einstein

If you’re on Facebook, I’m sure that you’ve seen the memes that go something like this: “tell a sad/scary/happy (whatever) story using only four words.”  It’s hard to do, isn’t it?

Welcome to the world of technical communication.  One communication tenet that I constantly preach — and you’ll hear me talk about this time and again in my presentations — is the KISS principle: “Keep It Simple, Stupid.”  Ask anyone involved with technical writing, documentation, or professional communication, and I’ll bet that most, if not all, of them will mention the KISS principle in some way, shape, or form (maybe not in those exact words, but you get the idea).  The goal of communication, after all, is to transmit information from a sender to a receiver.  If the message being conveyed is easy enough for the receiver to understand, so much the better.

However, here’s the irony: making things simple is difficult!

How often have you been asked to write something for knowledge transfer, and ended up with something that was nearly incomprehensible?  (Don’t be afraid to admit it; hey, I’ve done that, too!)  Whenever we’re tasked with writing documentation, our tendency is to explain every little tidbit of knowledge that’s in our head.  When that happens, we end up writing a huge paragraph of black text that nobody — and I mean, NOBODY, including yourself — wants to read!  That is not conveying information; that is obfuscation.

So how do we go about making things simpler?  For starters, I discuss some ideas in my previous articles about designdocument frustration, using examples, and talking to non-technical people.  I won’t rehash them here; I’ll leave it to you to go back to read those articles.

Additionally, here are some more thoughts that might be helpful.

  • Include only information necessary for the task at hand.  Avoid the tendency to include every last detail.  As a former manager was once fond of telling me, “don’t tell me how to build the clock; just tell me what time it is!”  I also remember a time back when my father was first learning about PCs.  He kept asking me questions about how the CPU and memory worked.  I finally said in frustration, “you don’t have to know how an internal combustion engine works in order to drive a car!”
  • Put yourself in the reader’s shoes.  When I wrote one of my very first technical documents, I said to myself, “okay, let’s say I’m the night operator who needs to use this document.  What do I want to see that would help me?”  That mindset resulted in a very successful document.  Reader empathy goes a long way.
  • I’ve said it before, and it’s an old but true saying: a picture is worth a thousand words.  A good illustration can convey a concept that’s difficult to do in words.
  • Avoid using long (or multiple) words when a simple (or single) word will do.  I think this is self-explanatory.
  • Voice matters.  Below are two sentences, one using active voice and one using passive voice.  Question: which one is easier to read?  Advice: try sticking to active voice.
    • Active: “John mowed the lawn.”
    • Passive: “The lawn was mowed by John.”
  • Formatting is a big deal.  Check out documents that you found easy to follow.  Pay particular attention to paragraph length, whitespace, headings, and so on.

People — myself included — say that the easier you can make things, the better.  The fact is, we humans only have a limited attention span, and we neither have the time nor the patience to comprehend complex information.  Simplifying things helps — but it’s also hard to do.  If you ever believe you know a lot about a concept, try explaining it to a child — and see for yourself how easy it is.

Document maintenance is critical

I had two appointments this past week.  The first was one for my car to get my oil change and to make sure everything was in good working order (it was).  A couple of days later, I had a dentist appointment.  It was a routine cleaning (I also had a procedure done — one that I’d been putting off for a while).  While the two appointments were for different reasons, they both served the same purpose: to perform maintenance.

Just about everything, especially anything mechanical, is going to break down over time.  Maintenance ensures that things remain in good working order.  But when we think about maintenance, we usually think about car repair, roadwork, furnaces, and water heaters.

I’m sure many people in tech industries consider periodic hardware and software maintenance.  Hardware can break down.  Drives crash occasionally.  CPUs are upgraded to keep pace with emerging technology and to support software.  Speaking of software, bug fixes are constantly made.  There’s also the matter of security; virus software definitions are constantly updated, and operating system patches are distributed to ensure computers are safe.

But here’s another question: when was the last time you maintained your documentation?  Does your documentation, which was written for, say, Version 1.0, reflect what is in Version 2.0?

The trouble with documentation, even the best-written documentation, is that it can become obsolete over time.  Processes and systems change.  Interfaces are redesigned.  Steps become more efficient, or in some cases, even eliminated.  Change happens.  It’s one of the sure things in life.  Documentation should also change as well.  How often has your help desk received calls from frustrated customers saying things like, “your instructions say ‘press the red button,’ but there’s no red button on the interface!”

If your product changes — and it inevitably will — your instructions should change with it.  It’s important that systems are maintained.  Your documentation should be maintained as well.

My first podcast interview!

About a week ago, I received an email from Carlos Chacon of SQL Data Partners inviting me to take part in a podcast.  This was my first such request, and I jumped on the opportunity.

The podcast recording took place last night.  My topic was along the lines of “writing and communication: why it matters to data professionals.”  It was a lot of fun, and I very much enjoyed talking to Carlos and his partner, Steve.

The podcast should air sometime in March.  It will be posted on their ‘blog.  When it does, I’ll make sure that I post a link to it!

Why design matters

“A user interface is like a joke. If you have to explain it, it’s not that good.”
— unknown

There are two elevators in the building where I work, including one that doubles as a freight elevator — it has front and back doors for access.  This particular elevator has a bank of buttons shown in the photo below.  The buttons for the rear door are denoted by the “R” next to the floor number.

elevator_buttons

Here’s why these buttons frustrate me.  Quickly, tell me which open and close door buttons work for the front and rear doors!  Yeah, I can’t tell, either!  You would think that the upper buttons control the front and the lower ones control the rear, but you can’t discern that from the way it’s laid out (and I’ve found that it isn’t necessarily the case).  I have had multiple occasions where I’ve tried to hold the door open for someone rushing to catch the elevator, and ended up hitting the wrong button.

Had these buttons been properly laid out, the open and close door buttons would both been placed under each respective door button column — i.e. the open and close door buttons that control the rear door should have been placed under the buttons marked “R,” which would clearly indicate that those buttons are used for the rear door.  That would make sense, wouldn’t it?

Raise your hand if you’ve ever been frustrated by a product simply because the user interface was poorly designed.  I would expect every hand in the room to be up.

Don Norman, an academic researcher considered to be an expert in usability design, talks about this phenomenon in his book, The Design of Everyday Things (disclosure: at the time of this article, I have not read this book — yet).  One very common example involves doors.  How many times have you come across a door with a handle, leading you to think you need to pull it to open the door?  Yet when you try it, it turns out that you need to push, not pull it, to open.  It’s extremely frustrating, and it happens more often than you think — so often, in fact, that it even has a name: a Norman door.

If you don’t think good design isn’t a big deal, there have been documented cases where poorly designed interfaces resulted in a significant loss of life.  I did a Google search for “disasters resulting from bad design,” and the results were startling.

This subject is of particular interest to me, speaking as someone whose job revolves extensively around technical communication, technical writing, and front-end development.  In my line of work, design and layout are a big deal.  I have seen many examples on the job of horrible documentation and bad interfaces — and poor design was a major factor.  I mentioned in an earlier article that I came across illustrations in a company document that were completely useless.  Pictures may be worth a thousand words, but if they’re not properly used — and yes, there is a wrong way to use them — they can be worth exactly zero words.  Likewise, one of my current projects is working on how to make an internal corporate social network work for my department.  I’ve discovered that I have a love/hate relationship with it; while I have no problem with the concept, the execution leaves a lot to be desired.  One of the most basic questions I have with this system which it fails to answer — and which should only be answered by the interface design without having to look up instructions — is, “where am I supposed to begin?!?”

Interfaces exist in just about every facet of our lives, including, but not limited to, application front-ends.  Good sensible design must be involved in creating them.  More often than not, they’re just “thrown together” without any thought as to how they should be laid out and how they are to be used.  The consequences of poor design abound.  In the best of cases, such as with Norman doors, they are just annoying.  But in the worst cases, they can have disastrous and fatal results.