Connect with us

Статьи

Выявление юзабилити-проблем в мобильном приложении

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

USABILITYLAB

Опубликовано

/

     
     
[pullquote align=right]

igor
Игорь Мыслинский, проектировщик пользовательских интерфейсов
[/pullquote]

Поздравляю, вы создали мобильное приложение и прошли через процедуру проверки в Apple App Store или Google Play. Теперь вы готовы к покорению бескрайних просторов целевой аудитории и захвату своей доли рынка. Если вы считаете, что все самое сложное уже позади, то у нас есть плохие новости.

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

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

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

Система аналитики для мобильных приложений

Для начала нам надо встроить в мобильное приложение систему аналитики, например, Flurry (есть еще Google Analytics, Яндекс.Метрика, Mixpanel) . Через некоторое время, допустим, месяц, мы получим временной срез информации о том, как и кто пользуется нашим приложением.

Рассмотрим аналитический инструмент на примере Flurry:

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

Какие данные он нам может предоставить:

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

flurry-screenshot-1

Обработка полученных данных

Данные о переходах с экрана на экран, которые предоставляет аналитика, всегда очень интересны.

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

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

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

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

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

Гипотезы:

  • Пользователь не понимает, какие данные нужно указывать в полях
  • Проблемы с оплатой товара, не ясно, прошла оплата или нет
  • Проблемы с отображением товаров в корзине – часть товаров не видно

Или, например, пользователь выходит на странице товара

Гипотезы:

  • Проблемы с отображением товара (недостаточное количество изображений)
  • Не хватает информации о товаре, чтобы принять решение о покупке
  • Непонятно как перейти к оформлению заказа
  • Проблемы с добавлением товара в корзину
  • У конкурентов дешевле данный товар

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

blinkux

Создание персонажей и их сценариев использования

Персоны и сценарии – удобный инструмент для компактного описания целевой аудитории и задач, реализуемых продуктом, с точки зрения пользователей. Всегда понятно, для кого работает программист и дизайнер, для маркетинга понятно. на каком языке говорить, чтобы попасть в цель.

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

Описание персонажа

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

Пример персонажа для мобильного интернет-магазина по продаже пони

Конезаводчик Сергей, 25 лет

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

Задачи на портале:

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

256880830

Сценарии для проектирования

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

Пример сценария

  • Запустил приложение
  • Ввел запрос поиска
  • Выбрал интересующее в поисковой выдаче
  • Просмотрел характеристики
  • Прочитал отзывы
  • Заказал
  • Получил уведомление о времени доставки

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

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

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

Introduction-Website-Usability-Testing-Car

Юзабилити-тестирование

У вас уже собрана статистика, построены персонажи и их сценарии вы знаете проблемные экраны в своем приложении. У вас есть набор гипотез, которые вам нужно проверить.

Теперь самое время провести тестирование.

Для тестирования необходимо:

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

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

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

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

Сделать листы оценки:

  • выполнил ли задачу – смог ли достигнуть нужного результата;
  • сложности – например, от одного до пяти, как он считает;
  • затраченного времени – тут надо отмечать, прошел ли за разумное время или затратил много времени, понимая, что от него хотят.

Задания формируются из сценариев очень просто. Если, к примеру, у вас есть сценарий заказа услуги, то задание будет, как ни странно – заказать эту услугу. Ставьте перед респондентом конечную цель сценария и смотрите, как он будет ее достигать. И помните – если реальный путь расходится с идеальным, то кто-то не очень хорошо знает своих пользователей.

slide

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

“У вашего друга скоро день рождения. И вы решили подарить ему розового пони в яблоках. Чтобы не ехать на конюшню, вы собираетесь заказать его в интернет-магазине. Купите подарок для вашего друга”.

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

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

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

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

Итого

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

Установите систему аналитики в ваше приложение.

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

Анализируйте поступающие данные и корректируйте ваши планы глядя на них.

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

Сделайте персону для вашего приложения. Знайте своего пользователя в лицо.

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

Тестируйте на живых пользователях.

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

Не останавливайтесь на достигнутом.

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

USABILITYLAB
Комментарии Facebook
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

Как я получил 400K загрузок в App Store за две недели и почему потом бросил инди-разработку

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

Анна Гуляева

Опубликовано

/

Я не являюсь успешным игровым разработчиком. Моя самая популярная игра Frantic Architect получила 410,678 бесплатных установок до того, как её удалили из App Store; это даже близко не стоит с успехом Flappy Bird или 2048.

Мне было 21, у меня был не очень традиционный, но приличный бэкграунд в играх, и я создал игру сам с небольшими усилиями. Это выглядело как идеальный старт моей карьеры независимого разработчика игр.

Но вместо этого я всё бросил.

С момента выхода Frantic Architect прошло полтора года. Область технологий меняется быстро, и я не так много думаю о заброшенных проектах. Но я захожу в App Store и вижу, как разработчики казуальных игр достигают успеха, используя ту же стратегию, что и я в свое время. Я сомневаюсь, что это будет работать и дальше, но сейчас это работает, и эта стратегия очень проста.

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

17 марта 2016 я слез с кровати в своем общежитии и проверил свой Skype. Я отправил свою игру в Apple неделю назад и знал, что она может выйти в любое время. Я был в Торонто, мой продакт-менеджер — в Париже, и я привык просыпаться от тонны сообщений.

Тогда я прочитал несколько сообщений с поздравлениями о том, что моя игра была выпущена по всему миру. Я включил iPad и открыл App Store. Frantic Architect была прямо в разделе лучших новых игр.

Спустя несколько дней я получил доступ к аналитике. Четвертый день стал для меня лучшим — игра получила 58,486 скачиваний.

Через две недели количество загрузок резко снизилось. Я не был разочарован, потому что я не ожидал даже такого числа пользователей. За шесть месяцев работы/прокрастинации над игрой у меня не было свидетельств того, что все хорошо пойдет – за исключением контракта с одним из самых успешных издателей казуальных игр BulkyPix.

Однако доходы от рекламы не соотносились с количеством загрузок.

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

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

То, что моя игра не стала “денежной коровой”, на самом деле оказалось хорошим сигналом, потому что через два месяца BulkyPix объявили о банкротстве и я не получил ни гроша. Я был зол, но не это стало причиной того, что я бросил инди-игры. Мне нужен был стабильный доход, но многое я скопировал из других игр, и этот подход был неправильным.

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

Чтобы получить фичеринг, вам нужно иметь доступ к команде редакторов. Вы можете попытаться разослать множество писем или запросов в LinkedIn, чтобы найти нужный контакт (никогда этим не занимался, но это стоит рассмотреть), но многие разработчики казуальных игр продвигают их среди известных издателей. Эти издатели регулярно встречаются с командами редакторов Apple и Google, чтобы лично проводить для них питчи игр. Их связи и репутация — это лучший способ получить заветное место на главной странице, если ваша игра так же посредственна, как и моя.

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

Всю стратегию можно разбить на пять шагов:

  1. Пройдитесь по рейтингам и зафичеренным играм в App Store и Google Play, чтобы найти игры, которые просто создать. На момент написания статьи такими играми, например,  являются Fire Up! и Dunk Shot.
  2. Найдите издателей этих игр и выберите тех, кто работает с разными разработчиками. Ищите паттерны в их портфолио. Обычно у всех игр короткая длина сессии и простая механика. Многие издатели принимают примерно одни и те же игры, и если одному из них понравится ваша игра, велики шансы того, что и другим она понравится.
  3. Быстро создайте прототип. Напишите код только для основного геймплея и сделайте простую графику. С других игр можно копировать, если у вас есть уникальное “торговое предложение”. Обычно это механика, но вы можете просто реализовать существующую механику интересным образом – если у вас есть художественный талант.
  4. Отправьте работающие прототипы издателям, которых вы нашли ранее. Письмо должно быть коротким. Вам не стоит описывать торговое предложение более чем одним предложением.
  5. Подпишите контракт и закончите игру. Вам, вероятно, придется создавать материал для рекламы и описания. Уделите особое внимание графике, которую вы отправите в Apple и Google.

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

Когда я говорю, что издатель займется всеми деловыми вопросами, я имею в виду, что он увеличит ваши шансы на фичеринг. Вы можете подумать и о других маркетинговых путях, с которыми они могут помочь. Такие способы есть, но они, по большей части, включают рассылку материалов в медиа или социальные сети, связанные с играми или технологиями. Это не очень поможет, если вы сделали просто очередную казуальную игру. Просто, чтобы представить, насколько это неэффективно: версия Frantic Architect для Android получила всего 3,817 загрузок. Она была отправлена на те же сайты, что и iOS-версия, но она не получила фичеринг от Google Play.

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

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

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

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

Я почти ничего не знаю об управлении компанией. Я забросил несколько других проектов после Frantic Architect, поэтому я не рассматриваю этот случай, как особо болезненную неудачу. Но я не думаю, что мой текущий проект по предоставлению серверов для игры в жанре выживания и крафта будет обязан успехом большой удаче или большому усердию. Этот проект в следующем месяце принесет дохода больше, чем Frantic Architect, хотя база пользователей исчисляется сотнями (а не сотнями тысяч) пользователей и продолжает расти. Я понимаю, зачем людям этот сервис, я могу оценить его соответствующим образом, и я могу улучшать его, не делая безумных догадок.

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

Анна Гуляева
Комментарии Facebook
Продолжить чтение

Дизайн и прототипирование

Как потерять доверие пользователей к продукту и чем это чревато?

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

AppTractor

Опубликовано

/

Автор:

Изображение с сайта Kayako.com

Когда я была маленькая, родители сдавали меня на лето на дачу к бабушке. Дама она была очень строгая и не разрешала мне включать телевизор, потому, что не доверяла ему (или мне :)) Аргумент был простой – «у телевизора даже экран бьет током, возьмешься за вилку – тебя убьет!». Ну как тут поспоришь?

Доверие – либо полное, либо его нет. Ощущением доверия измеряется человеческое счастье. Громко звучит? Тем не менее, так и есть. Человек не может чувствовать себя счастливым, если тревожится, что дверь могла не закрыться, утюг не выключился, будильник не прозвенит, календарь не сообщит о мероприятии, изменения не сохранятся и др.

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

Кривизна, кустарщина

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

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

Страница статистики сервиса товарных рекомендаций Retail Rocket

– Оля, ты – дизайнер, ты это видишь, а нормальным людям на такое плевать!

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

God is in the detail, – народная мудрость

Непонятный нейминг

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

Пример ниже – кусочек «Настроек поведения» CallbackHunter – сервиса колл-трекинга. Не поняла, что означают загадочные цифры и что будет, если я их поменяю. При наведении на знаки вопроса всплывают подсказки, но ясности они не добавляют.

Фрагмент настроек сервиса колл-трекинга CallbackHunter

Например, подсказка у первого пункта Mouse motion speed гласит Average mouse motion speed analysis. Почему оно равно 9.8, осталось для меня тайной, в чем это 9.8 измеряется – тоже. Если вы понимаете что это все значит – напишите в комментариях, пожалуйста.

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

Сообщения об ошибках

Хотела тут недавно купить биткоины через приложение Coinbase. Вместо того, чтобы провести транзакцию оно сообщило мне «It looks like an unknown error occurred while processing the buy…». Гайз, если вы сами не знаете, что за ошибка у вас произошла – как мне вам доверять свои деньги и криптовалютный кошелек? В поддержку они мне, кстати, тоже не ответили :(

Сообщение об ошибке в мобильном клиенте криптовалютной биржи Coinbase

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

Попап ошибки в системе аренды недвижимости RentLinx

Отображение состояний

Если пользователь не понимает, что происходит прямо сейчас и что с этим можно сделать, он будет нервничать.

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

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

Интерфейс PlayStation. Иконки с обозначениями кнопок в самом низу экрана.

Экран «Спасибо за заказ» в приложении доставки еды Just Eat

Самое неприятное для службы доставки то, что у их конкурентов есть четкое отслеживание статусов и интерактивные карты, где видно в реальном времени, где курьер и что происходит с заказом. Конкуренты этим пользуются и с радостью переманивают к себе клиентов Just Eat.

Интерфейс PlayStation. Иконки с обозначениями кнопок в самом низу экрана.

Статусы заказа и интерактивная карта сервиса доставки Glovo

Защита от дурака

Часто слышу от программистов «А зачем пользователь туда полез? Сам виноват». А вот и не так! Если продукт разрешил пользователю «туда полезть» и накосячить, то виноват продукт, вернее, команда, которая его сделала.

Есть масса способов защитить пользователя от ошибок – от масок ввода и принципа «не набирай, а выбирай» до возможности отмены.

Уважаю Gmail за то, что отправку письма можно отменить в течение нескольких секунд. Воспользовалась ей всего пару раз, зато отправляя письмо, чувствую себя уверенно.

Функция отмены отправки письма в Gmail

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

Раньше у меня был ноутбук Sharp, у него тоже была кнопка на клавиатуре и она работала мгновенно. Поверьте мне, когда в процессе работы ты случайно промахиваешься мимо Backspace, тыкаешь в Power и теряешь контроль над ноутбуком минут на 10 – это боль.

Платежи и все, что с ними связано

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

На скрине выше форма оплаты в сервисе покупки авиабилетов Southwest Airlines. Выбран радиобатон Credit Card. Но над формой мы видим пункт PayPal, да еще такой заметный с суммой и иконкой. Зачем? К чему он относится? Ну и вообще всего много и как-то кривовато.

Итого

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

Дальше у сервиса есть два пути – либо оправдать ожидания, либо разочаровать пользователя. Каждая нестыковка съедает часть доверия. Если их много – клиент раздражается, начинает чувствовать себя неуверенно, ждать подвоха и сомневаться во всем.

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

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

Источник: https://olgashavrina.com/.

AppTractor
Комментарии Facebook
Продолжить чтение

Разработка

Как культура сверхурочной работы наносит вред компаниям

Известно,что сверхурочная работа приносит только вред и сотрудникам, и компаниям. Почему тогда компании продолжают поддерживать такую культуру? Алида Миранда-Вулфф рассказала о том, как компании поощряют трудоголизм и почему это так важно обсуждать.

Анна Гуляева

Опубликовано

/

Сотруднику мечты многих компаний 20-30 лет, у него почти нет жизни за пределами работы, этот человек не против работать по 14 часов и спать под столом. Но целая комната таких людей — это не так хорошо, как кажется. — Джейсон Фрид и Давид Хейнемейер Ханссон, Rework

Технологическая культура базируется на скорости, экспериментировании, итерировании и упорной работе. Эта этика, которая часто приводит к удивительным инновациям, продуктивности и переменам, выражена в придуманной в Facebook фразе: “Двигайтесь быстро и ломайте вещи”.

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

Но когда дело доходит до людей, девиз “двигайтесь быстро и ломайте вещи” не работает. Потому что сломанными “вещами” становятся люди.

Сверхурочная работа вредит здоровью, счастью и продукту

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

Сверхурочные – большая ложка дегтя в игровой индустрии

В США сотрудники всех отраслей работают дольше, чем за десятилетия до этого, и данные показывают, что рабочее время среднего американца в году увеличилась по сравнению с 1978 годом на четыре недели. Больше рабочих часов не означает, что сотрудники стали продуктивнее. Средний работник проводит только 45% дня за своими прямыми обязанностями. Более того, увеличение рабочего дня ведет к снижению когнитивных способностей. Другими словами, это давление, вынуждающее людей не брать выходных и “вкалывать упорнее”, сокращает продуктивность и делает сотрудников глупее.

Сотрудников заставляют работать больше и делать больше, что повышает стресс от работы. Американская психологическая ассоциация оценила, что стресс от работы обходится экономике США в 500 миллиардов долларов и 550 миллионов рабочих дней ежегодно. То же исследование показало, что миллениалы показывают самые высокие показатели стресса среди всех поколений. Стоит заметить, что миллениалы составляют 33% работающих американцев.

Почему стресс так дорого обходится? Он повышает количество ошибок и несчастных случаев среди работников промышленности на 61%. Стресс также вызывает проблемы со здоровьем, и более чем 80% визитов к врачам связаны именно с ним.

Сочетание сверхурочной работы и стресса влияет и на сон. Исследования показывают, что 30% людей спят меньше 6 часов в сутки. Нехватка сна приводит к снижению концентрации на 23%, памяти на 18%, и повышает сложность работы на 9%. Работники попадают в замкнутый круг: уставшие люди не способны справляться со стрессом и эффективно работать, и из-за этого вынуждены работать ещё больше.

Неудивительно, что уставшие, нервные и нездоровые сотрудники хотят уволиться. Стресс повышает текучку кадров на 50%, что влияет и на прибыль компании, и на качество работы. Стоимость замены одного сотрудника составляет около 20% годовой зарплаты этого человека, и увольнение одного приводит к увольнениям других людей.

Как статус кво маскирует зависимость от работы

Если этот подход не работает, то почему мы продолжаем продвигать его в компаниях?

Многие из нас верят, что усталость — это символ статуса, — Брене Браун, “Дары несовершенства”

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

В своем анализе игровых автоматов в Лас-Вегасе Наташа Доу Шюлл изучила, как каждый элемент игрового опыта создан, чтобы привести к игровой зависимости: от физического окружения до самих автоматов. Казино и производители игр повышают уровень “продолжительной игровой продуктивности” и “времени в устройстве”, чтобы увеличить прибыль. Игроки достигают “зоны”, в которой они сосредоточены не на победе, а выигрыш часто рассматривается ими как нежелательный перерыв. Вместо этого они заинтересованы в самой игре, она позволяет им войти в состояние транса. Эта “зона” точно такая же, что мы видим при бесконечном скролле в мобильных устройствах.

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

Почему программисты работают в наушниках

Двигайтесь медленно и создавайте вещи

Когда речь идет о людях, нам нужно пересмотреть философию “Двигайтесь быстро и ломайте вещи”, чтобы сосредоточиться на том, чтобы сотрудники оставались счастливыми, здоровыми и продуктивными. Нам нужно перейти к подходу “Двигайтесь медленно и создавайте вещи”.

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

Хорошие новости: для этих изменений уже существуют планы. В технологическом секторе компании переходят на более короткие рабочие недели и дни и видят аналогичный рост прибыли и улучшение морального состояние сотрудников. Treehouse стала одной из первых компаний с такой моделью работы, когда она перешла на 32-часовую рабочую неделю.

Европейские страны экспериментируют с большей продолжительностью отпуска, сокращенными рабочими неделями и днями и инициативами, направленными на благосостояние сотрудников. Люксембург и Норвегия, две самых богатых и экономически стабильных страны мира, работают соответственно на 146 и на 363 часа в год меньше, чем американцы.

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

Но сокращение рабочих часов — это только вершина айсберга. Чтобы воспитывать таланты, которые принесут пользу компании, нам нужно инвестировать время в обучение людей и знакомство с ними. Это означает создание программ по разнообразию и инклюзивности, которые приведут к развитию связей между сотрудниками. Это означает позволять людям из разных отделов брать на себя лидерские роли, чтобы продвигать свои культурные инициативы: обучение новичков другими сотрудниками, shadow days (стажеры в компании «тенями» ходят за опытными сотрудниками целый день) или карьерные консультации.

Анна Гуляева
Комментарии Facebook
Продолжить чтение

Разработка

Автоматизируй это

Андрей Неверов, Head of Engineering в Trucker Path, в своем блоге написал о том, что стоит автоматизировать в разработке ПО.

AppTractor

Опубликовано

/

Автор:

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

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

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

Проверьте, настроены и автоматизированы ли у вас следующие вещи:

  1. Сборка релиза и запуск тестов. Коммит в определенную ветку, запуск тестов, сборка артефакта. Все без малейшего участия человека. Мы используем CircleCI и Jenkins.
  2. Проверка качества и стиля кода. Страшно сокращает время и позволяет на ревью не отвлекаться на ерунду и обращать больше внимания на суть. Начните с использования линтера и убедитесь, что команда не игнорирует его ошибки. Можно настроить git-хуки или использовать готовые решения, например, Codacity или CodeClimate.
  3. Меряйте покрытие кода тестами. Нет единой универсальной метрики, мол, “85% покрытия и все круто”, зато вы всегда сможете сопоставить тренд роста количества багов в трекере с изменениями покрытия и следить, чтоб покрытие никогда не падало ниже определенного процента. Попробуйте Codecov.
  4. Заведите журнал ошибок. Это не баг-трекер и не канал с гневными отзывами пользователей — это система автоматического сбора и категоризации ошибок. Чаще всего для этого используется Sentry, причем как для клиентского, так и для серверного кода.
  5. Мониторинг производительности и серверов. Если у вас нет мониторинга, вы в темноте. Что-то где-то упало, все в огне, паника и бежим тушить руками. Поставьте мониторинг и настройте хотя бы базовые оповещения (CPU сервера > 90%, явно что-то не так) и ваша жизнь сразу станет проще. Самые известные инструменты это New Relic и Datadog, а вообще тысячи их.
  6. Собирайте логи так, чтоб потом их можно было прочитать. Когда оно упадет (а оно упадет), вам нужно будет разобраться, что же пошло не так, причем никакого отладчика и возможности восстановить состояние системы у вас не будет. Если у вас не один сервер — удачи в сборе и попытках склеить логи с разных машин. Классическое решение — Syslog, на рынке масса более user-friendly вариантов, таких как Papertrail или Logstash.
  7. Выкиньте свой железный сервер. Если вы не банк или не предприятие оборонки, никакого смысла иметь физические сервера нет. Разместитесь в облаке и забудьте про всякие проблемы с железом и необходимость все это обслуживать. Одни из самых популярных вариантов — AWS и Digitalocean. Для решений от Microsoft можно использовать Azure.
  8. Автоматизируйте создание и тестирование бэкапов. Как гласит народное поверье, инженеры делятся на две категории: те, кто не делает бэкапы и те, кто уже делает бэкапы. Иначе будет весело.

Источник: блог CTO hints в Medium

AppTractor
Комментарии Facebook
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.