Я привык анализировать личный опыт и на основе его формировать принципы, которые помогут в дальнейшем совершать меньше ошибок и работать продуктивнее. В этом разделе я делюсь с вами несколькими важными принципами развития продукта и принятия дизайн-решений.
1
Каждый продукт должен отлично решать ОДНУ ключевую проблему пользователя в выбранной сфере, которая не изменится с годами. Все остальное – вторично.
Нужно понять, для какой ОДНОЙ основной работы люди нанимают ваш продукт, а после сделать этот процесс идеальным. Ведь сколько бы у вас не было функций, какой бы у вас не был красивый интерфейс, люди не будут его использовать, если он не решает их ключевую проблему.
Например, Яндекс.Такси не было бы смысла вкладывать большие ресурсы в новые категории услуг (доставка посылок, еды), если бы они не научились отлично решать ОДНУ ключевую проблему – быстро найти машину, чтобы доставить человека из точки А в точку Б.
Поэтому, прежде чем расширять возможности вашего продукта, сначала спросите себя, насколько хорошо он решает ОДНУ ключевую проблему пользователя в вашей сфере.
2
Все продуктовые идеи и решения, которые приходят в голову команде, следует переводить в проблемы.
Этот принцип – своего рода холодный душ. Ведь продуктовой команде часто приходят в голову с виду отличные идеи, но большинство из них теряют смысл, как только вы определите в решении какой проблемы они помогут пользователю. Часто такой проблемы просто нет.
Чтобы не попадать в эту ловушку, при появлении идеи, я сначала опускаюсь до уровня проблемы, а потом пытаюсь придумать другие способы ее решения. Очень часто мне удается найти что-то лучше.
3
Прежде, чем взяться за решение проблемы, нужно определить, есть ли она и насколько она серьезна.
Когда вы хорошо разбираетесь в своей сфере, то определить важность проблемы можете сразу. Но даже в этом случае полезно использовать дополнительные источники подтверждения. Как мы уже говорили, есть два основных метода проверить что-либо: количественный и качественный. Покажу, каким образом их можно использовать.
Количественные – это аналитика. Когда инвесторы просили нас сделать приложение для iOS, мы в первую очередь обратились к аналитике и выяснили, что лишь 6% наших пользователей использовали эту платформу. Исходя из этого, тратить большие ресурсы в этом направлении было не логично. Мы предложили компромисс – упаковать адаптив, как отдельное приложение для App Store.
Качественные – это общение. Чаще всего для поиска интересующего вопроса достаточно сделать простой звонок пользователю, и в течение нескольких минут вы получите ответы на все свои вопросы. Это невероятно простой и эффективный инструмент, поэтому если вам скучно или не с кем поговорить, можете набрать пользователю :)
4
Перед тем, как вносить изменения, подумайте насколько часто этот сценарий или функция будут использоваться.
Бывает так, что проблема действительно существует, но лишь у небольшого количества пользователей. Решение этой проблемы повлечет за собой серьезную переработку продукта. Другими словами, вы измените продукт и усложните систему ради 1% пользователей, которые отнимают ресурсов больше, чем приносят денег бизнесу.
Именно поэтому, некоторые проблемы лучше оставлять проблемами, ведь ваш продукт не должен быть удобен абсолютно всем. Лучше пусть его полюбит небольшая, но очень лояльная аудитория, потребности которой вы решите на 100%.
5
Ваш продукт должен быть в несколько раз лучше конкурентов, чтобы переубедить пользователей перейти к вам.
Если у человека есть проблема, то скорее всего он уже каким-то образом пытается ее решить, используя другой продукт. (Если не пытается, то это неплохой повод подумать, есть ли такая проблема). Одна из самых главных задач компании – переубедить пользователя перейти к вам.
В сфере продуктов для бизнеса доминирует 1С и очень сложно заставить компанию перейти на что-то другое, ведь было потрачено уйма ресурсов на настройку системы и процессов компании. Поэтому, чтобы заинтересовать пользователей, ваш продукт должен быть на голову выше конкурентов, и только в этом случае появляется шанс переманить его к себе.
Но есть еще один способ – упростить переход с одного продукта в другой, то есть обеспечить простой перенос данных из старой системы в новую.
Для решения этой задачи мы настроили интеграцию с 1С, у Apple есть отдельное приложение, которое позволяет перенести данные с Android на iPhone, а некоторые сервисы предлагают автоматический перенос заметок в свой сервис из Evernote.
Всегда держите в голове, что в данный момент использует пользователь для решения проблемы, которую пытаетесь решить и вы. Очень часто именно банальная привычка становится главным барьером развития нового продукта.
6
Не бывает глупых пользователей. Есть недостаточно удобный интерфейс.
Любой продукт нацелен на какую-либо аудиторию – вашу аудиторию. И если эта аудитория плохо взаимодействует с технологиями, нет смысла списывать проблемы в использовании на них. Ведь ваша задача – не сделать объективно удобный интерфейс, который соответствует усредненным правилам дизайна. Ваша задача – сделать интерфейс удобным именно для ваших пользователей.
7
Прежде, чем разрабатывать функцию для решения какой-либо проблемы, нужно попробовать протестировать ее «руками».
Каждая новая функция – это риск потерять ресурсы компании впустую, поэтому еще перед реализацией следует убедиться, что она нужна и нужна именно в определенном виде. Часто самый быстрый способ сделать это – протестировать идею «руками». Покажу, как это делаем мы.
Около года назад мы ввели новый способ подписания договора с помощью перевода одного рубля со счета компании. Нам нужно было сгенерировать корректный счет и передать его пользователю для оплаты.
Генерация счета – это большая задача, которая требует ресурсов не только разработки, но и дизайна, ведь нужно проработать весь сценарий взаимодействия. Чтобы снизить риск сделать ненужную функцию, мы решили протестировать ее «руками»: первый месяц сами создавали каждый счет в Google Docs, а после отправляли его пользователю. И лишь убедившись, что эта логика работает, сделали автоматическую генерацию счета в личном кабинете.
Другими словами, сначала мы создали и протестировали процесс, а после, зная все его детали, автоматизировали эту работу.
Еще раз повторим описанные принципы:
1
Каждый продукт должен отлично решать ОДНУ ключевую проблему пользователя в выбранной сфере, которая не изменится с годами. Все остальное – вторично.
2
Все продуктовые идеи и решения, которые приходят в голову команде, следует переводить в проблемы.
3
Прежде, чем взяться за решение проблемы, нужно определить, есть ли она и насколько она серьезна.
4
Перед тем, как вносить изменения, подумайте насколько часто этот сценарий или функция будут использоваться.
5
Ваш продукт должен быть в несколько раз лучше конкурентов, чтобы переубедить пользователей перейти к вам.
6
Не бывает глупых пользователей. Есть недостаточно удобный интерфейс.
7
Прежде, чем разрабатывать функцию для решения какой-либо проблемы, нужно попробовать протестировать ее «руками».