Developer Diaries: OWL-studio on how to make reports

Recently, I have been attending conferences more and more often, communicating with organizers and speakers. I came across the fact that among my colleagues there are a huge number of skilled people who would be interesting to listen to – but it is quite difficult to encourage them to speak. And not only because of the natural introversion of the character – they do not understand from which side to give up on the topic. For novice speakers, I wrote a small memo: step-by-step instructions for compiling a report and a presentation to it.

1. Report

1.1 Name

The title should be short and succinct, and should also reflect the essence of the report and preferably cling to some kind of chip.

• A good name: “Two doshiraks for an icon”. It is clear that we are talking about graphics (in particular iconography) and finance, there is a catchy wording.
• The normal title is “All about mobile monetization”. The name doesn’t catch on, but those people who are interested in mobile monetization will note and come.
• Bad name: “A big ship has a great voyage.” What the report is about is not clear.

1.2 General recommendations

Two types of reports are the most useful:

• up-to-date statistical information;
• solving urgent problems.

In the first case, the report introduces the listener to some cross-section of what is happening at the moment in the most relevant areas for developers (it can help make the right decision). In the second case, the report voices a certain problem that is relevant to the majority and suggests ways to solve it.

Next in usefulness:

• reports-presentations;
• case reports.

When people talk about a product or project, or about how they encountered any specific tasks and what tools they solved them. The difference between the case report and the report on solving actual problems is that the first one is more highly specialized, refers to special cases and the methods of solving are not always universal. For example, a report on time management on a project (typical “timekillers” and ways to destroy them) is a solution to the problem. The report on the creation of the animation of the flight of witches in a particular game is a case study.

Such reports can be very interesting, but they are aimed at a smaller audience.

What to avoid:

1. discussion of questions without giving answers;
2. discussion of the topic (project) without a specific purpose and conclusions;
3. a narrative without a beginning, an end and key points;
4. lengthy stories about his personal life or “my path as a developer”.

1.3 Outline of the report

The plan of the report is based on the following logic:

A) AcquaintanceI’m like this, I have such and such skills, so now I’ll tell you about that.

B) Introductory topicHere comes the formulation of the problem.

Even if the report is not about the problem – this wording creates engagement, now we are listening not just to information, but to the solution of the problem.

Example:

• One day we created a farm where there were zombies instead of sheep;
• One day we realized that farms work mainly for a female audience (a problem). We wanted to create a unisex farm – and replaced sheep with zombies.

C) Key pointsThere should be 3-4 of them for a half–hour report and 6-8 for an hour.

All information should be broken down into completed pieces, 3-5 minutes per piece. It is desirable that such pieces have headings: they will be remembered and will help the listener to structure the information. This will allow the listener to perceive the information more comfortably and assimilate the maximum of what the speaker told. In these pieces, you can consider individual cases, questions, stages, groups of data, etc.

D) ConclusionHere the speaker gives an answer to the question Why you need all that you just heard, what problems we managed to solve, how we can apply this knowledge.

“As a result of replacing sheep with zombies, we have increased the male audience of the farm by 70%.”

2. Presentation

2.1 General recommendations

Do not forget about the features of the picture transmitted through the projector: small details, thin and small fonts are not read on it, light tones are “eaten” and dark ones look unprofitable. Bright, clear scales, large sans-serif font look best.

2.2 Slide functions

Each slide for a presentation can have its own function. I single out four.

• Summary. As part of the summary slides, a brief extract is given on the key point (part of the report), which the speaker verbally reveals in more detail. It is convenient to photograph the notes so that you can remember what you heard later. Listeners love clearly and correctly formulated notes.
• Complementary. The supplement slides, as a rule, contain any diagrams, graphs, etc., explaining what the author means. Separately, the speaker’s speech and these pictures are uninformative.
• Illustrative. Slides-illustrations show what the author is talking about. They carry an additional character. They work well as a “pause”. It is not necessary to build a presentation on illustrations alone – so informative is lost.
• Entertaining. An entertaining picture (less often an inscription) – helps to focus the listener’s attention, well fixes what he has heard (cats, tits, funny gifs, photojabs, etc.). It can be a cool “highlight”, but also often do not make much sense.

2.3 Preparation of the presentation

How to alternate slides is a master’s business, but as practice shows: presentations that alternate slides–summaries and slides-presentations (graphic/textual information) are best perceived. It is better to give the most important and complex information at the beginning, entertaining content, if added, then at the end.

I have everything! Good luck at conferences!