Some tips for more effective white-boarding? [closed]

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.

Demandant

I think the fact that you are working on whiteboards means that it doesn't have to be perfect or visually appealing. If you can get your point across, the whiteboard is just there to reinforce what you've stated verbally. – Arvid

Note to the close-happy: Communicating effectively with other programmers is "not programming related"?! Go close something else! – Affined

No kidding--this is amazingly programming related unless you just sit at home and never talk to anyone. I don't know a single programmer without a well-used white-board in his cube. – Uel

Voting to close as too broad. – Mannerheim

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.

Beard

For symbols, do you for 2-D or 3-D, e.g., when drawing a database container? – Marnimarnia

Consistency helps. Borrow from UML. Rectangles are things. Lines are associations. 3-D rectangles are servers. File-folder icons are packages. – Tsarism

Answer 2

Slow Down.

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

Tsarism

+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. – Marnimarnia

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.

Mellins

makes a massive difference. De-stressing – Lathery

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.

Binnings

This is exactly the scenario where I want the diagram to look nice. The work often gets reproduced. – Marnimarnia

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. – Cabbageworm

Answer 5

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.

Dorri

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

Chenopod

+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. – Marnimarnia

Answer 7

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

Nicolasanicolau

Hmm, that looks like a dog's breakfast to me :) I guess we have different taste! – Marnimarnia

Answer 8

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.

Uel

Can you provide a link to a sample UML diagram that you think is exemplary? – Marnimarnia

Answer 9

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

Fatherinlaw

Answer 10

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

Cristie

Yes, thankfully this is one area where I am comfortable: some boxes, lines, and crows-feet. It's all those other things... – Marnimarnia

Answer 11

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

Syzygy

Not even circles are allowed? Or are they derived from lines :) – Marnimarnia

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. – Affined

Answer 12

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.

Tsarism

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. – Marnimarnia

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. – Tsarism