Введение

Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. В этой статье я расскажу, почему для проектирования функциональности наших продуктов вместо стандартных ТЗ мы используем методологию User Story Mapping и как это помогает нам вести разработку быстро и качественно.

Всем привет! 

В прошлой статье, посвящённой A/B-тестированию, мы коснулись технических деталей устройства нашей A/B-платформы, которая обеспечивает нам супербыстрое распределение пользователей по вариантам. Теперь пришло время поговорить о методологии и процессе A/B-тестирования, а если точнее, то о проблемах и заблуждениях, которые могут привести к тому, что, проснувшись однажды среди ночи, вы почувствуете нестерпимую боль ниже спины от внезапного осознания очень простого факта —все проведённые вами A/B-тесты невалидны. 

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

У A/B-тестов есть хорошее свойство — они либо работают, либо нет. Сегодня вы узнаете, что нужно учесть, чтобы заставить ваши эксперименты работать и приносить тем самым пользу бизнесу. Мы рассмотрим шесть самых распространённых причин, ведущих к несостоятельности системы принятия решений с помощью A/B-тестирования. 

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

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