⚙️ Как спроектирована система, подобная Instagram*?

Сегодня мы рассмотрим схему, которая показывает, как можно спроектировать систему, похожую на Instagram. Даже если вы далеки от разработки, эта схема от ByteByteGo поможет понять основные компоненты и их взаимодействие.

❶ Пользователь совершает действие
Всё начинается с вас! Когда вы нажимаете кнопку "лайк", загружаете фото или подписываетесь на другого пользователя (стрелка 1), ваше устройство отправляет запрос в систему. Это может быть что угодно — от публикации нового поста до простого просмотра ленты.

❷ Запрос попадает на сервер
Запрос с вашего устройства отправляется через специальный "шлюз" (API) на бэкенд-сервер (стрелка 2). Этот сервер — это как "мозг" системы. Он обрабатывает ваши действия и решает, что делать дальше.

❸ Сохранение данных в базах данных
После того как сервер получил ваш запрос, он сохраняет данные в соответствующих хранилищах:
— Структурированные данные , такие как профили пользователей, комментарии и подписки, хранятся в реляционных базах данных (например, Postgres).
— Данные, требующие быстрой записи , такие как лента новостей или логи действий, могут храниться в специальных базах данных, которые работают чуть медленнее, но выдерживают большие объемы данных.

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

❹ Хранение медиафайлов
Когда вы загружаете изображения или видео, они сохраняются в специальном хранилище для файлов — объектном хранилище (Object Storage) (стрелка 4). А вся информация о них (например, название файла, размер, дата загрузки) записывается в базу данных.

❺ Очередь задач
Если нужно выполнить задачу, которая не требует мгновенного ответа, например, отправить уведомление о новом лайке, эта задача помещается в очередь (Queue) (стрелка 5). Это помогает системе не перегружаться и выполнять задачи постепенно.

❻ Фоновые процессы
Фоновые рабочие процессы берут задачи из очереди и выполняют их (стрелка 6). Например, они могут отправить уведомление другому пользователю или обработать новый комментарий.

❼ Обновление данных
После выполнения задачи фоновый процесс также обновляет необходимые данные в базах данных (стрелка 7). Например, если кто-то поставил лайк вашему посту, это отразится в вашей статистике.

* — принадлежит Meta, признанной экстремистской организацией и запрещенной на территории РФ ))

#tech #Instagram #systemdesign #ByteByteGo

🔍 Поиск на стероидах. Адресная строка для поиска по разным системам

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

📝 Как настроить поиск (в chromium браузерах)

❶ В браузере заходим в настройки поиска:
— можно вбить в адресной строке browser://settings/searchEngines, либо
— нажать на адресной строке правой кнопкой мыши, далее в контекстном меню выбрать пункт "Управление поисковыми системами..."
❷ Жмём кнопку "Добавить" справа вверху
❸ Для поиска по Википедии заполняем поля:
— Название: Wikipedia
— Ключ: wiki
— Ссылка: https://en.wikipedia.org/w/index.php?title=Special:Search&search=%s
❹ Сохраняем
❺ ПРОФИТ! Теперь если в адресной строке вбить wiki , затем нажать пробел или tab, адресная строка переключится в режим поиска по Википедии.

Таким образом можно настроить несколько поисковых систем, указав разные ключи и подставляя параметры %s в разные ссылки вместо запроса.

При этом это не обязательно должны быть поисковые движки, можно просто быстро открывать нужные страницы передавая параметр в урле в нужном месте, например логин сотрудника или id какого-то объекта


👍 Примеры

Поиск в Яндекс Почте

https://mail.yandex.ru/?#search?request=%s

Stack Overflow

https://stackoverflow.com/search?q=%s

Github

https://github.com/search?q=%s&ref=opensearch

🕑 Техники управления временем, которые действительно работают

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

Часть из этих подходов знал, но часть оказалась вновинку. Рассказываю кратко и с примерами:

❶ Используйте календарь для задач
Не записывайте задачи в приложения — ставьте их в календарь как события.

Пример: Запланируйте «написать код для фичи X» с 10:00 до 12:00.
Если что-то помешает, просто перенесите задачу.
Почему работает : Если задача не в календаре — её часто не делают.

❷ Если задача занимает меньше 2 минут — сделайте её сейчас
Если действие можно выполнить быстро (например, ответить на письмо или исправить опечатку в коде) — не откладывайте.

❸ Ведите список «Ожидаю»
Когда просите кого-то сделать что-то — добавляйте это в список «Ожидаю».

Пример: «Жду от разработчика отчет о баге #123».
Это помогает не забывать о задачах и вовремя напомнить о них.

❹ Каждое утро записывайте 1–3 главных задачи на день
Каждое утро выбирайте 1–3 задачи, которые сделают день продуктивным.

Например: «Исправить критический баг до обеда».
Сначала делайте самое сложное («съешь лягушку»).

❺ Защищайте время глубокой работы
«Глубокая работа» — это cфокусированные, неразрывные задачи, требующие когнитивных усилий.

Планируйте 2–3 блока времени в неделю.
Отключите уведомления, используйте инструменты вроде Brain.fm.
Договоритесь с командой о запрете встреч в определённые дни.

❻ Запретите встречи до определённого времени
Не берите встречи до 15:00 или даже до 12:00. Это время для творческих задач.

❼ Включайте режим «Не беспокоить»
Отключите уведомления на всех устройствах. На Mac/PC есть встроенные инструменты для этого.

❽ Переводите встречи в асинхронный формат
Большинство встреч можно заменить письмом. Ответьте на приглашение так: «Могли бы мы обсудить это асинхронно? Что вам нужно от меня?»

Это экономит часы на встречи.

❾ Используйте виртуального ассистента
Делегируйте рутину через сервисы вроде Double или Fancy Hands.

Пример: Ассистент может оформлять отчеты или искать информацию.

❿ Чаще говорите «нет»
Большинство перегрузок из-за излишнего «да». Фильтруйте задачи через приоритеты.

❯ Подробнее в статье

#productivity #timemanagement

🧩 Как enterprise architecture (EA) помогает достигать "быстрых побед"

Интересная статья от Daniel Lambert — эксперта в области бизнес- и enterprise architecture (EA), автора книги о agile-стратегиях и партнера компании Business Architecture Info.

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

Вот основные идеи:

Что такое «быстрые победы»?
Это небольшие проекты , которые:
— Реализуются быстро (недели, а не месяцы).
— Доставляют ощутимую пользу (сокращают затраты, улучшают процессы).
— Показывают ROI и мотивируют команду к большим изменениям.

Примеры:
Автоматизация рутинных задач.
Устранение дублирующих систем.
Оптимизация данных для быстрого доступа.

Как EA помогает их находить?
В статье предлагается шесть методов :

❶ Стратегическая выравнивание
Проверяйте, насколько проекты соответствуют целям компании.

❷ Оптимизация процессов
Используйте EA для визуализации процессов и выявления «узких мест».
Пример: сокращение этапов в цепочке поставок.

❸ Рационализация технологий
Уберите «лишние» системы.
Пример: замена нескольких CRM на одну.

❹ Управление данными
Централизуйте данные, чтобы избежать «силосов».
Пример: создание общего хранилища.

❺ Повышение эффективности
Найдите простые способы сэкономить ресурсы (например, пересмотр контрактов).

❻ Создание новых источников дохода
Используйте EA для анализа клиентских цепочек и добавления новых услуг.

Как это работает на практике?
Всё просто — классифицируйте проекты :
— Быстрые победы — низкий трудозатрат, высокая отдача.
— «Денежные дыры» — требуют много ресурсов, но не приносят ценности.

Сосредоточьтесь на первых) Profit!

#prioritization #projects #ea

🤓 Продуктовые паттерны: как решать проблему «неправильного порядка действий»

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

Рассмотрим 7 продуктовых решений , которые помогут снизить количество таких случаев:

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

Пример:
Шаги с нумерацией (например, «1. Выберите дату → 2. Введите данные»).
Анимация или цветовые акценты для текущего шага (например, подсветка активного поля в форме).
Почему работает : Пользователи интуитивно понимают, что делать дальше.

❷ Realtime-валидация
Проверяйте порядок действий на лету и блокируйте ошибки до их совершения.

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

❸ Уведомления и подсказки
Помогайте пользователям в момент совершения ошибки.

Примеры:
Всплывающее окно: «Вы не выбрали категорию. Это нужно сделать до сохранения».
Тултипы с пошаговыми инструкциями.
Почему работает : Фокусирует внимание на ключевых шагах без необходимости читать документацию.

❹ Автоматизация
Сделайте систему «непробиваемой» — пусть она сама корректирует действия.

Примеры:
Автозаполнение пропущенных шагов на основе данных пользователя.
Система, которая перестраивает процесс, если порядок нарушен (например, возвращает к предыдущему шагу).
Почему работает : Сокращает нагрузку на пользователя и уменьшает ошибки.

❺ Обучающие гайды и чек-листы
Встроенные руководства внутри продукта.

Примеры:
Всплывающий гид при первом входе: «Сначала выберите проект, затем добавьте задачу».
Чек-листы на экранах: «Проверьте: все поля заполнены → нажмите «Сохранить»».
Почему работает : Упрощает понимание процесса, особенно для новичков.

❻ Предотвращение шагов
Запрещайте выполнение шагов в неверной последовательности.

Примеры:
Кнопка «Далее» становится активной только после выполнения предыдущего шага.
Убрать доступ к определенным функциям до завершения предварительных условий.
Почему работает : Физически невозможно сделать ошибку.

❼ Аналитика и A/B-тесты
Используйте данные для выявления проблемных мест.

Примеры:
Следите за тем, где чаще всего нарушают порядок (например, через Session Replay).
Проводите A/B-тесты: сравните два варианта интерфейса и выберите лучший.
Почему работает : Оптимизация на основе фактов, а не гипотез.


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

😉 Как выбрать решение?
Для критичных ошибок (например, потеря данных): Используйте блокировку шагов или валидацию в реальном времени.
Для сложных процессов (например, настройка CRM): Внедрите обучение или чек-листы.
Для массового использования (например, форма заказа): Проверьте через A/B-тесты, что лучше работает.

😜 Итог
«Защита от дурака» — не всегда оскорбление, а инструмент, который помогает пользователям быстрее достигать цели.

Пробуйте комбинировать подходы: например, визуальные подсказки + уведомления. И помните: лучшая система та, где пользователь даже не замечает ограничений.

#product #UX #problems #path

🗳 Data Pipeline Overview: Как данные становятся ценным ресурсом

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

Сегодня разберём очередную схему от ByteByteGo и посмотрим на типовые этапы конвейера:

❶ Collect (Сбор данных)
Данные собираются из разных источников:
— Data Stores : базы данных, CRM, ERP (например, записи заказов).
— Data Streams : реальные события (клики, логи серверов).
— Applications : мобильные приложения, IoT-устройства.

❷ Ingest (Загрузка данных)
Задача — загрузить данные в систему конвейера.

Инструменты :
— Apache Kafka: для потоковой передачи данных в реальном времени.
— Amazon Kinesis : обработка больших объемов данных в режиме реального времени.

Типы обработки :
— Batch Processing : обработка данных порциями (например, ежедневный отчет).
— Stream Processing : обработка данных «на лету» (например, мониторинг транзакций).

❸ Store (Хранение данных)
Где хранятся данные :
— Data Lake : Необработанные данные (например, Amazon S3, HDFS).
— Data Warehouse : структурированные данные для аналитики (Snowflake, Redshift).
— Data Lakehouse : комбинация озера и хранилища (Delta Lake, Azure Synapse)

❹ Compute (Обработка данных)
Цель —- преобразовать данные в формат, удобный для анализа.

ETL vs ELT :
— ETL : Extract → Transform → Load (преобразование до загрузки).
— ELT : Extract → Load → Transform (преобразование после загрузки).

Инструменты :
— Apache Spark - для пакетной обработки.
— Apache Flink - для потоковой обработки.

❺ Consume (Использование данных)
Как данные помогают бизнесу :
— Business Intelligence - инструменты вроде Datalens,Tableau для создания дашбордов.
— Self-Service Analytics - платформы типа Looker для самостоятельного анализа.
— ML Services - использование данных для прогнозирования (например, рекомендации товаров).
— Data Science - исследования с помощью Jupyter Notebooks.

💪 Почему это важно?
— Автоматизация : устраняет рутину (например, ручной экспорт данных).
— Качество данных : очистка и стандартизация улучшают аналитику.
— Быстрое принятие решений : доступ к актуальным данным в реальном времени.

🤓 Основные вызовы
— Сложность интеграции : разные системы могут иметь разные форматы данных.
— Безопасность : защита данных во время передачи и хранения.
— Масштабируемость : конвейер должен расти вместе с объемом данных.

Итог
Конвейеры передачи данных — это «скелет», который позволяет компании быстро переходить от сырых данных к осмысленным решениям. Без них аналитика становится медленной, а бизнес — менее гибким.

👀 См.также
— Видео от ByteByteGo на тему "What is Data Pipeline?"
— Big Data Pipeline Cheatsheet for AWS, Azure, and Google Cloud

#data #pipeline #analytics #ByteByteGo

💼 Как управлять крупными проектами

В канале TeamLead Good Reads промелькнула статья, которая меня заинтересовала. Текст поста был суховат. Решил изучить первоисточник и изложить свою версию.

В статье автор Ben Kuhn делится своим опытом управления крупными проектами. Автор малоизвестен, но тезисы весьма интересны.

Итак — как управлять масштабными проектами:

❶ Фокусировка
Очистите расписание: для крупных проектов выделяйте 6+ часов в день . Это не столько про время, сколько про концентрацию на цели.

❷ Подробный план
Создайте план с четкими этапами и дедлайнами. План показывает, где вы отклоняетесь от графика, и позволяет вовремя скорректироваться.

❸ Цикл OODA (observe, orient, decide, act)
Цикл наблюдения, анализа, решения и действия:
— Наблюдение : отслеживайте прогресс.
— Ориентация : обновляйте приоритеты в документах.
— Действия : быстро разрешайте блокеры.

❹ Переизбыток коммуникации - это хорошо
Используйте телеграм-чаты и общие документы для отслеживания прогресса. Чем больше у команды контекста, тем лучше принимаются локальные решения.

❺ Делегирование
При команде >10 человек:
— Делегируйте управление
— Дайте ясные цели.
— Выбирайте лидеров, которые организованы и фокусированы , а не только технически сильны.

🛠 Инструменты успеха ответственного за проект
1. Weekly Meeting (Еженедельное совещание)
Что делать: запланируйте 30-минутную встречу с участниками проекта.
Адженда:
— Статус: Что сделано за неделю? Цели на следующую.
— Письменный brainstorm : участники пишут вопросы или идеи в чате (без голосового обсуждения).
— Обсуждение важного : решать самые острые вопросы вживую.
Когда увеличивать встречи :
— Сроки очень сжатые.
— Люди заняты не тем.
— Нужна оперативная помощь.

2. Landing Page / Working Doc (Главный документ проекта)
Что включить :
— Название : В URL или названии документа упомяните, что это часть большего проекта (например, go/project/subproject).
— Цель : Четко сформулируйте, что должен достичь проект, и как это связано с общими целями компании.
— Участники : Список людей, их роли и ссылка на Slack-канал.
— Ссылки : На документы, код, доски задач.
— План : Этапы проекта с дедлайнами.
— Заметки : Протоколы встреч, ключевые вопросы, риски.

3. План / Roadmap / Маршруты
Как составить :
— Разбейте цель на этапы с дедлайнами.
— Будьте честны с неопределенностью: «Дедлайн этапа 3: 15.09.2024, но мы на 70% уверены в этом сроке».
— Используйте вероятности: «Возможность завершить этап: 80%».

4. Чат-нормы
Правила :
— Все обсуждения — в общем чате, а не в личных сообщениях.
— Если кто-то пишет важное в личку, переносите это в общий чат.
— Избегайте длинных цепочек сообщений (centithreads). Можно делать треды
— Если цепочка получилась, напишите краткий итог для канала.
Пример : Вместо 20-сообщенийной ветки в Slack, создайте короткий отчет: «Итог: Найдена ошибка в коде. Иван исправит к пятнице».

5. Weekly Broadcast Updates (Еженедельные обновления)
Как писать :
— Кратко, без мелочей.
— Фокус на результатах , а не на действиях.
Пример: «Проект: Запуск ИИ-модели. Достижения: Точность выросла до 85%. Следующий этап: Тестирование в продакшене до 10.10.2024».
Где публиковать :
— В чате проекта.
Если проект часть большего, — кросс-пост в общий канал.

6. Retrospectives (Ретроспективы)
Как проводить :
— Частота : Раз в 2 недели для активных проектов.
— Формат :
Async brainstorm (13 минут): Участники пишут в документе: Что прошло хорошо? Что нужно улучшить?
Голосование : Сортируйте идеи по популярности .
Синхронное обсуждение : Обсуждайте самые важные пункты и выделяйте action items.

💡 Итого
Успешное управление проектом — это:
— Фокус на главных целях.
— План с четкими этапами.
— Скорость в принятии решений.
— Коммуникация , которая не оставляет вопросов без ответа.

#project #management #IT #team

📝 "Почему" вместо "что": как объяснение причин экономит время и нервы

На днях в канале настенька и графики моей бывшей коллеги и друга Насти увидел пост про важность объяснений "почему" мы делаем так, а не иначе. Обычное "что" надо сделать — приносит мало пользы.

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

Вот несколько примеров из разных аспектов айтишечки, где этот принцип работает на все 100:

📚 Документация

❌ Плохо:

API-метод /payments/cancel отменяет платежи

Это и так видно из названия. Зачем он нужен? В каких случаях использовать?

✅ Хорошо:

Метод /payments/cancel отменяет платежи до их подтверждения банком (статус pending). Используется, если пользователь передумал сразу после оплаты. Не работает для уже проведенных платежей (статус completed)

Почему это важно?
— Новые разработчики не потратят часы на тестирование "нерабочего" метода.
— QA поймет, какие сценарии проверять.


📋 Постановка задач

❌ Плохо:

Добавить поле 'регион' в форму регистрации

Зачем? Может, это требование GDPR? Или маркетинг хочет аналитику?

✅ Хорошо:

Добавить поле 'регион' в форму регистрации:
— Для пользователей из ЕС — обязательное (требования GDPR).
— Для остальных — опциональное (поможет в локализации)

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

🔀 Pull Request'ы

❌ Плохо:

Исправил баг с авторизацией

Какой баг? Почему решение верное?

✅ Хорошо:

Исправил баг с авторизацией:
— Проблема: Токен обновлялся даже при неактивной сессии (ошибка 401).
— Решение: Добавил проверку session.isActive() перед обновлением.
— Почему это безопасно: Метод isActive() покрыт интеграционными тестами

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

👥 Встречи и обсуждения

❌ Плохо:

Нужно переписать модуль X на Go

Почему не Python? Это критично для дедлайна?

✅ Хорошо:

Переписываем модуль X на Go:
— Причина: Текущая реализация на Python не справляется с нагрузкой > 10k RPS.
— Альтернативы: Рассмотрели кеширование, но это лишь временное решение.
— Риски: Миграция займет 2 недели, но снизит затраты на инфраструктуру.

Почему это важно?
— Команда видит, что решение взвешенное, а не "просто ради Go".
— Новые участники поймут контекст, даже пропустив обсуждение.

👀 Тестирование

❌ Плохо:

Тест: проверить отправку email после регистрации

Какой email? Всем ли пользователям?

✅ Хорошо:

Тест: проверить отправку email после регистрации:
— Кейс: Письмо с подтверждением отправляется только новым пользователям (поле is_new=True).
— Почему: Спам-фильтры банят, если отправлять повторно

Почему это важно?
Тестировщик не потратит время на проверку "почему письмо не пришло".

🪄 Лайфхаки
— Везде, где возможно, добавляйте ссылки на контекст: задачи в таск-трекере, страницы в вики, чаты в телеграм.
— Если решение временное, пишите FIXME/TODO + дату:
// TODO: Удалить после миграции на Logbroker (дедлайн: 01.01.2024)
— В сложных решениях оставляйте аргументы против альтернатив (например, "Выбрали Redis вместо Memcached из-за поддержки TTL на уровне ключей").

💡 Итого
Чем больше вы объясняете зачем, тем меньше времени команда тратит на "догадки" и тем выше качество продукта.

#softskills #management #bestpractices

📝 Friction Logs: как найти скрытые боли пользователей в вашем продукте

Наткнулся на старую статью в канале Teamlead Good Reads. Автор статьи Shai Ben-David предлагает уникальный метод — friction logs (логи трений). Это детальные записи всех моментов, которые вызывают неудобства при использовании продукта.

Посмотрим, как это работает и как использовать:

📄 Что такое friction logs?
Это документ с описанием всех «затыков» , которые возникают при взаимодействии с продуктом:
— Ошибки, которые сложно исправить.
— Непонятные инструкции.
— Мелкие детали (например, непонятный шрифт или медленные переходы).

🤷‍♂️ Когда нужно использовать friction logs?
Вы разрабатываете ПО — чтобы улучшить UX.
Исследуете продукт конкурента — чтобы найти их слабые места.
Учите продакт-менеджмент — тренируете навык «смотреть глазами пользователя».

📖 Как создать friction log: пошаговая инструкция
❶ Подготовка
Создайте документ : Используйте Notion, Google Docs, Вики, да что удобно
Определите роль и сценарий :
— Кто вы? Например: «Я разработчик мобильного чата».
— Что делаете? «Хочу настроить плату за подписку».
— Критерии успеха : «Нет редиректов, все на iOS».
Не ищите информацию заранее : Попробуйте пользоваться продуктом «с нуля», как новый пользователь.

❷ Используйте продукт
Записывайте всё :
— Даже мелочи (например, «неудобно найти настройки»).
— Отмечайте эмоции: красный/желтый/зеленый эмодзи для сортировки проблем.
— Делайте скриншоты. Важно фиксировать проблемные моменты

❸ Анализ
Выделите главные проблемы :
— Пример из лога ChatGPT : сложная регистрация отпугивает пользователей.
— Пример из лога Bing AI : неясные подсказки в поиске.

Сортируйте по важности :
— Выберите 3 главных трения , которые нужно исправить в первую очередь.

❹ Передайте команде
— Не требуйте решить всё. Укажите, что многие проблемы — результат компромиссов (например, скорость vs. безопасность).
Готовьте контекст. Ответьте на вопросы: «Почему это важно?», «Как это исправить?».


⚙️ Почему это работает?
Помогает найти блокеры :
— Если пользователь не может найти кнопку «Оплатить», он уйдёт в конкуренты.
— Пример из лога Zapier : ошибка, от которой невозможно восстановиться без поддержки.

Фокус на деталях :
— Не только «большие» проблемы, но и мелочи (например, отсутствие подсказки при наведении).
Прозрачность для команды :
— Friction logs становятся «картами» для улучшения продукта.

🪧 Пример
Ситуация : Тестирование системы оплаты в мобильном приложении.
Затык : Неясная инструкция по добавлению карты.
Friction log запись :
— Проблема : Не понятно, почему не активна кнопка «Сохранить».
— Эмоции : 🟥 (очень раздражает).
— Скриншот : Картинка с нерабочей кнопкой.
Анализ :
— Эта проблема попадает в топ-3.
— Причина: Недостаточная валидация данных.

🪄 Советы от автора
Имитируйте пользователя. Даже если вы знаете продукт, ведите себя как новичок.
Отслеживайте эмоции. Замечайте моменты, когда вы «злились» или «сдались».
Не перегружайте команду. Покажите 3 главных проблемы, а не все мелочи.

❯ Посмотреть примеры

💡 Итог
Friction logs — это инструмент, который помогает «слышать» пользователей , даже если они не пишут в поддержку.
Если ваш продукт застопорился — сделайте friction log. Возможно, вы обнаружите, что пользователи не доходят даже до главного экрана.

#UX #analytics #product #IT #testing