Case Study Presentation Architecture Powerpoint

You thought when you finished university, you said goodbye to presentations forever. But now, as an architect, you’re standing up in front of a group of strangers at least a couple of times a month, whether it’s presenting project ideas to a client, giving updates to a board, presenting at a conference, trying to win over a council, or lecturing to a room of hungover students.

I’m a pretty seasoned speaker, having given presentations at several national and international conferences on a diverse range of topics, as well as lecturing students. I still get nervous every time I stand up in front of a room, but the truth is, if you weren’t nervous, you’re probably not concerned about doing a good job, and that meansyour audience isn't going to relate to you. Being nervous before a presentation is totally normal.

Here are my top tips for crafting a spectacular architectural presentation:

Common Mistakes Architects Make in Presentations

  • Too many words. Too few images. The truth is, if you’re trying to get someone to buy in to the idea of a space, you need to show that space and get them excited about it. People are more excited by images than by words describing a space.
  • Using jargon your audience doesn’t understand. If your audience don’t know what you’re talking about, you will quickly lose them.
  • Running overtime. Your audience are busy people: they have meetings to attend and decisions to make and kids to pick up from soccer practice. Don’t take up their precious time by going over your allotted slot. It’s rude and will reflect badly on you.
  • Getting rattled by things going wrong. The projector won’t work, the main decision-maker gets stuck in traffic and can’t attend, you’ve forgotten your notes … inevitably, something will go wrong. The important thing is to not let it rattle you. Just go on the best you can. Your audience will respect your attempt.

Step 1. Think About Your Audience

The most important aspect of your presentation isn’t actually what you say, it’s who you say it to.

In order for a presentation to be successful, it has to hit home with the audience. What some people are interested in will completely bore others. It’s your job to figure out who the audience is and craft a presentation that will keep them engaged.

Think about:

  • What are your audience members’ goals? Are they students looking to understand a concept so they can pass an exam? Are they decision-makers in a firm looking to choose a design for their new building? Are they community members concerned about a new development? Think about what their goals are for the presentation.
  • What are they interested in? When you’re trying to sell a design, it helps to appeal to people’s selfishness - think about what most attracts people in the audience to a space (work space improving productivity, relaxation, eco-principles), and highlight these features.
  • What are the three things you want your audience to walk away with?

Step 2. They Don’t Need Every Detail

Do you know what drives me mad when I attend presentations or lectures? Presenters who write all of their content on the slides, and simply proceed to read the slides to the audience. Bor-ring! If I wanted someone to read to me, I’d call Benedict Cumberbatch.

Mmmmm. Benedict Cumberbatch.

Where was I? Oh yes, improving your presentation. You are not trying to get your audience to remember every single bit of information on your project. If they need specific details, they can look them up in the documentation or ask you later. What you’re trying to do is get them excited or help them understand the overall concept.

Your presentation isn’t about the minutiae - it’s about the big, flashy, sparkly concept. It’s about the stuff that makes people go wow. Focus on getting people excited, rather than bombarding them with details:

  • Putting all your text on the slides does not make people remember it. It makes them nod off.
  • Use images instead. I always use images as cues - so each images represents a concept I want to talk about. When I want to discuss a new idea, I move on to a new image that represents it. (For example, one image might show the clever use of light and shadow in a building design, while another showcases the sustainable details of the same building).
  • What actually works much better than extraneous details is telling a story. Talk about how you arrived at a particular idea, at how a building’s history has shaped your design, a crazy story about a famous architect whose work has influenced yours … stories engage your audience and build a connection between you and them.
  • At the end of your presentation, you could include a summary slide where you briefly state the three main points or themes you covered. This helps ensure everyone walks away with the intended message.

Step 3. Create a Stunning Presentation

You’re an architect, so you like things to look pretty. Putting together the presentation is probably your favorite part of the process (I know it’s mine!). Here are some tips to make it shine:

  • Use a simple, plain background. Let your images and text pop. I’m a huge believer in using as many images as possible, but minimal text.
  • Add some humor. When you tell a joke or show an image that makes people laugh, it helps your points to stick in people’s minds. When you go home after a day of presentations, whose do you usually remember? That’s right - the funny ones. So it never hurts to add a few giggles.
  • Avoid jargon, unless your audience are seasoned architects. You may think talking the lingo makes you appear professional and knowledgeable, but all it does is make you sound like a prat. An architect friend once said to me that he, “talks as if I’m explaining something to Grandma.” Talk at the level of knowledge your audience is at - this will help them grasp the concepts of the project you’re trying to portray.
  • Keep it simple! Remember, you’re not trying to win the Pulitzer Prize here (unless you are), but you’re just trying to get your idea across - focus on stripping things back to your main points and getting people excited about your concepts.

Step 4. Practice Makes Perfect

One of the best ways to combat your nerves is to be prepared. The better you know your material, the less likely you are to have a total brain freeze. Here are some tips for practicing your presentation:

  • Practice in front of your family at home. If you live alone, sit your pet down on the couch and get them to watch. If anyone is going to tell you what they really think, it’s your cat.
  • Remember that you are presenting in front of a group of interested colleagues, stakeholders or students - not the Spanish Inquisition. If you mess up, stumble over a word, or get a slide in the wrong order, no one is going to crucify you. As long as you can convey your enthusiasm for the project, you’re going to do just fine.
  • If you turn into a blubbering mess every time you stand up in front of an audience, then perhaps you need some more focused skill-building in public speaking. Joining a debate club, speech competition or toastmasters class will help you perfect your skills. Professional speakers associations in your local area often run workshops for budding public speakers. Go along and learn as much as you can from professionals. The only way to conquer your fear of standing up there is to keep standing up there til it’s not fear anymore.

Step 5. Deliver It Beautifully

Ah, now we come to the hard part; the palm-sweating, floor-staring, uncontrollable-shaking, inarticulate stuttering part. You have to stand up in front of a crowded room and deliver your presentation. Here are some tips to make it a little less painful:
  • Choose clothing you’re comfortable in. If you always feel awkward in a suit and tie, wear something else. You can still look professional and feel comfortable at the same time.

  • Avoid lecterns and other props that discourage movement. No one likes watching a statue talk. Wave your hands, stamp your feet, move around the room. This comes naturally to some people, and others have to work on it. Watch videos of speakers you admire on youtube and watch what they do.

  • Vary your delivery techniques. A lot of speakers like to ask the audience questions, and use these questions as a jumping-off point to talk about concepts.

  • Leave time at the end for questions.

6. After the Presentation

I know you’ll never want to think of it again, but it can help to take time after your presentation to evaluate what went right, and what you could improve on. If you’ve had someone video your talk, look over the footage if you can (I am always way too embarrassed to do this), and see what the audience sees. Did you talk too fast? Did you make eye-contact? Were your slides easy to understand?

If possible, gather feedback from others. Talk to attendees after the lecture or send them out a quick questionnaire by email. You might be surprised at the responses you receive - good criticism can help you improve for next time.

Extra for Experts

Have a look at these articles stuffed with presentation tips for architects:

Have you had to present an architecture project before? How did you overcome your nerves? What tips do you have for fellow architects?

One night I couldn't sleep I wrote a whole blog entry in my mind on how to do a good case study presentation on paper. I quite liked it, and so wrote it down on paper, and that paper has been lying around for a year or two now. Since the Topic Maps 2008 conference is coming up I figured this was a good time to finally post it, as the speakers are likely to be struggling with such presentations just now over the Easter break.

The motivation for this post is that usually when I attend a case study talk I go away with my head full of questions that didn't get answered in the presentation. What's strange is that very often they are the same questions. So figured that this time around I would ask them before the conference. I hope those of you writing presentations will see this, and find it useful. If nothing else it should give you 10 of the slides for your presentation.

Making an impact at Hotel Bristol

1. Who are you?

Always start with who you are and where you work, plus your relationship with the project. Everyone in the audience will want to know this. What they do not want, however, is 10 minutes of you droning on about your employer. Your organization probably has lots of ready-made slides about itself, which is an easy source of material. Be very careful about using too much of it, however. 2 slides should be the max.

Another pitfall is to speak too much internal dialect, so that outsiders cannot actually understand what you are saying. You may want to test these slides on someone who is not a colleague to check if it is understandable.

2. What is the application?

This is crucial. You need to be really clear on what your application actually does, and what business needs it serves. You can see this as the answers to a list of questions: Why was the application built? Who uses it? For what? Where in this system did you use Topic Maps? Why?

Note that I'm not asking about the project. Information about that is useful, too, but secondary.

3. Conceptual architecture

This is equally crucial, and usually omitted. What is the structure of the application/system that you've built? What are the major components, and how are they related? The only way to show this, is with a boxes-and-arrows diagram that gives a rough outline. It doesn't need to be terribly detailed, as long as it covers things like application server, database, CMS, search engine, etc. Covering the data flow may also be a good idea.

Some presenters skip this altogether, and don't get into architecture at any level of detail at all. When they do I always feel like I don't really know what they've done, unless I've been able to piece together this information indirectly. So for me personally this is often one of the most important parts of the presentation.

Make sure to include actual product names! Omitting the product names tends to annoy me no end. Knowing what products others have used is always useful, and giving this information is nearly effortless for the presenter, so why anyone would leave it out I really can't understand. Presenters who omit this part can usually count on getting questions about this after their presentations, from me or from someone else. (Post-lunch speakers risk being pelted with fruit from the buffet. :-)

4. Show your ontology!

Ceiling lamp, Hotel Bristol

A diagram showing the main classes and relations in the ontology is another thing the audience wants to see, and which makes a major difference in showing people what is actually going on. Don't worry about using UML/GTM or being very formal. That's not the point. The point is to at least give a rough outline of what is happening in the system. So an informal boxes-and-arrows diagram is good enough for this, too. (Plain text, on the other hand, is not the solution.)

One thing people probably worry about here, and that tends to cause them to leave this out, is a concern that their ontology is not complicated or fancy enough. That shouldn't really be a worry. A complex ontology is not necessarily good. Since end-users and authors need to understand the ontology it often can't be very complex, and in most systems it actually isn't that complex.

5. Screenshots are good!

For showing people what your application does there is nothing like screenshots. In this case, as in the two previous ones, a picture really does something a thousand words never could hope to achieve. A common problem here is to include the entire screen, so that the text in the screenshot becomes too small for people to read. If you do that you might as well leave the screenshots out, as this makes them useless. Instead, it's better to break them up into smaller pieces and show one piece at a time.

Don't overdo this, though. 2-3 screenshots is usually enough, and more than that tends to become too much quite quickly.

6. Numbers are good!

Generally, case studies tend to be very low on precise information, which makes them a lot less useful than they could be. So exact figures are good, even if getting hold of them tends to be difficult and require early planning (because you have to ask other people who often take a week to reply).

Good numbers are things like: How many authors? How many users? How many concurrent users? How many topics, associations, occurrences? How many topics of each type? How big was the project team? Budget numbers are good, too.

7. What's special about your application?

Most applications tend to have a lot in common, which is fine, but you should try to put the emphasis in your presentation on what makes your application different from the others. There is always something that is different about each application, and the difference tends to be the most interesting aspect for the audience. So try to find out how your project is different, and then emphasize that.

8. What was good?

Hotel Bristol

What went well during your project? What were you happy with and felt worked for you? What are you pleased about in retrospect? What didn't cause problems? This type of information tends to be very valuable (and interesting) for others.

9. What was bad?

There is always something bad in every project, from illness through budget cuts to technical issues, and knowing about this always interesting for others. For those thinking about running their own projects it's always enlightening to hear that the biggest issues may be completely different from the ones they are worrying about.

Of course, in many cases the biggest problem is a people problem, in which case this part may require some tact, but it's still worth including. And don't worry about people's reaction when you tell them you had difficulties, since most people are experienced enough to know that all projects have their problems. So by including this you are more likely to impress people with your honesty and your ability to analyze your difficulties.

10. What's the status?

Very often, the presenter neglects to say whether or not the system described has been in production for a decade already, or whether they are still trying to find a customer for it. This is another omission that's sure to make people ask you questions at the end, since people always want to know what the status of your project is.

Talking a little bit about future plans is also a good way to wind up the presentation. Are you planning to scrap the system? Are you going to extend it? Let people know!

Similar posts

TMRA'05 — second day

(Second day of semi-live coverage from the TMRA'05 Topic Maps research workshop.)

Today we again start with Jack Park, this time speaking on "Just for Me: Topic Maps and Ontologies"

Read | 2005-10-07 13:33

Emnekart 2006

This was the fourth Norwegian Topic Maps conference (emnekart is Norwegian for Topic Maps), and for the first time it was not entirely in Norwegian, as this year there was an English track through the whole conference

Read | 2006-03-30 20:59

TMRA 2007 — day 1

As usual, the conference was opened by Lutz, who gave a short introduction based around the conference motto of "Scaling Topic Maps"

Read | 2007-10-11 18:13


Conal - 2008-03-16 17:26:06

Marit Mellingen - 2008-04-02 09:23:07

Peter - 2008-04-22 05:59:03

Dushyant Kumar - 2012-04-19 14:25:55

aaronpaul lagrimas - 2012-09-11 21:37:31

mahrukh - 2012-12-30 03:50:16

Vilhelm Erichsen - 2013-04-12 21:29:57

Srini Bojja - 2013-06-24 21:40:34

kenneth mwelwa - 2016-02-09 09:08:32

Add a comment


Leave a Reply

Your email address will not be published. Required fields are marked *