views:

291

answers:

11

I am occasionally called upon impromptu to white-board (non-virtually) data flows, architecture diagrams etc., for both a technical and non-technical audience. Unfortunately my drawing skills (and print legibility) are terrible.

How can I become more effective at doing this? I am looking for tips on standard symbols and connectors to use, some standard ways of organizing and categorizing the information (e.g., swim lanes), etc.

What can I practice to become better at this? I want these visual presentations to be effective in communicating my ideas, and badly presented diagrams can make the ideas appear convoluted and inelegant, even when they are not.

+8  A: 

Slow Down.

It's okay to take your time to write neatly.

S.Lott
+1: That's a deceptively simple tip. There is definitely pressure to crank something out quickly, and if I can resist that, I'll be miles ahead.
RedFilter
+1  A: 

Are you familiar with ER diagramming ? If you are modeling a database ER diagrams are pretty universal to most people.

JonH
Yes, thankfully this is one area where I am comfortable: some boxes, lines, and crows-feet. It's all those other things...
RedFilter
+7  A: 

White-boarding is a great tool. I do quite a bit of it myself, and I've found a couple of things to be very effective:

  • Use a minimal set of symbols: Boxes, arrows, circles, and lines get you a long way. Prefer simple things to more advanced modeling techniques - everybody understands boxes and arrows.
  • Think aloud while drawing to help the audience understand what you're drawing.
  • Communicate with your audience. White-boarding is not one-way communication. If you are unsure whether a message got through or a drawing is understood, just ask.
  • When the audience is sufficiently small, get people close to the board, and make pens readily available so people can draw with you. This allows for better visually aided communication, and an even more efficient white-boarding session.
  • Take enough time to write and draw "neatly", but prefer a steady communication rate over perfect hand-writing. This is a hard trade-off which requires some practice, and practicing while keeping your writing and drawing understandable will increase both your writing and drawing speed.
Håvard S
+1: I like these tips, esp. *"think aloud while drawing"*
RedFilter
For symbols, do you for 2-D or 3-D, e.g., when drawing a database container?
RedFilter
Consistency helps. Borrow from UML. Rectangles are things. Lines are associations. 3-D rectangles are servers. File-folder icons are packages.
S.Lott
+3  A: 

Pretty basic, but this tip from drawing cartoon speech bubbles made a huge difference to me: don't draw boxes and then write text inside them. You will usually misjudge the required size, resulting in squashed, illegible text. Instead, write your label first, and draw the box around it afterwards.

I was amazed at how much the clarity of my diagrams improved by the application of this one simple principle.

ire_and_curses
+2  A: 

I often write on Post It Notes because you can easily move them around as your discuss relationships between objects. Also, different color Post Its can convey meaning.

Below is an example:

alt text

Christopher Altman
Hmm, that looks like a dog's breakfast to me :) I guess we have different taste!
RedFilter
+6  A: 

Another good tip for white-boarding is to bring along a digital camera and take a picture of your session. You can throw that up on a share after the meeting and it is great to be able to review past sessions that way.

davecoulter
This is exactly the scenario where I want the diagram to look nice. The work often gets reproduced.
RedFilter
Another quick and dirty way to do this is with a camera phone, assuming you have a reasonable quality camera phone, e-mail it to yourself and its a fast and easy way to record a whiteboard session.
CrimsonX
+2  A: 

Hi

  • Trying to accomodate too much into a single diagram might get confusing.
  • Try to visualize drill down of ideas where in you can draw and connect larger modules. May be, take a snap of this diagram as a way to save your idea-on-whiteboard and get feedback.
  • Focus on smaller modules and apply drill downs if applicable.

Wiki has some basic information on different diagrams which might be suitable for different scenarios.

I hope this helps.

cheers

Andriyev
+1: I really like that *Wiki* link, as there are a wealth of visual examples. I am going to go through them and see if I can pick a few styles I like, and start practicing them.
RedFilter
A: 

Architecture diagrams "should" be in UML.

However.

Detailed UML diagrams are a pain in the neck, so don't go for technical depth.

There are, however, some classifier stereotypes that are very, very helpful in allowing a "high-level" summary diagram to cover a number of bases.

The "Objectory class stereotypes" (see http://doc.sumy.ua/prog/umld/AD970806.PDF) for Control, Boundary and Entity classes are worth their weight in gold. Adding these stereotypes to a class diagram is helpful, quick, and a formal way to define how the class (or package) fits into the whole.

S.Lott
That sounds good in theory, but when I viewed that PDF, I saw unfamiliar symbols. I don't think I have *ever* seen a whiteboard drawing done using those symbols on p. 4. I want to make sure the ideas are communicated universally, not to just those that know UML.
RedFilter
They're only unfamiliar to you, right now. The stereotype icons are (1) easy to understand, (2) easy to draw and (3) a huge clarification. They're a great way to avoid visual clutter often done with color or irregular blobs to fence in packages. No picture can communicate anything "universally". UML helps by limiting the kinds of icons you can use and providing definitions for those icons. Don't go off the deep end. Just be consistent.
S.Lott
A: 

I'm a big fan of the Galactic Modeling Language, myself.

Will Hartung
Not even circles are allowed? Or are they derived from lines :)
RedFilter
When I have talks at a whiteboard, they begin with the ceremony of The Drawing of the Box So We Can Point At It While We Talk.
Daniel Earwicker
+1  A: 

Make sure you have a big whiteboard.
The bigger, the clearer you can detail your ideas.

Ink-Jet
+1  A: 

I know many programmers tend to think of UML as "that stupid crap they want me to put in the document that is never going to be looked at", but it was actually designed to solve the problem of programmers communicating.

Know UML, even if though it rarely matters if you use an open arrow or a closed arrow because the fact is that it will confuse some people if you use the wrong one. Programmers are very single-minded critters and that's one of the things they often enjoy getting "Stuck" on.

Know a few basic UML diagram types. Everyone knows some level of object diagram, I often combine inheritance and containment diagrams in the same picture--don't be too strict.

Read a few flow diagrams and actually create one for a complex flow you're working on. They are so damn cool at analyzing what's going on and at communicating anything beyond a trivial single method call/return. I didn't know about these for about 1/3 of my career and was just dumbfounded the first time someone threw one out on the whiteboard (this was after I knew everything--but of course, every year I learn more and then decide I FINALLY know everything).

Finally--you're standing there talking with the person. Really a box on the white board is just something you can point at so that the next time you point at it the person knows that you mean the same thing... it'a a visual assist to enhance your verbal communication, that's all.

Edit:

This page is a good intro to sequence diagrams with a lot of great examples.

Bill K
Can you provide a link to a sample UML diagram that you think is exemplary?
RedFilter