views:

123

answers:

6

Communicating with non-technical users can be challenging. What tips do you keep in mind in order to keep the presentation of new and often in-progress development productive?

+3  A: 

"A picture is worth a thousand words." Diagrams can be helpful.

Jim Anderson
A: 

I agree with the picture answer. Also, plan to be able to drill down into your presentation if your audience is interested, but if they only want the 1000 foot view just hit the top level points. The key is to stay in communication with the audience while you are presenting so you know how much detail they want.

Andrew Cowenhoven
Any "drilling" should be done at a later time, if possible. Wow them with the 1k' view and have them wanting more. A little "digging" might help, but save the detail for when you know what they want to hear and have time to prepare specifically for delivering that message.
Scottie T
+2  A: 

You need to quantify progress for non-technical people in a way they can understand - talk about features completed, describe use-cases and user stories and talk about the next milestones.

Use short sentences with easy to understand language and plenty of graphics. Try to create metaphors regular people can relate to.

Eran Galperin
+1: Facts they actually care about -- features, use cases, etc.
S.Lott
+2  A: 

If you are showing them a Beta, an Alpha or even a prototype, show things that aren't working as broken. e.g., gray-out menus or use only rough graphics. Otherwise they are going to think that you are almost done the whole project from the first time they see it.

Building the interface is often the easy part; and they won't remember (no mater what you tell them) that the code behind is broken.

CodeSlave
A: 

Understand your audience and at what level of granularity and timeframe makes sense for a given meeting. For some new development in front of a steering committee staying at a high level may work fine for defining general rules, while if there is a one-on-one meeting then getting into the nitty-gritty details of "What should the application do if..." gets answered over and over again as sometimes users don't realize that the computer has to have steps for any situation that may not go over so well if you have a half dozen VPs in a room and are discussing a handful of bugs that most of them don't care about at all. As for the time point, having an agenda and knowing what from various perspectives should be discussed or communicated is something to keep in mind. If you booked a 4 hour meeting that ends up being 30 minutes a few times, you risk losing credibility if the meeeting ever does require more time as some people may think, "Well, we've had this 3 times now and each time it was done within 30 minutes, what is different this time?"

JB King
+1  A: 

Something that everyone wants to know... How does it affect them?

jle