I'd Rather Be Writing » drawing

Finding Time to Draw: Ben Minson at the STC Summit in Dallas, #stc10

Tom Johnson — Mon, 10 May 2010 03:57:31 +0000

Ben Minson and I attended Don Moyer‘s session on drawing for technical communicators. Don explained simple drawing techniques to illustrate concepts. I asked Ben Minson, an artist, to comment on Don’s session and evaluate whether he thinks the techniques would be useful or practical in the workplace.

Blog Sponsors

Having Fun with Snagit

Tom Johnson — Wed, 03 Jun 2009 13:53:40 +0000

This week I needed to create some visuals for a PowerPoint to illustrate concepts related to blogging. Since I have limited artistic ability (perhaps even negative artistic ability), I resorted to a stick figure person as a common theme. I spent a while trying to decide which tool to use to draw with. It turns out drawing a basic circle in Photoshop that doesn’t have a solid fill is tedious, as are other drawing functions in Photoshop. So I used my favorite little graphics program instead: Snagit.

Snagit 9 introduces a .snag format that saves every object on the screen as a movable part. Of course it’s not as powerful as Photoshop or Illustrator, but it’s a lot quicker and easier. I especially like the Add to Quick Styles feature, so that after defining a shape (for example a line of a certain color, width, and shadow) I can save it to the toolbar and access it immediately.

I also enjoy Snagit’s general ease of use. It’s the one graphics program that Jane found essential for working with images on her blog. I tweeted the other day that I wished more products would have Techsmith’s same usability, and they consequently gave me several product licenses to give away. So look for an upcoming caption contest on my blog shortly.

Here are my little stick figure drawings. You can click the images to see the full sizes.

Visibility

Purpose

The Question

Relevance

Readability

Voice

Story

Revealing Appropriately

Interaction

Regularity

Blog Sponsors

Drawing as a Tool for Thinking: The Back of the Napkin

Tom Johnson — Tue, 19 May 2009 14:08:50 +0000

Lately I’ve been reading Dan Roam’s The Back of the Napkin: Selling Ideas and Solving Problems Through Pictures. In the book, Roam asserts that drawing pictures can help you solve problems. It’s a simple but profound assertion.

You’re no doubt familiar with the same assertion with writing. Writing is a tool for thinking, a method for unlocking ideas. Writing about something helps you think about it, helps you see the problem more clearly, helps you see what you’re trying to say. Most people who write know this. It’s what teachers in writing courses tell students who dislike writing—that even if you’re not going to be a writer, writing is a worthwhile skill because it extends your critical thinking faculties.

Roam essentially says drawing provides much the same critical thinking tool.

It sounds cool, but does it really work? I decided to give it a try. Here’s the problem I was trying to solve. Next month I’m giving a five-hour WordPress workshop in Vienna (as part of the TransAlpine conference). Five hours is a long time. If I stand up there and lecture, not only will I collapse from exhaustion after three hours, everyone else will either leave or fall asleep. Also, the room won’t have Internet. How can I keep people awake and engaged?

Roam has a specific heuristic to follow when drawing. Not only should you explore the 6 W’s—the who, when, why, what, how / how many, and where—you should also look at various angles: simple versus elaborate, quality versus quantity, vision versus execution, individual versus comparison, and change versus as-is.

I decided to keep it simple and mostly focus on the first set of questions, but you can imagine how each of these angles would prompt a different inquiry. Here’s what I drew.

Drawing the problem helps you come up with solutions

As you can see, I’m not an artist, but that’s okay, Roam says, because the purpose of these drawings is to analyze and explore the problem, not to represent something aesthetically.

My chicken-scratch drawings may look unintelligible, but they did help me consider solutions and additional facets of the problem that I hadn’t previously considered. While I was drawing, here are some of the ideas I thought about.

In drawing the how, I realized (and this may be small) that I’ll need a long cord to extend to the projector if the projector is in the back of the room. I doubt the room is set up that way, but drawing it made me think about the layout of the room and what technical problems I may encounter. If I need sound, how will I orchestrate that? What problems will the 220 current from European outlets pose for my American equipment? Will I set my laptop on a table beside me or on a slanted podium?

In drawing the why, I realized that I’ll be filling the participants with enthusiasm and excitement for WordPress, but if there’s no outlet, no way of putting that enthusiasm into practice, it will be an exercise in frustration. I’ll need some practice problems for everyone to follow. To facilitate practice with WordPress offline, I’ll have to walk them through local installations of WordPress on their own computer through something like WAMP server.

In drawing the what, I decided I’ll need a workbook of some kind for the participants to follow along. The workbook will give structure to the course and provide a safety blanket for people who may feel they’re not entirely getting a concept. I already started on a WordPress Quick Reference Guide last year, so perhaps I should update it, extend it, and illustrate it with more pictures.

In drawing the how many, I realized that of the 20 to 30 people who might attend the course, the participants will likely have a variety of technical backgrounds, from people who can’t code a hyperlink to people employed as professional web designers. I need to be aware of the different skill levels and start from the ground up, assume that many will have little understanding of CSS and later move into advanced concepts.

In drawing the how many, I also realized that not everyone may be planning to use WordPress as a blogging tool, but might be looking to use it to sell products, build a chapter site, or implement it for some other purpose. I know that’s a somewhat obvious point, but I didn’t think about it until I drew forty separate audience members, each of whom looked a little different.

So you see, drawing out various scenarios, answering the who, when, what, why, where, how, and how many, did bring up some important issues and help prompt some solutions. Drawing really is a tool for thinking, a heuristic for investigating ideas.

Part of the reason drawing works, I believe, is because our visual sense is critical to the way we understand the world. It’s how we process what happens around us. As children, we instinctively draw. The urge is unstoppable. Even as bad as the pictures are, we don’t care. I can’t help but think that, unconsciously, children draw to help make sense of the world, to understand what they’re seeing and to express what they’re feeling.

Perhaps we draw less as we learn to write, but drawing does not provide the same analytical results as the written word—it’s another sense and medium. As a unique medium, the answers are often unique as well. Whatever the reason, drawing as a tool for thinking does give you another tool for solving problems. (And it’s a great excuse to doodle on paper.)

Blog Sponsors

Starting Points with Quick Reference Guides: Gathering Before Designing

Tom Johnson — Fri, 15 May 2009 03:21:54 +0000

In The Back of the Napkin, Dan Roam explains that drawing pictures can help you solve problems. He says the first rule is to “collect everything possible up front” (p.58). After collecting all your information, you then “lay it all out where you can look at it” (p. 61). By laying out all the information, you can grasp the whole of it, make connections between various parts, see the important sections, and recognize patterns.

These two rules define the starting points when creating quick reference guides. Neglect them and you run into trouble.

For example, on a recent project, I sized up the application and decided the help content would be minimal. I could fit it all on a few one-page quick reference guides spread across several roles. I didn’t even need an online help, I decided, but would author directly in my quick reference guide layouts.

I opened Adobe InDesign, created a new document, and started writing the content directly in it. It began well enough, but little by little, the application started to reveal its complexity. Edge cases, special workflows, notes and other important information began to accumulate. I manipulated the text frames and column layouts to fit the information. Needing more space, I adjusted the line spacing, the font size. Then I removed a screenshot, and another. I increased the length of the columns, and so on, trying to make it fit on one page. After some deliberation, I decided to cut entire sections that weren’t actually necessary. So I then added a screenshot back in.

The information continued to fluctuate. After some time, having modified the design several times to accommodate the content, I realized my error: I was starting at the end rather than the beginning. I needed to see all the information at a glance before designing the quick reference guide. Without a complete picture of the documentation, I couldn’t see which tasks were essential, what to include and exclude in the guide, or how it should be arranged. It became an exercise in frustration.

Trying to author your original content while worrying about design is an exercise in frustration

Returning to Roam’s point: First gather all the information. Second, lay it out on the table to see. Roam actually calls this second principle the Garage-Sale principle, because once you lay out all the information in front of you, you can then begin to see it with more clarity. You can note patterns and spot duplicate and overlapping content. You can start organizing it, throwing away extraneous information, noting gaps, and so on.

By gathering all information first, you can recognize patterns and see how it fits together

The next time I needed to make a quick reference guide, I didn’t even start to think about the design. Instead, I followed Roam’s advice. I opened up a help authoring tool and wrote out the procedures in full, without considering limitations of space or design.

After collecting the information, I reviewed it with a subject matter expert to make sure the information was accurate. She noted some steps that were wrong, information that was missing, and brought up some key issues users would face. I made the revisions to my help content.

I then asked a colleague if I could watch her follow my instructions. I scheduled an hour of her time and then just observed her casually as she tried to perform the instructions. It blew my mind that she could not complete even the first step. From the start, the plugin she needed to download ended up breaking the application she needed to test. When we tried the web interface workaround, she noted serious usability issues with a few fields and a bug with the lookup selector. I made notes about what I needed to fix in my documentation and made the adjustments.

After I felt I had a fairly complete and accurate body of documentation, I arranged the files in an online table of contents. Because it was relatively short (eight pages), I also printed the pages out and physically laid them side-by-side on my desk. Looking at all the information, I realized two procedures overlapped each other. They seemed too redundant to be separate, so I combined them into one task with a note. I also realized another process needed separating out, so I created a new task for it.

Had I been working with this information in little text frames in Adobe InDesign, adjusting and modifying the sentences each time to accommodate new or fluctuating information within the confines of a tight design, it would have driven me crazy. It would have taken a lot of time, hours spent worrying more about how the content affected the design rather than the content itself.