It is not a secret that one of Jappware’s key values is support for the technical community. Therefore, we regularly participate in technical meetups and conferences organization, and one of our most important goals is to ensure the highest quality of technical talks.

Like famous GoF collected and described the most typical design patterns in software, our team compiled a set of common mistakes speakers make during their talks over several years.

Of course, this article is far from the excellence of the GoF’s “Design Patterns” masterpiece, but we believe this experience is still worth sharing.


  1. Choose the most important message you’d like to tell your audience.
  2. You may also have one or two secondary messages, but not more.
  3. Compose your presentation according to the classic structure:
    1. Setup - introduce the problem you will present.
    2. The central part is the journey and trials you (or your hero) have passed through to resolve the problem. The culmination of your presentation should be here.
    3. Resolution - summary, conclusions, lessons learned, etc.

Slides design and content

  1. Slides should be numbered. There are multiple reasons, e.g., it's easier to refer to the slide by its number during the QA session.
  2. The slide layout should be standard whenever possible. Make sure titles and other typical slide blocks do not “jump” when you switch between slides.
  3. Let the audience track the progress of the presentation. You may use one or more of the following:
    1. announce the total slide count during the intro
    2. specify it on your slides (e.g., for PowerPoint:
    3. Include progress bar (PowerPoint:; Google Slides:


  1. Ensure fonts are readable, especially for the audience on the last rows.
  2. Use consistent fonts. It includes font families, font sizes, and font colours.
  3. Don’t use Comic Sans MS unless your presentation is a comic. More on this:

Slides content

  1. Add a slide with your contacts. This slide should not be the last slide of your presentation. Preferably, it should be after the concluding slide but before the Q&A (Questions) slide.
  2. Third-party content (photos, pictures, articles, text from a book, etc.):
  3. Respect content licenses do not include any content unless you are authorized to do so.
  4. Specify sources of the content. For example, specify the URLs of the images used on slides (e.g., place a reference in the slide’s footer or under the picture).
  5. Add a slide with a list of resources used in the presentation, such as [links to] articles, books, etc.
  6. Include QR codes for links.

Code snippets

  1. Highlight important parts of the code snippet.
  2. One message - one line (if possible): if you explain a line of code (operator, statement, function calls, etc.), it should fit into one line on the slide.
This code is correct but is hard to read on a slide.
The same code could be rephrased to shift the focus to important stuff.
You may emphasize the most important part of the code

“Live” Slides

  • Use animation when possible. By animation, we mean not all these fancy slide transitions. It’s rather about showing the information on the slide in small portions if there is much content. It would be best if you uncovered or highlighted the information piece by piece as you speak.
  • Avoid infinitely-looped gifs or minimize their exposition time. Such gifs might make your audience sick.


  1. If possible, determine the audience level in advance and best guess the optimal level of details for your presentation.
  2. The above is not always possible, though. In most cases, the audience level is diverse. Accept that there will be newbies, middle-level people, and experts. Don’t make any assumptions about audience level before you start the presentation, though.
    1. Prepare slides explaining basic terms and concepts.
    2. Don’t be afraid to explain “obvious things”; for many listeners, they are not so obvious 🙂
    3. Try to determine the level of the audience as you present. If you feel the audience is mature enough, you may spend less time explaining the basics and vice versa.

At home

  1. Practice your speech in front of a mirror. Rubber duck, pet, partner, or a friend may help too.
  2. Record the time spent on every slide and overall presentation time (PowerPoint’s features can help you here).
  3. Determine the “outlier” slides that take significantly more time than average. Think whether that’s OK, or maybe it’s worth splitting the slide into smaller parts or omitting some details.
  4. Check time restrictions with the event organizers and make sure your presentation fits.
  5. Think about the level of detail you want to speak on. Adjust the level of detail according to the expected audience.
  6. Try to predict questions and be ready to answer them.
  7. Practice speaking moderately (not too slowly or too quickly). Remember – people need some time to “consume” the information.
  8. Practice not reading your slides or notes.
  9. If there are complicated statements, think about how you will compose the sentence so that it’s easy to understand. Prepare two or more variants for such a sentence.


  1. We recommend you conduct several trials where you speak to a trial group. It might be a group of 3-5 coworkers, an event program committee, etc. Collect feedback and adjust your presentation accordingly.
  2. If, during the trial, reviewers repeatedly run ahead asking questions that you plan to cover in future slides – rethink your storytelling; maybe the sequence of information needs to be adjusted.
  3. Ask experts to write down their comments, ideas, and suggestions. Discuss all of the notes after the trial. Ask reviewers to send you their notes (do not waste time noting everything yourself).

In the conference hall

  1. If possible, visit the conference hall or the stage a few days before the presentation.
  2. Determine the optimal slide aspect ratio (4:3 or 16:9) for a given screen and projector.
  3. Ensure your equipment is compatible with the conference hall equipment, and everything works well. If it’s incompatible or doesn’t work, ask the organizer to resolve the issue. Examples:
    1. projector cable and adapters
    2. presentation RC, laser pointer (ideally, bring your own)
    3. microphone
    4. flip chart or whiteboard, markers
    5. comfortable and safe laptop stand (make sure your laptop will not fall from the stand)
  4. Pay attention to the hall size (e.g., how close the first row is and how far the last row is from the projector screen) and adjust your slides accordingly.
  5. If you plan a demo, make sure all the fonts in your IDE, browser, or other tools are
    1. large enough
    2. visible for people on the last row (also consider people with poor eyesight)
  6. Considering the hall’s lighting, ensure your slides and tools look good. Adjust your slides theme and OS theme accordingly (don’t forget about your IDE, browser, and other tools you plan to present).
  7. Check if you can speak loudly enough so that everyone can hear you. Request a microphone if it’s hard to talk loud enough.


  1. Introduce yourself
  2. Announce the high-level agenda clearly. You may also mention what NOT you are talking about or what aspect of the topic is NOT covered (manage audience’s expectations).
  3. Don’t read your slides.
  4. Speak to the audience, not your slides, a window, or a sidewall. It’s even more critical if the screen is behind you or you have no microphone.
  5. Make brief pauses between chapters (sections of your presentation). People usually need a moment to “process” the information.
    1. If you are uncomfortable keeping silent for a moment, take a sip of water or ask if there are any questions so far.
    2. You may use “wrap-up” slides to summarize the current section. The “Wrap-up” slide should precede the next section’s title slide. It helps the speaker not jump to the next section too quickly and lets the audience rethink what they just heard.
  6. Observe the audience’s reaction and adjust the level of detail based on the response.
  7. Be ready for something to go wrong (presentation RC doesn’t work, demo failed, internet failed, etc.)
    1. prepare some jokes and keep calm 😉
    2. don’t panic, and don’t emphasize the issue
    3. do not make excuses
    4. prepare plan B for such situations (e.g., prepare the working version of the demo application in a separate git branch in advance)


  1. If a live coding demo is a part of your talk, it’s often a good idea to publish the code in a public GitHub repo. Include a README file with brief instructions (prerequisites, building and starting the app, etc.)
  2. (Optional) Organizers may ask you to record your screen during the presentation so that they can include your slides and demo in a high quality into the event video recording. Please ensure you have enough free disk space and screen recording software installed.
  3. If you provide a link to the GitHub repo, your site, or similar, and you want the audience to follow the link, you may include a QR code.

Additional resources

There are lots of these on the internet. Consider the following resources before the first trial: