Я пишу этот текст примерно через полторы недели после появления Niqual. Поэтому это довольно плохое место для рассказа о многолетней эволюции бренда.
Зато происхождение ещё не успело превратиться в легенду.
Я помню его довольно точно.
Мне понравился домен.
Я его купила.
Здесь полагалось бы упомянуть исследование рынка, стратегическую сессию и хотя бы один мудборд.
Но сначала был домен.
Смысл появился потом.
Nikkalma становилась общим пространством для моей работы: продуктов, разработки, экспериментов и клиентских проектов. Делать Niqual её дублёром не имело смысла.
Параллельно у меня была задача гораздо прозаичнее бренд-архитектуры. Я осталась без работы и искала продукты достаточно небольшие, чтобы их можно было закончить, выпустить и проверить рынком, не проведя перед этим год в разработке.
Niqual достались маленькие утилиты.
На несколько дней этого определения хватило.
Маленькое очень хочет стать большим
Первым продуктом стало «Не сейчас».
Исходная идея была почти неприлично простой.
Человек хочет что-то купить или сделать. Вместо немедленного решения он фиксирует его и выбирает, когда хочет вернуться к вопросу. В назначенный момент приложение спрашивает снова.
Хочу.
Не сейчас.
А сейчас?
На этом продукт, в сущности, заканчивается.
По крайней мере, должен был.
Стоит начать проектировать приложение для импульсивных покупок, и вокруг него немедленно возникает очередь вполне разумных идей.
Бюджет. Категории. Список желаний. Статистика. История цен.
Наверняка где-то неподалёку уже разминается AI, готовый проанализировать эмоциональные причины покупки носков.
Проблема в том, что почти всё перечисленное действительно можно сделать полезным.
Поэтому вопрос «полезна ли эта функция?» практически бесполезен.
Если отвечать только на него, продукт может расти бесконечно. Всегда найдётся ещё что-нибудь полезное.
Пришлось задать другой вопрос:
Нужна ли эта функция для той задачи, ради которой существует продукт?
У «Не сейчас» остался один цикл:
импульс → пауза → возвращение → решение.
У каждой следующей функции появилось бремя доказательства.
«Это полезно» доказательством не считалось.
Полезное тоже бывает лишним
Это не означает, что приложение нужно сокращать до тех пор, пока оно не перестанет сопротивляться удалению.
Например, уведомление увеличивает продукт.
Без него меньше кода, меньше состояний, меньше способов что-нибудь сломать. С точки зрения размера продукта — сплошные преимущества.
Только тогда человек должен сам помнить, что две недели назад специально решил до сегодняшнего дня о чём-то не думать.
Получается маленький продукт и довольно посредственное решение задачи.
Поэтому уведомление осталось.
Не как способ вернуть человека в приложение. Оно выполняет часть самой работы: до назначенного момента человеку больше не нужно держать решение в голове.
С архивом произошло примерно то же.
После ответа решение перестаёт быть активным. Можно просто удалить его и сделать продукт ещё меньше.
Но завершённое решение всё ещё имеет смысл как завершённое решение. Оно должно исчезнуть из текущего списка, но не обязательно из существования.
Архив остался.
А дальше граница снова закрывается.
Можно показать статистику. Можно поздравлять с количеством отменённых покупок. Можно посчитать деньги, которые пользователь якобы сэкономил, если достаточно уверенно притвориться, что каждая отменённая покупка иначе обязательно состоялась бы.
Всё это можно сделать хорошо. Просто исходную задачу оно уже не завершает.
Полезное тоже бывает лишним.
Минимальность оказалась не целью
Какое-то время происходящее удобно было называть минимализмом.
Но минимализм слишком хорошо описывает количество и слишком плохо — достаточность.
Минималистичный продукт вполне может быть недостаточным.
Можно оставить три кнопки, убрать подписи, спрятать настройки и получить интерфейс такой чистоты, что пользоваться им придётся исключительно силой духа.
Мне было нужно другое:
минимальная достаточность.
Столько продукта, сколько требуется, чтобы полностью решить конкретную задачу.
Не меньше.
И, что значительно сложнее, не больше.
Если задаче достаточно локального хранения, аккаунт и облако не появляются просто потому, что приложениям положено иметь аккаунты и облако.
Если AI ничего принципиально не решает, его отсутствие не является технологическим отставанием.
Если после завершения сценария пользователю больше нечего делать в приложении, не нужно срочно придумывать ему занятие.
Из этого появилась формула:
Одна задача → одно решение.
Не как слоган. Сначала это был просто удобный способ отвечать на вопрос: зачем это здесь?
А потом оказалось, что формула описывает уже не только «Не сейчас».
Она объясняет, зачем существует Niqual.
Когда имя догнало смысл
К этому моменту Niqual существовал уже несколько дней, поэтому настало время пересмотреть его многолетнее наследие.
Сначала это был красивый домен.
Потом — имя для маленьких утилит.
Теперь выяснилось, что размер вообще не был главным свойством.
«Одна задача → одно решение» впервые дала этой коробке содержательную границу.
Niqual оказался не коллекцией приложений с одинаковым интерфейсом и даже не просто брендом маленьких утилит. Общим стал способ определять их границы: одна конкретная задача и минимальный достаточный набор средств для её завершения.
А одинаковые механизмы ещё не делают разные задачи одним продуктом.
Двум продуктам может понадобиться календарь. Это не делает их одним продуктом.
Трём могут понадобиться уведомления. Это всё ещё не повод строить универсальный центр управления жизнью.
Объединять должен был метод, а не интерфейс.
В каком-то смысле Niqual оказался способом не дать маленьким продуктам слипнуться в один большой.
И имя наконец начало означать что-то кроме адреса, который мне понравился.
Продукт, из которого хочется уйти
У «Не сейчас» обнаружилась ещё одна странность.
Если оно работает правильно, пользователь может довольно долго им не пользоваться.
Если я отложила решение на две недели, мне не нужно открывать приложение завтра.
И послезавтра тоже.
На тринадцатый день отсутствие вовлечённости всё ещё не означает, что что-то пошло не так.
Наоборот.
Продукт буквально обещал оставить меня в покое.
Отсюда появилось ещё одно ограничение Niqual: возвращение пользователя само по себе не может быть целью.
Уведомление имеет смысл, когда пришло время вернуться к решению. Новое взаимодействие — когда появилась новая задача.
Придумывать третью причину только ради того, чтобы приложение открывали чаще, не требуется.
Когда работа закончена, продукт может сделать довольно нетипичную вещь.
Замолчать.
Тишина после решения
Эта формулировка появилась последней.
Тишина после решения.
Не как исходная миссия и не как формулировка, под которую потом пришлось подгонять продукт.
Она просто оказалась самым коротким названием состояния, к которому уже вели принятые решения.
До взаимодействия есть незакрытый вопрос.
Во время взаимодействия есть инструмент.
После него вопрос закрыт, а инструмент больше не требует внимания.
Тишина.
Полторы недели назад Niqual был красивым свободным доменом.
Потом стал именем для маленьких утилит.
Сейчас я бы определила его точнее: небольшие продукты, каждый из которых полностью решает одну конкретную задачу и после этого перестаёт требовать внимания.
Возможно, это определение ещё изменится.
Проекту полторы недели. Было бы несколько самонадеянно объявлять его философию завершённой.
Но одна вещь за это время уже стала достаточно ясной.
Я начинала с вопроса, как сделать продукт маленьким.
В итоге гораздо интереснее оказался другой:
Где продукт должен закончиться?
Пока мой ответ такой:
после решения.