5 критических ошибок в презентациях данных
Всем привет!
Хочу написать про то, как мы презентуем данные другим. Технические специалисты часто сталкиваются с необходимостью доносить результаты своей работы до людей, которые не так глубоко погружены в тему. Однако, даже самые ценные выводы могут остаться непонятыми, если их неправильно представить. В этой статье я рассмотрю пять типичных ошибок, которые инженеры совершают при подготовке презентаций, и предложу способы их исправления.
![комикс натальи киселевой eolay комикс натальи киселевой eolay](https://habrastorage.org/getpro/habr/upload_files/1bb/75e/0c9/1bb75e0c974b050cd1a9cc925a6b4d04.png)
После 15 лет работы инженером могу сказать, что проработка этих ошибок стала хорошим карьерным скачком для меня. На картинке пример из реальной жизни! Когда я только начала работать с данными, мне частенько приходилось их презентовать руководству. И меня жутко злило, что директора ничего не понимают и постоянно сомневаются в показанных результатах!
Возмутительно! И только спустя годы, я поняла в чем тут была проблема, и как исправить эти ошибки.
Ошибка 1: Перегруженные слайды
![](https://habrastorage.org/getpro/habr/upload_files/cd0/1ce/1c5/cd01ce1c5262421d501acb3d2c6bcae0.png)
Проблема:
Часто инженеры при необходимости делать отчет стремятся уместить на одном слайде как можно больше информации: графики, таблицы, технические подробности. Это приводит к тому, что аудитория теряется в потоке данных и не может выделить главного. После такой презентации у слушателей остается ощущение потраченного зря времени, а доверие докладчику падает.
Как исправить:
Сосредоточьтесь на ключевых данных и выводах. Помнить про простое правило: Один слайд — одна идея. Его ужасно хочется нарушать, потому что хочется рассказать много всего и сразу, будто бы так выглядишь весомее и умнее… Но это работает наоборот.
Старайтесь избегать лишних деталей и используйте простые картинки, чтобы акцентировать внимание на главном. Ваши данные должны говорить сами за себя, без необходимости пояснять каждую мелочь.
График - он как анекдот: если его приходится объяснять слушателям - то это плохой анекдот.
Ошибка 2: Отсутствие связного повествования
![](https://habrastorage.org/getpro/habr/upload_files/a63/04b/aac/a6304baac7233196fe0deba5c9e96240.png)
Проблема:
Многие инженеры показывают свои результаты без чёткого порядка, переходя от одного графика к другому без явной логической связи. Это может запутать аудиторию и оставить её без ясного понимания, к чему вы ведете. Структура важна, это у докладчика глаз уже замылился и вам может быть все это понятно и очевидно, зритель видит ваши слайды впервые.
Как исправить:
Представляйте данные как историю с началом, серединой и концом. Объясняйте аудитории, что она видит и почему это важно. Каждый график и слайд должны поддерживать общий нарратив, который приводит к заключению (ведь именно для поддержки вашей точки зрения нам нужны графики, а не просто потому что мы умеем их строить). Хорошо продуманная история поможет удержать внимание и донести вашу идею.
Ошибка 3: Использование сложных или не подходящих графиков
![](https://habrastorage.org/getpro/habr/upload_files/cce/31a/aa2/cce31aaa213ac4640743e09b32e0eb36.png)
Проблема:
Специалисты, особенно, подкованные в работе с данными - любят сложные графики, которые показывают все аспекты проблемы. Однако такие графики могут оказаться слишком сложными для восприятия аудитории, особенно если она не знакома с деталями вашей работы. Докладчику может быть это не очевидно, потому что он уже провел с этими данными много времени и изучил их со всех сторон. Для зрителя они в новинку.
Как исправить:
Выбирайте простые и понятные визуализации (даже если вам это кажется банальным и скучным). Используйте графики и диаграммы, которые легко интерпретировать, даже если человек не обладает глубокими техническими знаниями. Простой, но точный график гораздо эффективнее сложного, если он помогает быстро передать суть.
Ошибка 4: Недостаток контекста
![](https://habrastorage.org/getpro/habr/upload_files/2a5/b33/841/2a5b3384125fa2c0ee0467e421dcf577.png)
Проблема:
Иногда в презентациях не хватает контекста, который помог бы аудитории понять, что означают те или иные данные. Это особенно актуально, если ваша аудитория не так хорошо знакома с предметом обсуждения.
Как исправить:
Предоставляйте контекст перед тем, как показать данные. Объясните, почему эти данные важны и что они означают в контексте вашей работы. Используйте аналогии или простые примеры, чтобы сделать данные более понятными и доступными.
Ошибка 5: Отсутствие обратной связи и доработки
![](https://habrastorage.org/getpro/habr/upload_files/527/8dd/df2/5278dddf2bca51d26007a4576c5fa5b1.png)
Проблема:
Многие специалисты готовят презентации в последний момент, не оставляя времени на проверку и получение обратной связи (это не всегда их вина, но все же). В результате, даже мелкие ошибки могут подорвать доверие к вашей работе. Успех доклада на 80% состоит из подготовки.
Как исправить:
Планируйте свою презентацию заранее, чтобы у вас было время на проверку и получение обратной связи. Покажите свою презентацию коллегам или друзьям и спросите их мнение. Это поможет выявить слабые места и улучшить общую подачу. Покажите своему деду или соседке бабе Нюре. Спросите, что они поняли. Если они ничего не поняли, подумайте, а ваши будущие зрители будут более компетентны в вопросе? Возможно, стоит что-то упростить.
Заключение
Визуализация данных — это мощный инструмент для донесения результатов своей работы до начальства или коллег. Правильно представленная информация может значительно повысить ваш авторитет и помочь достичь личных целей. Избегая описанных выше ошибок, вы сможете улучшить свои презентации и сделать их более убедительными.
Меня давно интересует тема рассказывания историй с помощью графиков и их улучшение для наилучшего восприятия. Многое по этой теме я почерпнула в прекрасной книге Cole Knaflic - Storytelling With Data, а также в ее блоге. Я даже обучала студентов-магистров этому подходу к работе с данными, так как это кажется мне невероятно полезным в современном мире. Я продолжаю изучать эту тему дальше, конца края ей не видя!
Если вы хотите узнать больше про дата-сторителлинг, приглашаю вас в мой канал, посвященный этой теме: Chatting Charts. Буду рада!
Спасибо, что дочитали!
Комментарии (30)
sentimentaltrooper
10.09.2024 07:16+2Когда я был молодым ученым, то послушал лекцию, а после купил книгу - Trees, maps, and theorems, on “effective communicationfor rational minds” - https://www.principiae.be/X0100.php Там и про то как делать слайды и как писать и как говорить. Общий подход основан на идеи соотношения сигнал-шум (замусоренные слайды это «шум» к вашей основной идее - сигналу). Считаю что эта книга мне сильно помогла в карьере, я пытался заставить ее читать сначала своих студентов, потом сотрудников. За прошедшие годы интерес проявила только одна девушка и кажется по другим причинам (и вроде даже не дочитала :()
Но тут еще надо понимать какова цель вашего выступления, кто в аудитории и что вы в идеале хотите от этого выступления. Последний вопрос я себе задаю перед каждой встречей кстати: какой идеальный результат лично я жду по итогу? Заключить контракт? Назначить исполнителя проекта? Разрешить затык? Ничего не жду надо по политическим мотивам посидеть 15 мин из вежливости?
mrtrololoo
10.09.2024 07:16а в переводе есть эта книга?
sentimentaltrooper
10.09.2024 07:16Если честно - не знаю, сильно сомневаюсь. Они по сути "самиздат" и конечно же ПДФку найти не составляет труда (я бумажную купили больше из принципа). Перевод может только если фанатский, но быстрым поиском я не нашел.
eolay Автор
10.09.2024 07:16О да! Прекрасная книга, судя по всему! Надо взять на вооружение, спасибо за наводку. Про сигнал-шум, мне кажется, самая полезная идея. Всегда стараюсь ее использовать. Очень помогает в презентации (особенно, если обучаешь, особенно, если молодых людей).
eolay Автор
10.09.2024 07:16Вот такое же влияние на меня оказала книга Cole Knaflic – Storytelling with Data – я тогда заказала ее почтой из-за рубежа в бумажном виде после того как прочитала электронную версию, настолько она мне понравилась. Конечно, по этой теме пишет много авторов, и я с тех пор прочитала еще несколько книг по теме.
Но именно первая книга мне дала толчок и позволила чуть увереннее себя чувствовать на выступлениях перед людьми. И мне даже со временном понравилось быть экспертом и преподавателем.
Как раз про визуальный шум и мусор, про гештальт принципы (близость, сходство) и визуальные атрибуты (цвет, форма, размер). Очень интересно про то, как это работает на уровне визуальной коммуникации! Со студентами кстати мне это тоже отлично помогало! Надеюсь, они потом тоже применяли эти методы в будущем… (но не уверена).
Вот да! Цель выступления – это, собственно, критический момент, про который многие забывают. А если еще помнить про цель каждой страницы, каждого графика, каждого слайда. Тогда получится намного больше пользы от презентации.
И это не так и сложно, но чудесно работает. Спасибо, что поделились своим опытом!!
turbotankist
10.09.2024 07:16+2И как инженеры теряют влияние на совещаниях? Из-за презентации?
По-моему опыту - кроме инженеров мало кто умеет делать интересные презентации. Поэтому статью можно было бы назвать - как не потерять влияние на совещаниях тем, кто не смог стать инженером, содержание было бы тоже.
eolay Автор
10.09.2024 07:16Инженеры умеют делать отличные презентации, если они этим занимаются. Имхо, работа с презентацией сложных данных и сложных концептов – это очень технический навык, так что инженеру по силу с ним разобраться. Не у всех это сразу получается, но и не всем это нужно.
Полагаю, те презентации инженеров, что вы видели – это были уже опытные инженеры, которые научились интересно презентовать свои данные. Далеко не все так круты.
Advisers
10.09.2024 07:16Интересно о каких инженерах идёт речь?
- если инженер закончил вуз, то диплом он должен был писать... и если вуз технический, то и уметь защищать этот диплом... с графиками, таблицами, формулами и выводами.
...в этом тексте есть некоторые аспекты из элементарных навыков выпускника...
Или речь о ком-то другом? (Инженер - это не продавец и его влияние прямо пропорционально его знаниям и умениям решать задачи, а не качествам "сейлза"; скорее начальник должен понимать - кто в какой ситуации должен выступать, а кто проверять, комментировать, спрашивать, делать критические замечания и перед кем).
А заставлять хороших инженеров выполнять работу, которая им не очень нравится (заниматься продажами) может закончится расставанием по их инициативе... и ещё не известно кто при этом больше потеряет.
eolay Автор
10.09.2024 07:16Ну, я говорю конкретно о своем опыте – я работала в фирме, которая занимается автоматизацией технологических процессов на энергетических объектах. Занималась разработкой рабочей и конструкторской документации (электрическими схемами, чертежами оборудования), внедрением автоматизированного проектирования, базами данных и ведением внутренней статистики процессов.
И у нас чем более квалифицированные инженер – тем чаще ему требовалось не только решать задачки тихо в углу у себя за компом (такие тоже есть, конечно), но и доказывать что-то на совещаниях коллегам, директорам, обучать заказчика и передавать мудрость коллегам. Управлять развитием продукта (может, у кого-то есть отдельные менеджеры такие технические и супер-экспертные, но у нас это инженеры делали).
Так вот, мне в какой-то момент пришлось работать с большим количеством данных – и в них никто кроме меня не разбирался, ни мой босс, ни тем более босс моего босса. А мне нужно было их им всем презентовать – и объяснять, что как, какие перспективы, делать аналитику, рекомендации выдавать. И еще чтобы они меня послушались надо было, а не отмахнулись и сделали какую-нибудь дичь.
Например – выбить обновление критически важного софта иногда не так просто, особенно когда ценник там с большим количеством нулей – приходится писать обоснования и все такое, показывать результаты всех предыдущих внедрений. Круто, если бы за меня это делал какой-то менеджер… но никто в этом ничего не понимал. И получается, мне все равно нужно было бы все это объяснить, показать и доказать сперва какому-то менеджеру тогда… А не напрямую боссам. Сперва у меня плохо получалось, но потом изучила немного матчасть и стало легче.
На самом деле, тоже не бином ньютона, уж инженеры быстро разберутся, что тут как)) На удивление, визуализация данных – а и менно это направление отвечает за работу с данными и компактным их представлением – очень техническая специальность. Хоть это и выглядит иногда «по-дизайнерски», «по-менеджерски», это не так. Не даром, даже ребята из анализа данных и датасаентисты – не пренебрегают визуальными методами анализа данных.
Oneandonly
10.09.2024 07:16Когда я работал инженером, мне было глубоко плевать ( даже грубее), понимают меня на совещании или нет. Тем более я клал огромный болт, на их отчёты, презентации и прочую шелуху, потому, что этих много, а нормальный инженер я был один. Потому каждый должен заниматься своим делом, и рисовать графики, писать отчёты и презентации, в список умений инженера, может не входить, этот юнит для других целей. Теперь как хозяин компании, мне и в голову не придёт, требовать этого от инженеров.
eolay Автор
10.09.2024 07:16У всех свой карьерный путь и задачи на работе. Здорово, что вы могли себе позволить решать, что именно делать, а что нет. И что был специально обученный менеджер, который работал с начальством вместо вас. Круто! Не всем так везет! У нас был небольшой отдел, так что некоторые выполняли по 2-3 функции.
Конечно, не вижу смысла заставлять человека, который не любит и не хочет представлять кому-то свои данные и выводы – заставлять это делать. Но на самом деле, для многих это неплохой толчок карьерному росту – если он метит в продакты или начальство.
Подскажите, а как владельцу компании, вам с клиентами, инвесторами и партнерами не нужно общаться и предъявлять им некоторые идеи, выводы или предложения? Я понимаю, что не во всех бизнесах это требуется. Просто в IT секторе без данных уже мало кому кто на слово верит. Так что приходится учиться их предъявлять.
vova_shv
10.09.2024 07:16Если сделать как в СССР - руководитель должен иметь научно-техническое образование, то рекомендации по презентациям нужно будет писать не для инженеров, а для гуманитарных обезьян!
Imaginarium
10.09.2024 07:16Полегче, пожалуйста, с эпитетами для уважаемых коллег из гуманитарных наук.
Asker1987
10.09.2024 07:16Как делать презентации хорошо описано в книге «iПрезентация. Уроки убеждения от основателя Apple Стива Джобса».
eolay Автор
10.09.2024 07:16По теме очень много классных книг! Эта одна из них - но она скорее про ораторское мастерство и владение вниманием - тоже очень полезно, но мне кажется, не все к такому склонны... Я скорее пишу о том - как данные предъявлять людям. Потому что это более житейская и насущная проблема сейчас... Мне кажется, там не так сложно узнать несколько трюков и методик, чтобы специалист любого уровня мог достойно отчитываться о своих результатах.
Конкретно про визуализацию данных есть книги на русском от Коул Нафлик, Александр Богачев, Альберто Кайро, Эдвард Тафти, Джин Желязны - но у них тоже по разным темам - от журналистики на основе данных, до творческих визуализаций. А если конкретно про донесение мысли - Коул Нафлик мне нравится. Еще хочу почитать:
Better Data Visualization и Better Presentations от Jonathan Schwabish, Info We Trust от RJ Andrews, Effective Data Storytelling: от Brent Dykes. Но это пока на будущее.
Anarchist
10.09.2024 07:16В итоге к хорошим специалистам теряется доверие, а наверх всплывают нетонущие легкие фракции, способные мыслить на уровне начальника-гуманитария. Итог, в общем, налицо.
eolay Автор
10.09.2024 07:16Мне кажется, инженер тоже может овладеть нужными навыками, если ему это видится важным для его работы или карьеры. Тем более, визуализация данных - навык довольно технический - гуманитариям с ним сложнее.
Если нужно просто что-то наболтать - тут да, технарю будет непросто. Но мне кажется, обработка данных и их корректное представление - это все же работа инженера. Другое дело, что потом за него выступать может и менеджер какой-то обученный))) Но работу по визуализации сложных и больших данных он вряд ли сам сделает.
arozhankov
10.09.2024 07:16Автор, так и «Как инженеры теряют влияние на совещаниях»?
Я потратил свое время, чтобы просмотреть малополезный пересказ старой замечательной книги Желязны о том, как делать презентации, но не понял как же инженеры теряют влияние.
Кликбейт?
eolay Автор
10.09.2024 07:16Это мой личный опыт, я допускала все эти ошибки, пока матчасть по теме работы с данными и их презентацией не подтянула))
Заголовок и правда получился вызывающим х) Когда я допускала такие ошибки на совещанях, я ощущала, как теряю влияние в департаменте. А женщине инженеру и так непросто развиваться в мужском коллективе, так что я переживала на эту тему. Не думаю, что эта проблема уникальна) поэтому про это и пишу. Желязны - супер! Вот бы все его почитали... Коул Нафлик в целом про то же)
Полагаю, надо было детальнее расписать каждый пункт с кейсами, а то вышло слишком обще. 8( сейчас тестирую способности разных инструментов, может, про этот прикладной кейс будет полезнее материал)
romanitalian_net
10.09.2024 07:16+1Спасибо за отличную статью. Тема донесена хорошо. Буду рекомендовать коллегам, по необходимости.
Dotarev
Не раскрыта самая главная ошибка.
Ошибка 0 - ошибка менеджера/руководителя проекта, которые свалил на технического специалиста подготовку презентации.
Технический специалист - не универсальный комбайн, если он хорош в своей области - он вовсе не обязан быть хорошим докладчиком и понимать как лучше оформлять презентационные (рекламные?) материалы. Поэтому хороший технический специалист может:
1. Стремиться уместить на одном слайде как можно больше информации.
Показывать свои результаты без чёткого порядка.
и т.д. по списку + много чего ещё.
maxmydoc
Такие специалисты ограничены в своих возможностях. Особенно в карьерных. Сейчас после выпуска из вуза можно стать сразу инженером первой категории. И очень быстро стать ведущим инженером.
Ведущий инженер в разработке должен уметь защищать свои идеи иначе какой он ведущий. Ну и если он хочет новых и интересных проектов то надо уметь коммуницировать.
Пост вообще не про презентации. А про обычный питчинг перед потенциальными заинтересованным людьми.
eolay Автор
Есть специальные книги про важность умения говорить "нет", это тоже навык, который стоит качать. У всех разные ситуации, классно, когда у вас есть специально обученный помощник, который презентует вашу работу за вас. Но не все могут позволить себе такую роскошь.
Эксперты обычно так глубоко работают с темой, что никакой менеджер не сможет за них эти данные понять и представить. Ну или вам придётся делать отдельную презентацию для этого менеджера.
IntegrationF
Пришли к выводу, что надо качать навык коммуникации. То есть софт скилл решает в карьере. Хоть у инженера, хоть у менеджера.
eolay Автор
Согласна, как выясняется, его иногда сложнее качать, чем хард... 8(
travacry
если там такие серьезные данные, и обьем достаточно большой, вы их хоть с презентацией хоть без нее понять не сможете. а занимать время эксперта пустой эмитацией деятельности для нормальной компании крайне не выгодно.
eolay Автор
А зачем показывать все данные? Покажите основные выводы. Экспертиза эксперта для этого и нужна.
travacry
какие выводы? - это обычно два листа в конце, прочитать за 2-3 минуты можно, а вот агрументация это как раз тех составляющая и ей реально будут пользоваться. тут вопрос в том шарят ли люди которым вы будете приводить примеры из своей экспертизы, или вы просто потратите свое время впустую.
eolay Автор
В том и проблема, что часто просто выводы не воспринимаются боссами, а просто данные – им не понятны.
Вот, например, мы стартуем новый проект, и нужно объяснить директору, который нам этот проект поручил, что в сроки мы не уложимся по таким-то и таким-то причинам – выдели еще специалиста такого-то уровня.
Без пруфов директор скажет «что вы ноете – идите работайте», а чтобы пруфы сработали, надо их предъявить и показать так, чтобы директор понял. А он в конкретно вашей теме разбираться не обязан, он может более или менее технически подкован – зависит уже от специфики структуры в организации. И приходится думать, как сжать все данные об объемах работ и проблемах, которые внутри есть - до 5-10 слайдов, которые можно показать директору, чтобы он усилил команду. Под инженером же может быть и продакт – который занимается развитием продукта или ведением проекта, может быть дата-инженер, который выбивает себе дополнительные сервера или демонстрирует проблемы с данными. Не знаю, как в других фирмах, у нас этим занимались инженеры…