How to Create Effective Technical Presentations

One of my great bugbears in life is the dire nature of the average technical presentation produced by IT folk in general and architects in particular. I’m not saying all architects produce bad presentations or that architects are the only culprits. It’s just that I tend to see more presentations from this particular group so am more inclined to comment on them. The main problems I see are:

  • Too much text/information on a slide.
  • Text too small to read unless you are in the front row and have 20-20 vision.
  • Inconsistent use of colour.
  • Poor layout.
  • Use of dreadful and completely irrelevant clip-art.
  • Far too many slides given the length of the presentation.
  • Unnecessary and confusing animations.
  • I could go on…

Before I go any further I confess I have produced some pretty dreadful presentations in my time where I have fallen foul of most, if not all, of the above at some point. However I’ve recently been reading the books (Presentation Zen and Presentation Zen Design) and blog of Garr Reynolds and thinking how what he says can help with people who need to produce technical presentations. Here are five tips based on the advice from Garr’s books that will help you next time you have to create a technical presentation.

  1. Don’t put more than you need to in the presentation. The first, and I think best piece of advice, is to recognise the inherent limitations of presentations as a communication mechanism and try and mimimise the amount of information you present. Hopefully the audience is there to listen to what you have to say not to see how good you are at slideware. Presentations should summarise, mainly in pictures and in as few words as possible, what you have to say. If you do need to provide additional information then hand this out as a supplement at the end of the presentation. Never just hand out your slides, that’s just cheap and shows you don’t care! Anyway, a good presentation should, by definition, not stand alone. It should only work when the speaker is there to present it.
  2. Make use of all the space on a presentation slide. This means removing all the unnecessary garbage that can often be found on a presentation template. You know the sort of thing I mean, there is a header and footer showing various aspects of your companies logo that take up more room than the presentation content itself! The only place a company logo should appear is on the title page. After that you should have complete use of the limited space you have available to you. Whilst talking about space you should not feel you have to fill all of the space with content. Sometimes having empty space is just as important as the content as it can provide contrast and at the same time help direct the viewers eye to the positive elements.
  3. Use words rarely. This is the most difficult piece of advice to take. It is tempting to fill a slide up with words because you are worried you will forget some important piece of information so you have to write this on the slide. Unfortunately giving a good presentation does mean you should practice, practice and practice and memorise what you want to say as much as possible. If you are in a rush and don’t have time then use cue cards but don’t read the words on the slide. Where you do need to use words to summarise key points then I like to try and follow what I call the five by five rule. That’s five words in a line and a maximum of five lines (yes really). Finally text should be viewable from people in the back row. To check this put PowerPoint in slide sorter mode, make the slides 100% and make sure you can read the text without squinting at the screen. This is the view people in the back row will have. Actually, I lied, that wasn’t the final point on this. You should also use consistent and clear typography throughout. Don’t go overboard with lots of different fonts and font sizes.
  4. Use colour, layout and other design techniques for diagrams. Technical presentations by there very nature often include lots of diagrams. By necessity these will usually need to be simplified in order to get the key points across. Make use of colour to show contrast, lay things out in a consistent and meaningful way and follow some basic design techniques such as the rule of thirds to ensure your diagrams have maximum impact.
  5. Use pictures wherever possible. I’m a recent convert to this. I love the idea of using pictures to get across key ideas and concepts. As a keen photographer I try and use my own images wherever I can however where I need something that I don’t have to hand I use stock photos (yes, which I buy with my own money). Don’t be a cheapskate and download low-res images from the web. Spend a few £££’s or $$$’s and get good quality stock images from somewhere like istockphoto.

This is a very short introductory set of ideas for making effective technical presentations. Try some of them next time you have to do a presentation and see what comments you get.

Finally, if you want to view some good quality presentations take a look at the technical presentations at

Architecture Anti-Patterns: Pattern #5 – Death by (Technical) Presentations

Anti-Pattern Name: Death by (Technical) Presentations
General Form:
A presentation on a technical topic contains many, many slides of tightly packed text with overly complex diagrams that are difficult to read close up let alone from any distance away.
Symptoms and Consequences:

  • You’re invited along to a presentation where the architecture will be “presented”.
  • The presentation consists of 167 slides in mainly 12pt font with closely packed words on each page.
  • The presenter often says things like “I’m sorry you can’t see this from the back” or ” I’m going to skip over this slide as it’s not really relevant”.

Refactored Solution:

  • Read this book and visit Garr Reynolds blog for ideas and inspiration
  • Architectures should be created as models in a legitimate modelling tool. It’s okay to cut and paste pictures into a presentation tool such as PowerPoint as long as they can easily be viewed and are meaningful.
  • Make sure presentations are consistent in their use of layout, colour and fonts.
  • Don’t attempt to put all the information in a presentation. Refactor to contain the key points only.
  • Put the detailed information in handouts which are given out after the presentation.

See Pattern #4

Design Really Does Matter

I’ve just received a new work laptop and what a monstrosity it is! There was a time when ThinkPads were actually quite sexy as far as laptops go but this model (a T400 if you’re interested) is a complete abomination of a thing. It’s not only square and clunky feeling but for some mysterious reason the designers have made the battery stick out of the back like some large cancerous growth. Why, if Apple can design a laptop with a supposed 6 hour battery life where the battery is hidden completely inside the case do Lenovo designers have to create something that has the battery hanging out the back and appear to offer no more life?

What’s all this got do do with the zen of architecture you might ask? I’ve been reading the latest book by Garr Reynolds, Presentationzen Design where Garr suggests we should take inspiration for good design from the products we see around us all day. The ThinkPad would seem to be a good design antipattern to me. Of course, as Hugh MacLeod says “there’s no correlation between creativity and equipment ownership” and “a fancy tool just gives a second-rater one more pillar to hide behind.” That said, I feel sure that using a tool that is both good to look and is well designed makes for an all round better experience that must aid in the flow of the creative juices. If you don’t have the ideas in the first place then the best tool in the world won’t help you create them but if you do have something to say what would you rather write with, the free pen from the hotel room or the Mont Blanc you got for Christmas?

Five Tips on How to Think Like a Designer

I got this idea from Garr Reynolds blog entry 10 Tips on how to think like a designer. Ten is too large a number for my simple brain so instead I’ve picked the five that I think we as software architects can most learn from the world of design.

  1. Embrace constraints. An architect often complains about the constraints and limitations she has to work under (especially those related to money, time and resource). The skill is to accept constraints and figure out what you can do with the resources you have. After all, a completely unbounded problem with total freedom on how to solve it is likely to end up never being solved. Remember how the NASA engineers managed to fix the Apollo 13 CO2 filter problem using just what they knew was available on the spacecraft. Now that’s embracing constraints.
  2. Practice restraint. This is related to the previous one. As Reynolds says: “any fool can be complicated and add more, it takes discipline of mind and strength of will to make the hard choices about what to include and what to exclude”. As software architects we are often overwhelmed with choice when putting together a solution. There are often many different vendors software products and packages from which to choose and, of course software, by definition, is malleable and can be shaped in many different ways. The trick here then is to practice self-constraint and go for simplicity rather than complexity and cleanness of form rather than clutter and obfuscation.
  3. Check your ego at the door. Ultimately all software, no matter how deeply imbedded or how far it is along the food chain, has an end user to cope with. How that user interacts with and understands the system of which your software is a part depends on how well designed it is. The software architect usually has many different people to deal with (people who use the system directly, people who must maintain the system, people who need to ensure the system is secure, the list goes on). Each of these people has a “stake” in the system (hence the name we some refer to them by as “stakeholders”) and a good architect understands the needs of these stakeholders and is empathetic towards those needs. Empathy is a difficult soft-skill to master but is very important to acquire. It is so important that Dan Pink in his book A Whole New Mind states it as one of the key differentiators that will mark out those people who are able to survive the 21st century world of work where everything is outsourced, commoditised or performed more cheaply by a computer.
  4. Become a master storyteller. You may have just devised the greatest software architecture the world has ever seen but if you cannot sell that solution it’s not going to be any good to anyone and will most likely never see the light. Much software is, by its very nature, complex and describing what it does and what are its benefits can be difficult. Storytelling, that is weaving a story around your system by illustrating it verbally and using multi-media to back up what you are saying can help. Don’t rely on complex and overly-cluttered PowerPoint slides when trying to describe what the system does but instead relate it to everyday experiences your audience are likely to identify with.
  5. Obsess about ideas not tools. As Reynolds says: “tools are important and necessary, but they come and go as better tools come along”. Probably no discipline is more blessed (sic) with tools than ours is. Whilst tools are clearly important to the software architect remember they are a means to an end so don’t sweat over them too much. Instead concentrate on the ideas and use pencils and paper or whiteboards and pens to capture your ideas. These also have the benefits of being readily available and don’t suffer from expired batteries.