Тут какие-то чуваки исследовали еще один феномен разницы восприятия себя и других. Большинство людей думают, что другие живут более насыщенной и активной жизнью, чем они сами. Причем это касается всех социальных групп.
Связано это с тем, что:
- Люди постят только самый интересный контент. Никто не постит фото вида “я читаю книгу”, все постят “смотрите, я на краю вулкана”. Если вы читаете книгу, а рядом устроили вечеринку, то ребят на вечеринке слышат все — а вас и других ребят с книгой — нет.
- Мы следим за большим количеством человек, среди них всегда есть кто-то с ОЧЕНЬ активной жизнью (более того — мы ХОТИМ следить за такими ребятами). Мы всегда вспоминаем про таких ребят первыми, поэтому сравниваем не со средним, а с максимумом.
Вообщем жизнь у нас не хуже чем и у остальных — даже лучше, скорее всего.
Кстати забавная цитата из этого исследования про сравнения себя с другими:
В местной локальной Фейсбук группе случился небольшой скандал. У нас в городе открылся новый пафосный ресторан “авторской кухни”. Туда сходил шеф-повар другого нашего локального (хорошего) ресторана и написал справедливо разгромный отзыв.Somewhat ironically, being a peripheral member of an extremely socially active entourage may leave a person feeling worse off about her social life than being an average member of a less socially active group of friends.
Что интересно, потом в комментарии пришли ребята, которые стали говорить, что это неправильно. Что должна быть “корпоративная этика”, “приличия”, “не выносить сор из избы” — то есть негативный фидбэк должен был дан исключительно приватно.
Я это вспомнил в связи с другой новостью. Прошедший 2017 год был самым безопасным для гражданской авиации. И было 0 (ноль) крушений у массовых коммерческих рейсов.
А если посмотреть на количество успешно перевезенных пассажиров на одну смерть от полетов, то там тоже все очень хорошо. Где-то с начала 90-х годов все начало сильно улучшаться.
Это очень круто. Конечно это связано с улучшением техники: самолеты, оборудование, вспомогательные системы — все сильно улучшилось.
Но думаю это еще связано с тем, как к происшествиям относятся в авиа-индустрии. Каждое происшествие регистрируется (есть даже возможно репортать их анонимно), разбирается и ищутся корневые причины (“post-mortem”). Культура “давайте говорить о наших проблемах и искать решения”, а не культура замалчивания, чтобы сохранить лицо (как например есть в медицине).
Поэтому авиа-индустрия постоянно улучшается: технически, улучшают процессы, даже такие вещи как коммуникация между пилотами. Все это приводит к повышению безопасности.
А культура сохранения лица, когда все боятся говорить о своих проблемах, когда они обсуждаются только “среди своих”, ничего не улучшает.
Так что важно, когда:
- О проблемах принято говорить вслух и никто этого не боится. Для этого за проблемы не должны наказывать, информация о плохих новостях должна привествоваться.
- Проблемы должны разбираться на честном пост-мортеме, когда находятся корневые причины (классическое правило “пяти почему”) и планируются исправления.
Про это хорошо написано в отличной книге “Принцип “черного ящика” Мэтью Сайеда. Очень рекоммендую ее.
На русском: https://www.ozon.ru/context/detail/id/137593779/ и https://www.litres.ru/metu-sayed/princip-chernogo-yaschika-kak-prevratit-neudachi-v-uspeh-i-snizit-risk-nepopravimyh-oshibok/
На английском: https://www.amazon.co.uk/Black-Box-Thinking-Surprising-Success/dp/1473613779
О проблемах принято говорить вслух и никто этого не боится. Для этого за проблемы не должны наказывать, информация о плохих новостях должна привествоваться.
Главная проблема тут в cамом себе же в первую очередь. Критику мы не любим. Когда нас критикуют, первая реакция — защититься или атаковать в ответ. А не разобраться, что к чему и “пост-мортемы” проводить.
Особенно если мы не чувствуем себя в безопасности: надо сохранить лицо, очень важно мнение окружающих (а оно нам важно — что бы мы себе не говорили!), боимся, что критика повлечет за собой смену какого-то статуса (социального, рабочего, etc.)
Я в себе стараюсь это явно отслеживать. Можно все эти правильные вещи знать, но первые свои внутренние реакции на критику все равно будут неправильными. Я стараюсь отлавливать их и явно себя переключать на рациональные вещи: “ОК, это полезная вещь, как она может нам пригодится?” (получается не всегда)
Ну и обратный подход: если надо кому-то дать негативный фидбэк, надо убедиться, что он чувствует себя в безопасности.
Сформулировал важную для себя мысль про A/B тесты.Есть два разных подхода к A/B тестам: для оптимизации существующей концепции/продукта или для создания новой.
Обычно A/B тесты выглядят так. Мы формулируем гипотезу, почему какое-то изменение улучшит нашу штуку. Запускаем тест, смотрим. Сработало — отлично, внедряем. Не сработало — формулируем новую гипотезу.
Пример: “если добавить фотографии существующих клиентов на сайт — люди будут лучше регистрироваться”.
Этот подход хорошо работает, когда надо оптимизировать уже существующую концепцию. В рамках существующей концепции мы находим локальный максимум.
Проблема в том, что этот подход не поможет найти новые и более лучшие концепции. Потому что все наши гипотезы УЖЕ лежат в рамках существующей концепции (старого продукта).
Чтобы находить новое, A/B тест и его гипотеза должны быть совсем другими, вне существующего фрейма. Такие гипотезы расширяют поиск “максимумов” и позволяет найти что-то совершенное новое, что качественно лучше старого.
Чтобы определить, подходит ли гипотеза под поиск нового, можно ответить на следующие вопросы.
1. Догадываемся ли мы о результате теста?
Удивит ли нас его какой-то один конкретный результат, а другой не удивит? Если да — гипотеза в рамках существующей концепции, “оптимизаторская”.
Пример: когда мы формулируем гипотезу “фотографии могут улучшить конверсию”, мы уже предполагаем ответ. Мы уже знаем, что лица важны для людей и уже более-менее уверены в результате. Если этот тест сработает — мы не будем удивлены. Если не сработает — будем сильно удивлены.
А вот обратный пример: гипотеза “посылать посетителя не на сайт, а в мессенжер-бота, где посетитель сможет получить данные”. Мы не можем предположить, какой вариант выиграет. Победа каждого варианта будет интересной и удивит. Значит гипотеза в рамках новой концепции.
2. Дает ли нам важную информацию и выигрыш и проигрыш теста?
A/B тест и гипотеза тестируют новую концепцию/продукт, если любой результат теста — негативный или позитивный дает нам важную и полезную информацию о мире, продукте, наших пользователях. Полезную, это значит на основе этой информации мы можем строить новые гипотезы для новых концепций.
Если полезную информацию дает только проигрыш теста или только выигрыш — это гипотеза в рамках существующей концепции, “оптимизаторская”. Если проигрыш и выигрыш теста дают только информацию о конкретном поведении в конкретных условиях — тоже.
Пример: если гипотеза “фотографии улучшают конверсию” выиграет, мы узнаем, как улучшить конверсию нашего сайта (это хорошо). Но если проиграет — мы не узнаем ничего. Мы будем знать, что на конкретном сайте конкретные фотографии не сработали — но почему не сработали — не знаем. Даже выигрыш нам дает только “конкретные” знания для “конкретной ситуации”. Мы не можем использовать новые знания, чтобы сформировать какую-то новую сильную гипотезу.
Обратный пример: гипотеза “посылать посетителя не на сайт, а в мессенжер-бота, где посетитель сможет получить данные”. И выигрыш и проигрыш гипотезы дает нам важную информацию. В первую очередь потому, что мы будем лучше понимать наших пользователей — “они на самом деле любят мессенжеры” или “они совсем не понимаю мессенжеры!”. Во вторую — потому, что ЛЮБЫЕ данные от этого теста, неважно провалился он или нет, можно использовать для формирования новой гипотезы / теста. Мессенжер-бот не зашел — а мы можем посмотреть как люди там общались и сделать новую версию, которая будет сильно лучше. Мессенжер-бот зашел — с нашим сайтом видимо проблемы, давайте его переделывать.
Итого, резюмирую.
1. Есть два вида A/B тестов: для оптимизации существующих штук/концепций/продуктов и для создании новых 2. Они не лучше и не хуже друг друга — у каждого свое применение. Оба инструмента хороши для своих задач. 3. Тесты для “оптимизаций” сильно помогут улучшить существующую концепцию (найти “локальный максимум”), но не помогут найти новую. Будет ошибкой пробовать “оптимизаторские” тесты, когда мы создаем новый продукт или нужно что-то совершенно новое. 5. Тест на новую концепцию должен как правило быть таким:
- мы не можем предположить результат, и выигрыш и и проигрыш нас удивят одинаково.
- и выигрыш и проигрыш принесут полезную и важную информацию для формирования новых “не оптимизаторских” гипотез.
Например.
Правда иногда там начинают ворчать на нормальные вещи и дизайнерские решения. Если тебе решение не нравится или ты его не понимаешь — оно еще не мудацкое. Например вот следующие штуки там были запощены, но я их считаю вполне нормальными решениями.
Интересно представить, что бы изменилось в обществе и мире, если бы оказалось (и это было бы научно доказано), что дельфины разумны (но мы этого не понимали, так как они не построили технологическую цивилизацию — зачем она им?).
Какая была бы реакция и что бы изменилось у всех.
Кстати вспомнил историю, что в прошлом с дельфинами проводили вообще интересные эксперименты. Одни чуваки хотели научить их говорить, поэтому взяли лабораторию, залили водой этаж и поселили там одного дельфина по имени Питер с девушкой. Идея была, что девушка(Маргарет Ловатт) будет проводить с ним все свое время (то есть она спала там же — в воде с дельфином) и научит его английскому, как мама ребенка.
В результате дельфин начал заниматься сексом с Маргарет (ну почти), а другим дельфинам стали давать LSD. Потом проект закрыли, Питера-дельфина разлучили с Маргарет и он покончил с собой.
Ric O’Barry corroborates the use of this word. “Dolphins are not automatic air-breathers like we are,” he explains. “Every breath is a conscious effort. If life becomes too unbearable, the dolphins just take a breath and they sink to the bottom. They don’t take the next breath.” Andy Williamson puts Peter’s death down to a broken heart, brought on by a separation from Lovatt that he didn’t understand. “Margaret could rationalise it, but when she left, could Peter? Here’s the love of his life gone.”
Занимательная и грустная история: https://www.theguardian.com/environment/2014/jun/08/the-dolphin-who-loved-me
Матвей, мой коллега, написал пост про 5 самых крутых книг, которые он прочитал в 2017: https://www.facebook.com/makfruit/posts/1920487587991977Даниэль Канеман. Думай медленно… Решай быстро (Daniel Kahneman. Thinking, Fast and Slow)
Все наши решения в несколько слоев окутаны когнитивными искажениями и систематическими ошибками. Источников для искажений сознания много, и это не про наркотики или пропаганду. Книга очень подробно разбирает, как работает мозг при принятии решений, и советует, как предупреждать ошибки в своих действиях и видеть их в чужих. Автор рассказывает про практики и инструменты для принятия более верных решений (например, premortem — очень интересный приём). Круто. Отличная книга для всех, вне зависимости от рода занятий.
…
Kathy Sierra. Badass. Making users awesome)
За последние несколько лет это максимально эффективное, что я читал про создание продуктов и сервисов. У книги очень высокий КПД — отношение полезных идей/советов к объему текста. Вместо популярного для подобных тем подхода “У меня родилась мысль, и я сейчас её объясню за 350 страниц”, здесь автор как будто делает “elevator pitch”: ёмко и без лишней воды выдаёт идею, добавляет иллюстрацию, шутку, вывод — и поехали к следующей главе. Очень рекомендую всем, особенно тем, кто как-то причастен к созданию и продвижению продуктов/сервисов.
Отличный список там.
Допустим есть 21-и этажный дом. В этом доме есть лифт. Когда вы вызываете лифт, он едет с этажа на котором остановился в последний раз.Всем приятно, когда нажимаешь на кнопку вызова, а лифт уже на этаже. Не ждешь, заходишь и сразу едешь.
Как максимизировать это удовольствие для всех жителей дома? (оставим в сторону сложные схемы с “машинное изучение паттернов использования” и т.д.)
Одна из штук, которая приходит в голову — после использования лифт всегда должен приезжать на первый этаж. В этом случае вызов лифта с лестничной площадки это всегда ожидание (он не откроется сразу), но когда возвращаешься домой — он откроется сразу. Это ожидаемая приятность, особенно когда возвращаешься вечером и усталый.
С другой стороны схема, когда лифт всегда ждет на этаже на котором остановился в последний раз, добавляет элемент случайности. Случайный и негарантированный выигрыш, когда лифт на твоем этаже и открылся сразу, будет ощущаться сильно приятнее, хоть и реже (так как дофамин в первую очередь вырабатывается на потенциальное вознаграждение, а не на само вознаграждение)
Может в 80% случаев ехать на первый этаж и останавливаться там, а в 20% ехать на случайный этаж из 20-и остальных? Шансы 1 к 99, что при вызове на своем этаже лифт сразу откроется — очень редко и поэтому очень приятно (возможно). Как правило всегда открывается сразу на первом этаже (в 80% случаев), чтобы быть ожидаемо. Небольшая негарантированность может добавить приятности.
🤔
Тут на Гаваях разослали всем оповещение, что летит ракета и “мы все умрем”. Опровержение прислали только через 40 минут. Эти 40 минут все люди были уверены, что им конец. Интересно, что там у них эти 40 минут происходило. Думаю еще мы про это узнаем и может даже снимут фильм.
А вот почему это произошло.
Around 8:05 a.m., the Hawaii emergency employee initiated the internal test, according to a timeline released by the state. From a drop-down menu on a computer program, he saw two options: “Test missile alert” and “Missile alert.” He was supposed to choose the former; as much of the world now knows, he chose the latter, an initiation of a real-life missile alert.
“In this case, the operator selected the wrong menu option,” HEMA spokesman Richard Rapoza told The Washington Post on Sunday.
Да, дизайн и интерфейсы важны (вся статья).
Ну и из личного опыта. Если в базе завести булевское(правда/ложь) поле, которое может содержать значения “t” и “f” (от true и false), то обязательно рано или поздно выстрелишь себе в колено.
(Добавлено позднее)
Я писал раньше про историю на Гаваях, когда по ошибке запустили настоящее оповещение о ракетной атаке, вместо тестового. Все тогда объясняли причину тем, что интерфейс был очень неудобен и позволял ошибиться.
Оказывается дело было немного не так и сложнее. Тренировку решили провести в новое необычное время — когда менялись смены. Руководитель ночной смены сказал о тесте руководителю дневной, но руководитель дневной подумал, что тест только для ночной смены (хотя он был для дневной), поэтому он не присутствовал рядом со свой сменой, когда это все случилось.
Когда начался тест, то по телефону голос сказал ““exercise “exercise “exercise”, но потом был зачитан текст от реальной атаки с “this is not a drill”. Сотрудник не услышал первую часть (как он говорит) и послал реальное оповещение.
Как обычно — большой факап это всегда комбинация мелких штук, каждая из которых не заваливает систему, но все вместе вызывают большую проблему.
Подробнее можно почитать в статье и полном репорте об инциденте.
Отличное эссе про “хуже это лучше”: http://dreamsongs.com/RiseOfWorseIsBetter.htmlТам рассказывается, что когда хочется сделать все правильно, то дизайнер (тут имеетcz ввиду дизайнер в общем смысле — создатель продукта, дизайнер API и так далее, например в тесте про дизайнера языков программирования) думает про правильные вещи: простоту, правильность, согласованность, полноту. (в тексте interface не означает именно графический интерфейс, а скорее интерфейс взаимодействия с API, например)
То есть хотят вот такую идеальную ситуацию:
- Simplicity — the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
- Correctness — the design must be correct in all observable aspects. Incorrectness is simply not allowed.
- Consistency — the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
- Completeness — the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
Подход “хуже это лучше” немного отличается. Он вот такой:
- Simplicity — the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
- Correctness — the design must be correct in all observable aspects. It is slightly better to be simple than correct.
- Consistency — the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
- Completeness — the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Автор заявляет, что хоть этот подход и хуже, но позволяет продуктам чаще выживать и доказывает это на примерах.
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing. … A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn’t.
Эссе потрясающее, но с одной штукой я не согласен. Считаю, что в большинстве случаев, особенно если взаимодействие с конечным пользователем, надо делать интерфейсы проще за счет усложнения невидимой имплементации. То есть “работают машины — отдыхает человек”.
Интересное и короткое (меньше минуты) видео про восприятие скорости загрузки в зависимости от вида прогресс-бара.Некоторое время назад пару людей в моей ленте расшарили эту картинку c посылом “смотрите, что техническая поддержка себе позволяет”.
Это интересно и вот почему.
Одна из способностей, которые стоит в себе развивать это умение замечать, когда ты озадачен и в замешательстве. Когда что-то не так и нельзя сразу объяснить что именно. Такие замешательства надо стараться замечать. Наш мозг всегда старается объяснить несостыковки, придумать готовую историю, подогнать все под удобный шаблон. Если заметить в себе озадаченность, проговорить ее себе: “я озадачен, почему же это?”, то можно посмотреть на ситуацию свежим взглядом.
Заметил замешательство или озадаченность → осознал и проговорил ее → начал понимать, что не так, съехал с шаблонных рельс.
Какова вероятность, что это ПЛОХОЙ саппорт и сервис вот так и пишет “нам очень жаль, мразь!”. Вероятность очень мала. Бывают неадекваты, но тогда бы и весь коммент был неадекватен. А общий нормальный коммент с абсолютно неадекватным приветствием странен и вызывает озадаченность.
Так что было так: у человека было в системе имя “Мразь”. В ответе невнимательный сотрудник поддержки не обратил внимание, в куче сервисов например в текст имя подставляется сразу. Потом клиент сменил имя — в системе оно сменилось, в тексте нет.
Получилось, что получилось. Это смешно и есть что улучшить, но те, кто показывает эту картинку как пример “о боже, ужасный саппорт” — поленились подумать.
Если история вызывает замешательство — или в нашей модели мира или в истории что-то не так.
Чуваки рассказывают, что скорее всего есть два типа самоконтроля: self-control and cognitive control. Умение отложить немедленное вознаграждение ради бОльшего в будущем и умение сфокусироваться на задаче, игнорируя отвлечения. Эти штуки работают по разному в мозгу и их можно развивать отдельно друг от друга: https://digest.bps.org.uk/2018/01/22/self-control-and-cognitive-control-are-not-the-same-thing/(мысли вслух)Понять причины конкретного действия ≠ оправдать конкретное действие.
У действий иногда нет причины, попытки строить историю/нарратив часто ошибочны.
Мир несправедлив и случаен. Кармы не существует.