Шрифт:
Интервал:
Закладка:
Проходят те же два года, и у второго приложения уже есть пользователи, которые любят его, потому что оно подходит им и точно решает их задачу.
Существует вероятность, что в течение двух лет второе приложение изменяется, становится другим, не таким, как задумывалось изначально. Но оно точно подходит рынку.
Подведем итоги. Через два года есть два предложения. Одно точно подходит рынку, у него уже есть пользователи.
На второе потрачена куча денег, пользователей нет, проверки только начинаются.
Как вы думаете, у кого больше шансов победить на рынке?
Дизайн
Мода на дизайн меняется очень быстро. Я бы не рискнул тут ничего советовать. Несколько лет назад, когда вышел первый iPhone,стало модно делать приложения, которые бы повторяли физический мир.
Если кнопка – то выпуклая. Если графические элементы – то обязательно трехмерные. Это было инновационной идеей, которая, однако, значительно загружала интерфейс.
Со временем интерфейс загружался такой графикой все больше. Дошло до того, что пользователь в элементах, кнопках, иконках начал теряться и перестал видеть контент.
Мода изменилась, контент стали выводить на первый план, а кнопки сгладили. Теперь это был просто квадратик с надписью «купить».
Спустя некоторое время Google вышел с дизайном, который называется material design, объединяющий предыдущие тенденции, совместивший две вещи. Выпуклость, объемность, которая достигалась не градиентом элементов, а игрой теней.
Еще совсем недавно было очень модно рисовать «пятичасовые» тени, то есть вниз вправо (как на часах расположена цифра 5).
Эта идея была очень популярной. Но в мобильном дизайне, как и в любом другом, однажды наступает пресыщение. Что-то становится модным, это начинают делать все, пользователю такой дизайн надоедает, он не хочет больше его видеть.
Появляются новые тенденции, разработчики переходят к чему-то другому.
Есть одна очень важная мысль: дизайн может быть некрасивым, главное – он должен быть подходящим для того пользователя, с каким вы хотите общаться.
К примеру, дизайн операционной системы Unix вряд ли можно назвать привлекательным. Но для ее истинных пользователей нет системы более правильной.
Меняем все, а потом еще раз и еще
Многие менеджеры считают, что разработка завершается, когда приложение выходит на рынок. Но релиз в Арр Store, первые пользователи – это не конец работы, а только начало. Настоящая работа начинается с момента, когда первый пользователь скачал приложение.
До сих пор вы делали предположения о правильном пользовательском опыте (UX), привлекательных особенностях и способах использования приложения.
Теперь вам предстоит проверить все наши предположения.
Является ли количество отправленных уведомлений чрезмерным и «напрягающим» или слишком низким и недостающим? Кому из ваших пользователей действительно нужна конкретная функция, не отвлекает ли она пользователя от выполнения поставленной перед ним задачи (например, покупки)?
Являются ли тексты, изображения и процессы использования оптимальными для ваших пользователей?
АВ-тесты должны проводиться снова и снова, даже после одного или трех лет использования.
Является ли пользовательская аудитория идентичной той, которую вы определили на этапе определения фичей, или она изменилась со временем? Какие новые возможности вы приобрели благодаря новой целевой аудитории? Мы проверяем все и меняем приложение в соответствии с потребностями рынка.
Что это значит с точки зрения бизнеса?
Бюджет, установленный для жизни приложения, намного выше первоначального бюджета разработки. И вы должны принять это во внимание, прежде чем войти в процесс.
Эпоха примитивных приложений закончилась много лет назад, и, как и любая другая эволюция, выжили только самые сильные, самые быстрые и умные. Наша цель – не выживать, а вести за собой и побеждать.
Только тогда, когда продукт выходит на рынок, вы начинаете понимать, что действительно вашему пользователю нужно.
Иногда бывает, что вроде идея хорошая и исполнение прекрасное, но у клиента не кликает. Здесь помогают аналитика и АВ-тестирование. Проверяем шаг за шагом все наши предпосылки, идеи и решения. Перерабатываем и выбрасываем лишнее, сохраняем только те решения, которые доказали свою эффективность.
Чаще всего разумнее дорабатывать приложение. Клиенты знакомятся с ним, пользуются. Значительно легче добавить какую-то услугу в существующее приложение, чем выпустить на рынок новый продукт и привести в него новых пользователей. Это стоит дорого.
Также нужно убирать из приложения те функции, которыми перестали пользоваться.
Кейс о том, как мы меняли приложение Moovit, посвященное общественному транспорту.
Мы придумали восхитительную фичу: возможность видеть на экране телефона, где едет автобус. Сейчас такая фича есть и в Uber, и в Яндекс. Такси, но тогда не было ни у кого.
На экране была надпись: автобус будет через 2 минуты. Пользователь видел, что на экране автобус поворачивает на его улицу, смотрел в сторону – и автобус действительно показывался из-за угла.
Нам эта идея казалась в то время инновационной и востребованной. Мы считали, что фичей будут пользоваться все.
Выпустили на рынок эту версию. Как мы и предполагали, все с этим игрались. Практически каждый человек включал как минимум дважды опцию просмотра, смотрел на этот автобус. И… все. Больше никто к этому не возвращался.
Оказалось, что, если пользователь знает, что автобус через две минуты подойдет к остановке, – ему вообще неважно, где он находится. Понять это нам помогли АВ-тесты.
Через несколько версий мы убрали эту фичу из приложения, и сегодня ее нет.
В приложениях, посвященных заказу такси, он остался. Знаете, в чем разница? Автобус всегда едет по одному маршруту, а такси – по разным. Разработчики приложений такси знают расстояние между такси и тем, кто его вызвал.
Но как такси будет ехать ко мне – они не знают. Этот путь может занять минуту или десять. Приложение указывает приблизительное время: машина приедет через 3 минуты. Во время движения появляется надпись: еще 4 минуты, еще 2 минуты, еще 6 минут. И пользователю хочется знать, что происходит, почему время то увеличивается, то уменьшается.
Если к нам приходит заказчик и просит, условно, «Хочу, как в Uber. Там такси, а мы будем тоже показывать автобус», мы садимся и досконально разбираем: нужно ли показывать этот автобус. Решаем, во-первых, запускать ли его в начальной версии продукта или это недостаточно важная фича. Или вообще не выпускать, потому что в случае с автобусами, как нам помогли понять АВ-тесты, это не нужно.
Чтобы