Гуманный аналитик

⚡ TechCommunity Fest 2026 (TCF2026)

Я сегодня на TechCommunity Fest. Событие не для широкой публики, но о нём точно стоит рассказать.

📍 Москва
🎤 40 спикеров
🛤️ 5 треков
👥 300 очных участников
💻 10 000+ онлайн

Конференция проходит только для сотрудников Сбера. При этом на площадку могут попасть 🔐 лишь активисты профсообществ и лучшие специалисты по персональным приглашениям — понимаю, звучит нескромно, но это официальная позиция организаторов 🏆

В Москву я прилетел накануне, так что успел отдохнуть. Сегодня курсирую между докладами и стендами, выбирая самое интересное. И если с использованием собираемого на стендах мерча всё предельно понятно, то материалы докладов точно предстоит ещё переваривать.

#события #сбер #ai

📕 "Ikigai: The Japanese Secret to a Long and Happy Life" by Héctor García and Francesc Miralles

Данная книга давно ждала своего часа, и вот я до неё-таки добрался.

🌟 Содержание. "Икигай" обещает раскрыть секрет долголетия и счастья, основанный на японской философии. Авторы исследуют жизнь жителей Окинавы, одного из регионов Японии, известного многим своими долгожителями. Читателям предлагается следовать принципам Ikigai (生き甲斐) — поиску смысла жизни через баланс и чувство цели. И тогда всё будет хорошо.

📣 Критика. Несмотря на привлекательную подачу материала, книга страдает от ряда недостатков.

🛑Во-первых, Гарсия и Миральес, как мне кажется, упрощают философию Ikigai до рассказов о быте жителей Окинавы и до набора советов и физических упражнений.

🛑Во-вторых, научные доказательства, подтверждающие эффективность предложенных советов, практически отсутствуют. Вместо этого читатель получает общие рекомендации, многие из которых затруднительно применить в реальной жизни.

Авторы приводят обширные цитаты, фрагменты интервью с долгожителями из Окинавы. Но вот что явно некорректно: жители сами называют причины своего долголетия. Учёные со всего света хотели бы знать ответы фундаментальный вопрос долголетия, но авторы берут на веру сказанное кем-то. Убеждён, это не показательно, это ошибка выжившего (во всех смыслах).

🛑И, наконец, в-третьих, статистические данные, которые приводятся в главе VII, считались релевантными на момент первого выхода книги, но по прошествии десятилетия таковыми уже не считаются. Более того, в интернете вы без труда найдëте не просто критику, но и результаты исследований, опровергающие упомянутую статистику, феномен долголетия и наличие "голубых зон" долголетия в целом. Всё это, если кратко, — следствие ошибок в метриках и результат манипуляций с данными🤷‍♂️

💡 Выводы. Книга может заинтересовать тех, кто ищет вдохновение для саморазвития и стремится улучшить качество своей жизни. Она предлагает задуматься о балансе между различными аспектами существования и найти собственный путь к счастью.

Поможет ли это дожить до ста лет — сомневаюсь, но о здоровье и психологическом равновесии думать всё же надо.

И ещё момент: если читать на английском, как сделал я, то это неплохая практика языка. Тем более что бóльшая часть книги читается довольно легко.

#книги #саморазвитие

Друзья, поздравляю всех с Днём системного аналитика! 🥂

Пусть все требования будут чёткими, юзкейсы — полными, а стейкхолдеры никогда не отрываются от реальности. Желаю идеальных схем, стабильных контрактов и чтобы кофе никогда не остывал во время долгих созвонов с заказчиками. И пусть критические баги обходят ваши системы стороной!

Ура! 🍾

📣 Выложены записи трека "Архитектура и анализ" CodeFest'16. Смотрим! 📺

#события #codefestru #видео

🤖 Новая веха: заказчик принëс нейрослоп

На днях произошло событие, которое без преувеличения можно считать новой вехой в моей профессиональной деятельности. А может, и мира в целом — за всех не знаю. 😅

Но прежде чем перейти к сути, небольшой контекст.

Все, кто занимается инженерией требований, знают, что заказчики могут формулировать свои ожидания неточно, упускать детали, полноту, высказывать трудновыполнимые или вообще нереализуемые требования. Это нормально, к этому мы привыкли, с этим мы работаем.

В свете тотального распространения ИИ за последние месяцы мы также перестали удивляться тому, что специалисты разного профиля используют LLM в своей работе. Например, разработчики пишут код, правят баги. Ну, а теперь про нечто новое...

Мне заказчик принёс 18-страничный документ💪 с описанием требований к реализации нужной ему функциональности. Я довольно быстро понял, что текст создан нейронкой. Если не вдаваться в суть, выглядит более чем солидно для MVP, но именно за суть мы и получаем свою зарплату.

Требования от нейронки — это боль, скажу я вам. Вот несколько иллюстраций этого безобразия.

🌊 Море воды. В документе было налито столько "воды", что запросто можно было вызвать паводок в отдельно взятом регионе нашей страны. Продраться к смыслу сквозь это буйство текста просто нереально.

🔄 Противоречия. Ряд тезисов не бьëтся между собой. Например, в начале говорится, что алгоритм должен уметь работать со всеми вариантами расчёта (такая формулировка сама по себе уже плоха, ибо неограничена и непроверяема), а уже через несколько листов упоминается, что "для неподдерживаемой формулы расчёт недоступен до реализации и проверки".

🪄 Галлюцинации. По тексту документа много раз встречается призыв "не выдумывать". Однако, "не выдумывать" — это скорее про галлюцинации LLM. Именно человек такое может написать нейронке в промпте...

🚪 Цифровой этикет. На странице 3 говорилось: "После... один раз аккуратно предлагает переход к формированию...". То есть мы должны программировать цифровую моторику? Алгоритм должен тактично постучаться в окно из GUI, прежде чем войти? А если пользователь проигнорирует, оно должно тихо извиниться и прикрыть за собой дверь?😂

📏 Расползающиеся рамки. Границы проекта стали размываться за счёт появления деталей, ни разу не затронутых заказчиком при личном общении. Более того, часть требований оказалась технически избыточной (например, выставлялись некоторые требования к логированию, хотя платформенное решение априори предъявляет другие).

❓ Термины-пустышки. В тексте среди "требований" упоминаются слова, которые никак не раскрываются. Так, в пункте о возможной недоступности сервиса можно прочитать: "Клиенту указывается дата справки". Что за справка? Может, нарколога? В общем, я так и не нашёл ответа.

На этом, пожалуй, остановлюсь, дабы не травмировать вашу психику. 😉 Но хочу напоследок кое-что отметить.

❗️Как мы видим, доступность нейронок сыграла злую шутку. Бизнес-заказчик быстро получает вроде бы правдоподобный документ, но критически вчитываться в него стимула уже нет. Пробежал глазами — вроде, то, что хотел. Но на деле это далеко от истины. Свои ожидания надо формулировать самому, и вряд ли когда-нибудь будет по-другому.

#требования #ai

Моё настроение сегодня как нельзя лучше представлено на этом ролике.

#юмор #методыуправления #менеджмент #жиза

😡 Не сломаться по щелчку пальцев

Сегодня начну с истории, которая произошла несколько лет назад. Коллега сидел над разбором инцидента: смотрел документацию, изучал логи и то и дело задумчиво повторял: "Компатибл…" Но в какой-то момент он воскликнул: "Компатибл-компатибл… Нифига не компатибл!" 🪄

Оказалось, что причиной проблемы было нарушение совместимости форматов данных. То ли какое-то из ранее предусмотренных полей было удалено, то ли переименовано — детали стёрлись в памяти.

Но я вспомнил эту историю неспроста. В последние дни занимаюсь решением, в котором используется несколько независимых кластеров Kafka от разных команд. И надо заранее подумать, как уберечь систему от таких поломок.

Вопросы освежаю сам для себя и заодно хочу тезисно зафиксировать и поделиться с вами. Погнали! 😂

-ˋˏ✄┈┈┈┈┈┈┈┈┈┈┈┈┈┈

В распределённых системах выделяют два базовых подхода: обратная совместимость (backward compatibility) и прямая совместимость (forward compatibility). А когда нарушаются правила контракта, пора поднимать версию.


🔶 Версионирование

Версионирование — это единственный способ договориться об изменениях в контракте между независимыми сервисами. Без него вы никогда не узнаете, кто именно пишет или читает данные по устаревшим правилам. Но это не всё. 🤷‍♂️

Даже если весь код лежит в одном репозитории и им владеет одна команда, брокер сообщений всегда создаёт временную "дыру" 🕐 между записью и чтением. Сервис-писатель может быть переведён на новую схему сегодня, а старый сервис-читатель дотянет до следующего релиза только через месяц.

✅ Что с этим делать
Идентификатор схемы (Schema ID) или номер версии формата передаётся в заголовках сообщения или кладётся в полезную нагрузку. Де-факто стандарт для Kafka — проверка через Schema Registry, но финальная реализация зависит от архитектурных решений конкретной компании.


🔶 Совместимость

▌ 🔙 Обратная совместимость (Backward)
Приложение на новой версии должно уметь читать данные, созданные по старой схеме.

✅ Что можно делать со схемой:
— удалять поля;
— добавлять новые необязательные поля;
— делать обязательные поля необязательными.

❗️ Кто обновляется первым: читатели (консьюмеры). Писатели (продюсеры) могут подождать.

▌ 🔜 Прямая совместимость (Forward)
Приложение на старой версии должно уметь работать с данными, созданными по новой схеме.

✅ Что можно делать со схемой:
— добавлять новые поля;
— удалять необязательные поля;
— делать необязательные поля обязательными.

❗️ Кто обновляется первым: писатели (продюсеры). Читатели (консьюмеры) могут подождать.

#интеграции #kafka #api #сервисы #форматы #данные

⚡️ Новый HTTP-метод QUERY

Сегодня День знаний, и по этому случаю у меня есть подходящая новость. Кто-то мог о ней прочитать ранее, но для многих она точно прошла незамеченной.

В июне опубликован RFC 10008 "The HTTP QUERY Method". Как следует из названия, в нашей "обойме" появился новый HTTP-метод QUERY. Он безопасный, идемпотентный и кэшируемый. ✔️

По своей семантике QUERY — это метод для чтения данных, однако, в отличие от привычного GET, он поддерживает тело запроса. Это обстоятельство вкупе с другими совсем скоро позволит создавать более читабельные запросы и уйти от практики использования POST не по назначению.

За более подробной информацией о QUERY стоит обратиться непосредственно к RFC 10008. Ещё вариант — эта статья на Хабр (иллюстрация к данному посту как раз взята оттуда).

🌶 Да, кстати, теперь вы знаете, какими знаниями блеснуть на ближайшем собеседовании. 😎

#интеграции #сервисы #собесы

Друзья, минутку внимания!

Если вы или кто-то из ваших знакомых собираетесь на сентябрьский TeamLead Conf за свой счёт, то для вас есть небольшой бонус.
 
Коллега поделилась промокодом, который даёт скидку 10% от стоимости билета.

🎟 Промокод: SHAKHTARINA
 
🗓 Программа конференции: здесь.

#события #анонсы #менеджмент #ai

📖 "Краткий курс логики: Искусство правильного мышления" Гусева Д.А.

🖋 Ремарка. Книга адресована учащимся школ с углублённым изучением предметов социально-гуманитарного цикла, гимназий и лицеев. Несмотря на то, что я не попадаю ни в одну из этих категорий, дружить с логикой кажется вневозрастной необходимостью.

🌟 Содержание. Книга представляет собой краткое изложение формальной логики — науки о формах и законах правильного мышления; науки, созданной Аристотелем 2500 лет назад.

Книга направлена на
развитие навыков критического и последовательного мышления. Как отмечает сам автор:

... практически мы используем логику задолго до того, как начинаем её теоретически изучать... владея ею интуитивно и повседневно её используя, мы изучаем логику... чтобы владеть ею намного лучше и использовать более эффективно.

Язык книги простой. Автор избегает излишней наукообразности, использует множество примеров из жизни, истории и литературы, что делает материал доступным для восприятия. В частности, автор приводит формулировку для иллюстрации неоднозначности:

Безбилетный проезд и бесплатный провоз багажа наказывается штрафом

И, надо признать, при разработке документов подобные ситуации могут возникнуть у каждого (об этом я уже рассуждал чуть раньше).

Текст книги хорошо структурирован, каждая глава логически вытекает из предыдущей, поэтому читать следует строго последовательно.

🍯 Ложка дёгтя. В данной работе не обошлось без ляпов. Например, на стр. 29 говорится:

Если же между первой и второй частью определения ставится знак ">" или "<", то оно является ошибочным — широким или узким соответственно.

Здесь стоит поменять местами либо математические знаки сравнения, либо слова "широким" и "узким". Иначе не сходится. А чтобы полностью исключить любую возможность для недопонимания, фразу можно переформулировать в таком виде:

Определение является ошибочным — узким, если первая часть больше второй (знак >), и широким, если первая часть меньше второй (знак <).

Другие ляпы.
🔸В таблице 3 в диаграмме Эйлера, иллюстрирующей пересечение для совместимых понятий, не закрашена общая часть.
🔸В таблицах 4 и 5 для суждения E правильной подписью будет: "S+ P+".

💡 Заключение. Логика мышления, конъюнкция, дизъюнкция, дедукция, индукция и пр. — всë там. И даже если кажется, что это всё уже слышал, то вдумчивое прочтение точно 🎯 даст пищу для размышлений и сформирует фундамент для дальнейшего развития. Лично я и четверти терминов не запомнил (их в книге даётся много), но понимать точно стал больше.

Неочевидный вывод. Если выстраивать список дисциплин для изучения IT-специалистом, я бы рекомендовал поместить формальную логику (на примере этой или другой книги) в самое начало — до изучения математической логики, графических нотаций, БД и ООП. Также её есть смысл изучать до чтения книг по публичным выступлением и точно до непростой для восприятия книги Минто.

#книги #коммуникации #логика

⚠️ Не повторяйте этих ошибок

Люди склонны верить в лучшее. Как говорил классик: "Ах, обмануть меня не трудно!.. Я сам обманываться рад!"

Это касается всего, но сегодня я хочу затронуть вопрос старта любой свежей инициативы. И тех рисков, которые поджидают системных аналитиков, словно акула 🦈 — чтобы отхватить заплывшему глупцу ногу🦵.

Если говорить кратко: никогда не стоит доверять результатам встреч, на которых лично вы не были. Равно как и заверениям о "лёгкой задаче" от людей, которые сами не будут её пилить или отвечать за конечный результат 💩.

Держите три свежих примера из жизни.

1⃣ Подключение к стандартному платформенному сервису
Вы слышите: "Почти все уже подключились, подойди потом, расскажем". Или даже: "Да там дел на пару недель, ничего сложного!" ✨

📉 Реальность: советчики интегрировались год назад через REST со стандартным коннектором. А вам такая опция недоступна. Почему?
▫ У вашей системы другой стек, старый коннектор просто не подойдёт.
▫ Архитекторы недавно запретили прямое взаимодействие через REST — теперь только Kafka.
▫ Появилось обязательное требование о гарантированной доставке сообщений в ту самую Kafka 😱.

А это значит — станцевать джигу-дрыгу с заказом отдельного персистентного хранилища для неотправленных сообщений и нагородить огород с наложением и проверкой электронной подписи на эти данные.

2⃣ Вывод функциональности на новую поверхность
Вы спокойно живёте в мобильном приложении. Вдруг прилетает новость: нужно вывести фичу на другую поверхность (веб-сайт, телевизор, умную колонку — не суть важно). Вы слышите: "Да мы вашу систему просто вызовем извне, всё будет работать" 📺.

📉 Реальность:
▫ На новой поверхности используются совершенно другие подходы к авторизации.
▫ Заказчику в действительности нужна несколько иная реализация, копировать логику один-в-один не выйдет.
▫ Сервисы, которые вы вызываете у себя, банально недоступны на новой поверхности, а их команда-владелец не собирается выводить аналог.
Кажется, кто-то забыл проговорить тонкости с архитекторами.

3⃣ Автоматическое наполнение базы знаний
В системе есть консультационный функционал: клиент спрашивает про продукт, вы делаете семантический поиск и отдаёте ответ. Базу сейчас наполняют вручную, но это некрасиво. На встрече льётся мёд 🍯 для ушей собравшихся: у базы знаний есть API, в мастер-системе лежат описания продуктов, давайте настроим выгрузку, а индексация подтянется сама 🤖.

📉 Реальность:
▫ В мастер-системе хранится описание в разы большего числа товаров.
▫ Формат — JSON, причём разные виды продуктов хранятся в разных реквизитах и по разным правилам.
▫ Выгрузить можно только всё сразу или ничего — отобрать нужные продукты нельзя.
▫ Принимающая сторона обнуляет качество поиска: объём одного JSON-файла кратно превосходит размер чанка при индексации 💥.

Страшно стало? 😬
И это я прошёлся только по верхам, намеренно не стал раскрывать все подводные камни.

Главное, что здесь стоит запомнить: простота бывает часто обманчива, и не стоит принимать всё на веру. Иначе рискуете взять на себя обязательства, которые будет невозможно выполнить.

#кейсы #интеграции #брокеры #архитектура #юмор

Рабочий инструмент — рекомендую 👍

#юмор #uxui

Я фигею от шринкфляции 🤯

Решил посмотреть на цены базовых продуктов глазами аналитика. Взял для примера молочку "Зелёный луг" — и обнаружил там настоящую драму.

Помните, раньше мы жили в довольно понятной "системе  координат": масло — 200 г, йогурт — 0.5 л, молоко — 1 л. Но годы берут своё и количество продукта в упаковке пошло на спад. 

🧈 Масло сливочное
200 г → 180 г → 150 г.
Падение на 25%, при этом визуально пачка за каждый шаг почти не изменилась. Получается такой эффект варёной лягушки. Варят, как вы понимаете, нас с вами. 

🥛 Молоко отборное
1 л → 900 мл → 750 мл.
График падения как классический даунтренд на дашборде. Обычно при таком графике надо волноваться и что-то предпринимать, ведь в общей сложности потеряли 25% и падение серьёзно ускорилось. 

🍶 Йогурт
Сперва тара "похудела" с 0,5 л до 0,45 л. Но теперь самое весёлое: в последней итерации на этикетке стали писать не миллилитры, а массу в граммах (если конкретно — 340 г). 

Как мы помним из школьной физики, плотность молочки > 1, так что циферка в граммах всегда больше объёма в миллилитрах. Я не стал упражняться сам, спросил ИИ: "Переведи в миллилитры". Результат — 0,33 л 🤖➗🧪.

То есть минус 34% от традиционного объёма! 

📐 Системный взгляд
Рассмотренные примеры это не разовые акции, а хитрая многоходовка со сменой единиц измерения, цель которых — притупить восприятие потребителя и замаскировать значительно более высокий рост цен на продукцию.

Но что ещё? Это повод задуматься... Важно уметь видеть за цифрами реальные процессы, но ещё важнее — вовремя замечать, когда эти цифры начинают играть против тебя.

😐 Вместо заключения
Скоро жду масло 100 г в форме изящного кубика со стороной 4,7 см и йогурт 200 г с надписью "Для большой семьи" или "Максимум протеина" 😄.

#экономика

🎯 Бесцельная цель

Меня попросили ознакомиться со спецификацией стороннего сервиса на предмет возможности его использования в будущем. Открываю Confluence, читаю шапку: "Цель: доработка входных и выходных параметров".

Печаль... 😭

Я не знаю, что делает этот сервис. Не понимаю, какую бизнес-задачу он решает для потребителей. Понимаю только, что это уже не первая итерация, раз что-то дорабатывается, но вот что и зачем?

Любые параметры можно переделывать бесконечно: сделать их красивее, привести к snake_case, перенести на другой уровень вложенности. Но зачем? Как мы поймём, что доработка успешна, если критерий успеха состоит в самом факте изменения?

💡И вот тут есть отличный маркер понятности текста. Хорошо настроенный ИИ в агентном режиме при генерации черновика спецификации почти наверняка потребует контекст. Он спросит: какую проблему пользователя мы решаем? На основе вашего ответа (а скорее всего, серии вопросов-ответов) модель сама предложит осмысленную бизнес-цель ("ускорить поиск", "снизить количество ошибок валидации") и только потом опишет необходимые технические изменения в контракте.

Опять же, если LLM сформулирует не ту цель или что-то выдумает, это сразу бросится в глаза и позволит вовремя скорректировать текст. А значит, при прочтении пользователь документации всё поймёт и не напишет пост на эту тему в своём телеграм-канале. 😅

Друзья, надеюсь, теперь понятно, почему первым пунктом в шаблоне спецификации должен идти раздел с описанием боли пользователя, а не список полей будущего JSON.

#ai #интеграции #сервисы #кейсы

🤔 Не всё так однозначно

Мы живём в эпоху необъяснимой уверенности: стоит вооружить команду нейросетями — и задачи начнут решаться быстрее и меньшим числом людей. Но точно ли ИИ поймёт, чего именно вы от него хотите? Я пока не уверен. И вот причина.

Естественные языки по своей природе неоднозначны. Иногда даже я, читая серьёзный документ, ловлю себя на мысли: "Что вообще хотел сказать автор?" Кажется, что нас всегда в подобных случаях спасает здравый смысл, но так ли это на самом деле? За последнее время мне встретились отличные примеры такой двусмысленности.

✏️Из корпоративной рассылки:

10 и 11 июня в студии настольных игр и танцев... состоялся турнир...

Не знаю, как у вас, а у меня перед глазами тут же встали настольные танцы 💃.

✏️Заголовок новости:

Россияне рассказали, какие сюрпризы ждут туристов в Египте

Всё бы ничего, но слово "сюрприз" давно существует в двух полярностях — приятной и катастрофической. Из заголовка совершенно неясно, о каком значении речь.

✏️Официальная инструкция к проездным билетам Московского метрополитена:

Данный проездной билет не дает права прохода на метрополитен... и права провоза ручной клади сверх установленных норм на МЦД и наземном городском пассажирском транспорте

Формулировка сбивает с толку: кажется, будто этот кусок пластика вообще ни на что не годится. На деле он нужен ровно для одного — оплаты дополнительного места багажа. Просто сам по себе турникет он не откроет.

Оттуда же:

При проезде на метрополитене… пересадки… осуществляются без взимания дополнительной платы при валидации проездного билета.

Здесь прячется риск двоякого прочтения. Можно понять как констатацию факта: "во время валидации доплаты нет". А можно — как жёсткое условие: "чтобы пересадка была бесплатной, вы обязаны валидировать билет".

✏️Или вот новостной заголовок:

Найдена гробница древнего принца с колесницей внутри

Разум подсказывает, что колесница находится внутри склепа, а не внутри усопшего, однако при прочтении улыбка непроизвольно озарило моё лицо😆.

✏️А теперь спустимся на уровень системного аналитика. Описание логики работы сервиса:

...проверяет наличие переданного source_uuid в source_uuid.yaml.

Значит ли это, что файл source_uuid.yml клиент должен передать параметром при вызове, и именно в нём сервис выполнит поиск айдишника? Или всё же названный файл относится к внутренней инфраструктуре сервиса, а клиент обязан передать только значение source_uuid? В предыдущих абзацах документации подсказок нет, и без помощи зала разобраться не просто.

👻Вывод. Всё это наталкивает на мысль, что прежде чем делегировать задачу машине, её нужно научиться ставить самому человеку так, чтобы исключить неверные трактовки. Нужно возвращаться к азам профессии. В противном случае есть риск получить вместо ускорения очень технологичный хаос.

#ai #логика

👾 TDD, BDD, SDD

В разработке ПО с давних времён стали популярны трёхбуквенные сокращения вида: ?DD ("Что-то там"-Driven Development). Сейчас в центре внимания очередная "звезда" ⭐️ — SDD (Spec-Driven Development, разработка на основе спецификаций).

И на фоне её "сияния" может возникнуть ощущение, что все предыдущие ?DD потеряли свою актуальность. Сегодня хочу с вами поделиться несколькими встретившимися мыслями из прочитанного на эту тему. Всё максимально тезисно.


🚩 SDD vs TDD
🛑TDD: как проверить, что код работает. Это список проверок для готового продукта.

🛑SDD: что код должен делать согласно проекту. Это детальный чертёж системы до написания кода.

Они дополняют друг друга: чёткая спецификация из SDD может автоматически превращаться в тесты для TDD.


🚩 SDD vs BDD
🛑BDD: поведение с точки зрения пользователя (сценарии Given-When-Then, "Дано-Когда-Тогда"). Мы смотрим на систему глазами человека.

🛑SDD шире: описывает не только сценарии, но и внутреннюю механику — архитектуру, потоки данных, граничные случаи.

Если BDD нацелен на внешнее проявление системы, то SDD делает акцент на её внутренней конструкции и надёжности.

#термины #ai #программирование

Analyst Days расширяет программу до 18+? 😂

#юмор

Онбординг (onboarding) — это процесс знакомства пользователя с продуктом или его новой функцией.

Он полезен, когда человек впервые открывает приложение, а также после обновлений, вносящих существенные изменения.

Цель мобильного онбординга — помочь разобраться в функциональности и обратить внимание на неочевидные моменты.

#термины #uxui

📕 "Законы UX-дизайна: понимание психологии пользователя — ключ к успеху" Джона Яблонски

Сегодня хочу поделиться мнением о работе, относящейся к смежной сфере. Но кого это когда останавливало? 😉

🖋 Ремарка. Несмотря на то, что на странице с библиографическими данными книги стоит пометка "для дизайнеров", порог входа у неё низкий. Любой человек с базовым уровнем грамотности сможет без труда погрузиться в её содержание — читается она довольно легко.

🌟 Содержание. Каждая глава с первой по десятую посвящена определённому закону, правилу или эффекту, которые оказывают заметное влияние на удобство и восприятие информации. Все эти явления рассматриваются через призму психологии и опираются на доказательную базу.

Например, при изложении закона Фиттса становится понятно, как расположение элементов интерфейса влияет на удобство и как это удобство можно количественно измерить. Здесь же, ссылаясь на исследования, автор наглядно показывает разницу в восприятии удобства между традиционными поверхностями и экраном телефона.

Небольшая цитата:

... люди предпочитают смотреть в центр и прикасаться к центру экрана смартфона... Они также, как правило, фокусируются на центре экрана, в отличие от движения глаз из верхнего левого в правый нижний угол, как это обычно бывает на настольных устройствах.

В главе 6 при разборе правила пика и конца (а также в последующих главах) автор неоднократно обращается к работам Амоса Тверски, Даниэля Канемана и др. экспертов по поведенческой психологии. Автор признаёт важность учёта когнитивных искажений при исследовании клиентского пути и проектировании пользовательского опыта.

И ещё одна цитата:

Люди оценивают тот или иной опыт в значительной степени по тому, что они чувствовали на его пике и в конце, а не по общей сумме или среднему значению каждого момента переживания.

Последние две главы книги подводят некий итог: здесь даются рекомендации по внедрению в практику рассмотренных психологических принципов, а также излагается их влияние на создание интуитивно понятного UX-дизайна.

Заключительные страницы книги рассматривают вопросы этики. Именно здесь можно прочитать, через какие механизмы "подсаживают" пользователей на свои цифровые продукты и сервисы (лайки, автовоспроизведение видео, персонализация и пр.).

💡 Резюме. Если ваша работа связана с UX/UI (пусть даже вы просто участвуете в согласовании дизайн-макетов), прочитать эту книгу определённо стоит. Она станет ценным источником для формирования осознанного понимания того, что в дизайне "хорошо", а что "плохо". Причём это понимание будет основано не на интуиции или общепринятых догмах, а на законах психологии.

Если ваша работа никак не связана с UX/UI, то данная книга может стать хорошим вариантом для расширения кругозора.

Итого: к прочтению рекомендую.

#книги #uxui #психология