Когда в продукте идет одновременно много разных процессов, о которых надо сообщить пользователю, он начинает зарастать тултипами, турами и всплывающими окнами о новых фичах. Кроме этого есть еще уведомления из мессенджеров и календаря. Я попробовала найти научные исследования про то, каким процессам в работе программиста это мешает сильнее всего и какие именно уведомления самые вредные.
Концепция точек прерывания
Когда человека прерывают посреди задачи, он теряет контекст, работоспособность снижается. Но есть моменты менее удачные и более удачные. Довольно много экспериментаторов увлекались тем, чтобы отвлекать людей посреди какой-нибудь сложной задачи и измерять эффект.
Выявили, что люди относительно неплохо переносят прерывания, но только если они в удачные моменты.
Что такое удачный момент? Это момент между двумя крупными этапами (Закончил писать комментарий во время редактирования, нашел нужную фигню и скопировал-вставил). А худший момент — внутри мелкого этапа (непосредственно во время набора текста или просмотра видео).
Вот несколько исследований, где это подтвердилось
Breaking the Flow: A Study of Interruptions During Soware Engineering Activities, 2024
20 студентов делали три вида задачек: писали код на С++, читали код и ревьюили, в процессе чего часть из них прерывали нотификациями. Нотификации были разной важности: где-то научник звал на встречу, а где-то просто напоминали заполнить опрос.
Субъективный стресс был сильнее всего, когда приходил научный руководитель и что-то там требовал, но забавно, что пульс в это время не повышался и время значительно не увеличивалось. А вот от экранного уведомления от тех же лиц увеличивалось.
Появления напоминалок о встречах и всего такого удлиняло выполнение таска почти на 3 минуты и увеличивало сердечный ритм (особенно сильно при программировании, поменьше при ревью кода).
Прерывания сильнее всего мешали более простым и коротким задачам.
65 программистов выполняли задачу на понимание кода на языке FORTRAN, разным группам сыпались уведомления.
Случайный факт дня был самым разрушительным, программисты залипали на нем на 8 минут (не знаю почему так долго), но и на полезной вроде как шпаргалке фортран терялось 4 минуты, а приглашение на экскурсию отнимало 43 секунды.
Надо сказать, что качество понимания кода при этом не пострадало, но пользователи говорили, что усилились напряжение и фрустрация.
Просто забавный график, когда программисты отвлекаются на уведомления, а когда нет. В принципе видно, что большинство знают, как переключение фокуса мешают задачам, требующим концентрации, и не открывают в это время чаты. Можно показывать менеджерам, если жалуются на то, что вы долго отвечаете в слаке
Короче, понятно, что прерывать людей в середине задач плохо. Почему это так работает, объясняет механизм запоминания целей. И почему сильнее страдают микрозадачи.
Task Interruptions in Requirements Engineering: Reality versus Perceptions!,2017
Анализ показал, что самоинициированные прерывания (когда человек отвлекается сам, например, чтобы проверить почту) оказываются более разрушительными, чем внешние прерывания. Однако опрос показал, что разработчики воспринимают внешние прерывания (коллеги, менеджеры) как более мешающие. В Task Interruption in So•ware Development Projects точно такой же вывод, кстати. Так что может не стоит постоянно на коллег пенять.
Так же получилось, что задачи, связанные с работой над требованиями (сбор, анализ, валидация), наиболее уязвимы к прерываниям по сравнению с программированием, тестированием или развертыванием.
Концепция памяти целей
Memory for goals: an activation-based model
Теория памяти целей (Memory for Goals), разработанная Альтманном и Трафтоном (2002), — это когнитивная модель, объясняющая, как наш мозг удерживает, теряет и восстанавливает информацию о текущих задачах при прерываниях.
В изначальной статье людей просили выполнять несложную работу — копировать и вставлять данные, и в середине этого процесса выводили им окно, где надо было делать совсем уж какую-то ерунду простую — вводить все подряд на клавиатуре. Ну и замеряли потом, сколько им нужно было времени, чтобы вернуться опять к работе.
Выводы такие — как только мы перестаем заниматься задачей, уровень активации этой цели начинает быстро угасать со временем. Чем дольше длится прерывание, тем сложнее вспомнить, на чем вы остановились.
И тут очень важный параметр — лаг прерывания, это время между сигналом о прерывании и самим прерыванием. Он нужен, чтобы человек мог подготовиться к возврату: либо наметить следующий шаг («когда вернусь, нажму вот эту кнопку»), либо мысленно повторить то, что только что было сделано.
То есть, если вы успели зацепиться взглядом за какой-то элемент интерфейса до того, как вас отвлекли, вернуться будет в разы легче.
Я думаю, именно поэтому на сложные задачи прерывание влияло меньше — в них больше визуальных якорей, к которым можно вернуться, а у маленькой задачи такого якоря нет, поэтому прерывание ее и руинит. И поэтому же прерывания живым человеком могут быть не такими фатальными — пока он с вами болтает, на экране остаются зацепки, помогающие вернуться к задаче, а если переключиться на мессенджер — то теряются.
Подробнее про саму теорию памяти целей я пишу в тг.
Выводы
Совсем избавиться от уведомлений вряд ли получится. Коллегам нужны ответы на какие-то их вопросы, а система вроде как должна сообщать пользователю о процессах, у которых нет индикаторов на текущем экране. Из того, что можно легко сделать самому для себя — заканчивать мелкое дело, прежде чем открывать нотификацию — допечатать до точки, скопировать-вставить и т.д. Потому что в большую задачу получится вернуться, а микрозадача точно из головы вылетит.
С точки зрения разработки продукта лучше всего для показа нотификаций выбирать момент, когда пользователь закончил кусочек работы и остановился передохнуть (вот тут живой эксперимент на японском яху), при этом оставлять ему визуальную подсказку о том, на чем он остановился, нотификации выдавать пачками, а не по одной, и заменять навязчивые туры по интерфейсу геймифицированной системой с задачками.
В какой-то старой статье была разработка такой системы, которая следит, чтобы не пулять нотификации, пока пользователь печатает или что-то активно шевелит, а ждет небольшого перерыва. Жалко, вроде не запустилась.
Автор: limmm
