Hi-Tech

Упрощайте, не надейтесь на чат-ботов, откажитесь от лишних фич — 11 советов разработчикам от основателя Caramba Switcher

До этого я 16 лет делал Punto Switcher, и некоторые из читателей наверняка так или иначе знакомы с этой программой. 21 июня 2018 года мы стартовали проект по созданию нового, автоматического переключателя клавиатуры Caramba Switcher.

В закладки

Вид из Caramba Studio на Дагомыс

За год программа была установлена на 40 тысячах компьютеров. Через пару дней после запуска новость о нашем новом проекте написали в vc.ru, потом там же вышло большое интервью, и понеслось! Получили в результате одного пользователя, и больше с рекламой не развлекались. Для нас это что-то невероятное, так как на продвижение программы мы потратили примерно 126 рублей: попробовали таргетинг в Фейсбуке.

То, с какой готовностью сообщество откликалось на наши идеи и помогало шлифовать шероховатости и неровности, стало для нас главным вдохновляющим фактором. За минувший год у нас вышло более 50 обновлений, появились версии Caramba Switcher LAB и Corporate, поддержка еще нескольких языков, и много чего другого.

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

Cервис для переключения раскладки Caramba…

Сообщаем, что бета-версия Caramba Switcher for Mac готова к публичному тестированию. Друзья!

vc.ru

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

Поддерживайте связь со своими пользователями: FAQ и чат-боты могут лишить вас этого

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

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

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

Не только на физическом, но и на метафизическом уровне. Важно, чтобы разработчики понимали, что первые пользователи – это «золотой запас» проекта. При этом разработчик не должен обольщаться, что он всё решает, ведь любой софт без пользователей, даже очень совершенный — это смешной и бесполезный артефакт.

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

А потом сделанное оказывается ниже уровня ожиданий и в результате: «Пффф…». Заметил, что если в продукте что-то афишируется заранее, обещается, то люди начинают ждать, и чем дольше они ждут, тем больше вырастает в их воображении значимость этого изменения. Так не теряется «дофаминовый эффект» — приятное чувство при открытии чего-то нового, своего рода unboxing. Поэтому анонсировать стоит только реально сделанное, когда остается только нажать кнопку "Опубликовать".

Не нужно удерживать пользователя любой ценой

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

Каждый человек, будь то пользователь или разработчик должны иметь свободу и радость выбора. Естественно, идея удержания любой ценой породила и у пользователей некий майндсет: «я уйду к конкурентам», «вот только что вы лишились кастомера». Не стоит бояться что человек куда-то пойдет и там найдет свое счастье:)

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

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

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

Часто на начальном этапе разработки софта или сервиса есть несовершенства, которые никак не видны. Мы обнаружили интересный принцип который назвали "long tail pressure" или "давление длинного хвоста". Естественно, нужно быть готовым к появлению такого рода давления и к работам по разрешению таких ситуаций (часто внеплановым). Но по мере роста числа пользователей, на больших числах, например, на сотне тысяч человек, редкая ошибка в работе программы у одного процента может создать одну тысячу проблемных случаев.

Не давайте проекту «покрыться пылью» — обновляйте сайт и соцсети

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

Удивительно, что это также касается нематериальных объектов, например, софта, где вроде бы пыли не видно. Если продукт не обновлять, не чистить, не заниматься им, то он покрывается некой «пылью». Они хотят иметь дело с чем-то живым, даже если оно еще несовершенно. Почему-то люди все равно ощущают запустение. И если на сайте перестают обновлять даты в копирайте, то даже это уже плохой симптом. Именно живость является признаком развития.

Желательно постоянно его тюнинговать, особенно тексты: выжимать из них воду, полировать неровности. Сайт – это отдельная тема. Через сайт происходит первое общение с пользователем. Иногда мы это делаем несколько раз в день, особенно, если приходит репорт с непонятками.

Первая волна пользователей явно читает то, что написано на сайте. Заметили — чем понятнее становится сайт, тем меньше недоумений. На просмотр нового сайта тратится от 30 до 60 секунд: поэтому желательно, чтобы текста было ровно столько, чтобы его можно было прочитать за минуту.

Сначала решайте маленькие задачи, крупные можно оставить на потом

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

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

Всё должно быть понятным — даже номера версий софта

Это заметно в продуктах Apple и в продуктах японской дизайнерской компании Muji. В минимализме вся сложность прячется в высоком качестве материала, полировке и в новом развороте старой идеи. Apple часто даже не рассказывает про свои новые функции, на них натыкаешься случайно, и всегда радуешься, тот самый "дофаминовый выстрел":) Вся сложность и качество спрятаны внутри.

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

Изначально номера версий были понятны — Word 6 становился Word 7 и это что-то говорило пользователю и было значимо. Одним из носителей информации по поводу изменений обычно является версия продукта. 1. Потом номер версии ушел из названия и стал дополнительным обозначением, сообщающим, что в продукте были произведены небольшие изменения, например, WinRar 2.

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

0. ABBYY PDF Transformer 12. 225 104.

4. Foxit Reader 9. 16828 1.

Номер версии Карамбы – это дата производства продукта, как в глазированном сырке. Мы решили нарушить эту традицию и сделать номер версии ясным для пользователя. 06. Номер версии передает единственно важную и нужную информацию – о ее свежести: Caramba Switcher 2019. 20.

Уведомления не должны мешать пользователю

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

Обычно после совпадения нескольких паттернов: нескольких минут отсутствия активности работы на клавиатуре, кликов мышки, отсутствие показа видео. Это привело нас к понятию «right time» — времени когда пользователю что-то может быть предложено, например, обновление.

Чем меньше настроек — тем лучше

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

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

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

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

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

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

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

Персональный опыт — не всегда правильный

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

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

«Я вам вчера писал, что не переключает, извините! В том числе проблема может возникать не только в софте и компьютере, но и в сознании пользователя. Знаем по себе 🙂 Сегодня я проверил — оказывается, что переключает!» Такие когнитивные глюки объяснимы — когда сидишь за компом без перерывов по 12 часов в сутки, то всякое возможно!

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

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

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

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

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

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

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

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

Сделать это мы, конечно, можем, но это придется поддерживать в работоспособном состоянии годами. Достаточно часто нам пишут: «Сделайте чтобы значок был красного цвета» или «Хочу перевод транслита на лету». Что отвлечет нас от по-настоящему важной задачи – качественного автопереключения.

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

Недавно человек написал: «А вы кроме даблшифта оставьте Break на отмену, без всяких настроек, пусть будет два варианта, последний — для тех кто привык». Конечно, бывают приятные исключения. Мы сами почему-то не додумались. Вот это гениально и просто – и было сделано за 2 минуты.

Заключение

В Карамбе не будет: ручных настроек по включению и выключению множества опций, звуков, флажков, автозамены. Продолжая наше совместное путешествие по разработке и улучшению Caramba Switcher, мы сразу честно хотим сказать нашим теперешним и будущим пользователям, чего мы не имеем возможности делать — "новый, старый Punto".

Это чудесные программы, и мы будем рады, если они подойдут вам больше. Все это есть в уже существующих на рынке продуктах – в Punto Switcher, в Everylang, в Mahou.

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

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»