It is not a secret that one of Jappware’s key values is support for the technical community. Therefore, we regularly take part 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 collected a set of common mistakes speakers make during their talks over several years.

Off-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. Central part - 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 for that, e.g., it's easier to refer to the slide by its number during the QA session.
  2. Slides 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 total slides count during the intro
    2. specify it on your slides (e.g., for PowerPoint:
    3. Include progress bar (PowerPoint:; Google Slides:


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

Slides content

  1. Add 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 license 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 is 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 part 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 piece of code could be rephrased to shift the focus to important stuff
You may emphasis the most important part in 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 a lot of content. You should uncover or highlight 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 audience level is diverse. Be ready that there will be newbies, middle level, 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 that the audience is mature enough, you may spend less time explaining 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 amount of time spent on every slide and overall presentation time (PowerPoint’s features can help you here).
  3. Determine the “outlier” slides – 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 details you want to speak on. Adjust the level of details 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 to read 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 which 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 optimal slide aspect ratio (4:3 or 16:9) for given screen and projector.
  3. Make sure 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 if the first row and how far is the last row 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. Make sure your slides and tools look well, considering the lighting of the hall. 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 speak loud enough.


  1. Introduce yourself
  2. Announce the high-level agenda clearly. You may also mention what’s NOT you talk 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 to your slides or a window or a sidewall. It’s even more critical if the screen is behind you or if 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 reaction of the audience and adjust the level of details based on the reaction.
  7. Be ready that something may go wrong (presentation RC doesn’t work, demo failed, the 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 also a README file with brief instructions (prerequisites, how to build and start 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 make sure you have enough free disk space and screen recording software installed.
  3. If you provide a link to 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: