Три смертных греха, которые испортят качество IT-продукта (или уже портят)

Привет! Меня зовут Женя, я руковожу агентством аутсорс тестирования «Кавычки». Мы занимаемся обеспечением качества для крупных российских и зарубежных компаний. В этой статье я хочу рассказать про три греха продуктовых команд, которые мешают создавать качественные IT-продукты. Окей, конечно, количество не ограничивается этой цифрой, потому что бесконечность — не предел. Но сегодня поговорим про три, да и VC не резиновый.

Почему появилась эта статья? На рынке выпускают все больше IT-решений, параллельно растет конкуренция за внимание пользователей. Никого уже не удивишь красивым интерфейсом. Пользователи ждут качество и максимальную заботу о себе. Тот, кто предоставит им лучший пользовательский опыт, будет лидировать в гонке за лояльность. Такие правила игры. Поэтому компании периодически начинают задумываться, как улучшить качество. Ну, или не начинают. Все, о чем я буду говорить дальше — это такой микс на стыке QA, UX и продуктовой аналитики. В общем то, что влияет на качество и как следствие — на лояльность пользователей. Это то, что касается каждого в продуктовой команде. Ну, поехали.

Давайте честно, люди нелогичны и иррациональны. Ожидать, что они пойдут по тому пути, который вы предположили — опрометчиво. Нужно предвидеть множество пользовательских путей. И возможно, не промахнетесь. Но это не точно. Есть крутой пример, о котором писал Дейв Фельдман (бывший руководитель проектов в Google, Facebook, TechCrunch, Emu, Yahoo). Суть: от пользователей стали приходить жалобы, что приложение сломано, т.к. не приходят уведомления. Когда команда начала разбираться, поняли, что пользователи сами отключили уведомления у себя в приложении. Где логика?

А логика все-таки есть. Фельдман объясняет ее работой двух систем человеческого мозга: Система 1 и Система 2. Именно Система 1 задействована большую часть времени, она работает автоматически и быстро, основываясь на впечатлениях, эмоциях или ассоциациях. Система 2 более сложная, медленная и осмысленная. В данном случае Система 1 увидела слово «уведомления» и провела ассоциацию с чем-то негативным, поэтому пользователь отклонил их. Система 2 может даже не замечать этого или совсем смутно осознавать. Но уведомления уже отклонены.

К чему все это? Природа пользовательской логики такова, что на любом этапе взаимодействия с продуктом может возникнуть блок, который прервет цепочку действий или вообще — изменит весь пользовательский путь. Что такое блок? Это все, что мешает пользователю взаимодействовать с продуктом и совершить целевое действие (от лени, мыслей и страхов пользователя до неудобных кнопок, непонятного интерфейса и загрузки более 5 сек.). Например, это могут быть лишние формы, которые долго и лень заполнять, поэтому пользователи уходят; это может быть незаметная кнопка или фича, которая важна, но ее никто не видит.

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

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

Критическая оценка и мышление — это must have для того, чтобы сделать качественный продукт. Нужно смотреть на продукт с точки зрения «что еще можно улучшить», всматриваться и искать в нем изъяны. А еще лучше — пользоваться продуктом на постоянной основе. Согласитесь, хуже, если эти изъяны найдут пользователи, которые побегут рассказывать вам об этом в Google Play или App Store, снижая рейтинг.

Это мой любимый пункт из серии «сами протестируем», «сами разберемся». Тестировать продукт с точки зрения богатого пользовательского опыта и насмотренности может тот, кто давно и профессионально этим занимается. Как вы поняли, вариаций поведения — много, поэтому качество во многом будет зависеть от того, какой специалист помогает на этапе разработки и тестирует ваш продукт.

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

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

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

Почему это важно? Если вам нужно, чтобы пользователь что-то выбрал или прочитал (прям прочитал) — то нужно выделить это/обратить внимание, иначе он все пропустит, по привычке жмакая «далее», пока не дойдет до кнопки «готово».

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

Есть, конечно, привычки неизменно любимые всеми. Легендарная борьба за стену в VK — «Дуров, верни стену». Другой пример, когда Microsoft избавились от кнопки «Пуск» в Windows 8, это вызвало возмущение пользователей. Реакция была настолько суровой, что Microsoft восстановили кнопку «Пуск» в Windows 8.1, хотя и не то, что было.

Но с багами тоже лучше не косячить.

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

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

Плюсы:

Минусы:

В команде может быть как один/несколько тестеров, так и по харду — целая QA-команда.

Плюсы:

Минусы:

Тут много вариантов: один или несколько тестеров, целая команда с QA-лидом или QA-лид в команду штатных тестеров. Тестировщики могут быть как отдельной проектной командой, так и работать со штатными тестерами, если расширился продукт или необходима дополнительная помощь.

Плюсы:

Минусы:

Если вы задумались, нужна или не нужна вам дополнительная помощь, тестировщик или команда QA, и что это вообще такое, то стоит разобраться. Для этого мы с командой сделали небольшой тест, чтобы всего за восемь вопросов вы могли еще раз убедиться, надо оно вам или нет. Сорян, но там не будет сбора почт и выскакивающих баннеров про уникальность наших услуг. Тест сделан не для этого. Если пройдете его и узнаете для себя что-то новое — круто. Если нет, значит — не круто.

Любая экономия времени или сил на качественном тестировании и QA всегда несет риски аукнуться письмами «любви» от клиентов или запахом горящих стульев из отдела службы поддержки. Заботьтесь о своих пользователях, старайтесь сделать для них лучший и удобный продукт. Именно такие продукты завоевывают сердца и рынки. А для этого надо быть внимательнее к качеству, не экономить на проверке и думать о своих пользователях.