Some tips for more effective white-boarding?

Question

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.

Answer 1

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.

Answer 2

Slow Down.

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

Answer 3

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.

Answer 4

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.

Answer 5

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 http://www.matterco.com/wp-content/themes/matter/images/art057.jpg

Answer 6

• 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

Answer 7

I know I am a little late on the scene, but I would also recommend actually writing down what you are trying to achieve, either in a sentence or with some bullets. It is quite easy to be working towards different things, and this gets that over with very early on. It also can be used to reign in/monitor requirements creep.

Last but not least it also gives you a good point to start from before moving on to ER diagrams and other modelling.

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

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