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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому анонсировать стоит только реально сделанное, когда остается только нажать кнопку «Опубликовать». Так не теряется «дофаминовый эффект» — приятное чувство при открытии чего-то нового, своего рода анбоксинг.

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

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

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

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

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

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

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

Мы обнаружили интересный принцип, который назвали «long tail pressure», или «давление длинного хвоста». Часто на начальном этапе разработки софта или сервиса есть несовершенства, которые никак не видны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ABBYY PDF Transformer 12.0.104.225

Foxit Reader 9.4.1.16828

Мы решили нарушить эту традицию и сделать номер версии ясным для пользователя. Номер версии «Карамбы» — это дата производства продукта, как в глазированном сырке. Номер версии передаёт единственно важную и нужную информацию — о её свежести: Caramba Switcher 2019.06.20.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

0
43 комментария
Написать комментарий...
Sam Beckett

А что можно было 16 лет делать в Punto Switcher? Какие фичи?

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Mikael Gevorkyan

А как монетизируется проект?

Ответить
Развернуть ветку
Стартапер-пессимист

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

Надеюсь, что компьютерная грамотность людей будет расти и такие программы никому не понадобятся.

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Что то ленинское в этом — "Надеюсь, что компьютерная грамотность людей будет расти"! Пока мы наблюдаем обратное:)

Ответить
Развернуть ветку
Sam Beckett

Серьезно? Прям вот обратное? Лет 16 назад никто особо компьютером пользоваться не умел, не то что интернетом. А сейчас даже пенсионеры тусят в соцсетях. Так что не понимаю о чем вы.

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Вы вероятно путаете умение посмотреть фильм в Одноклассниках, с пониманием как работает и настраивается система:)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Иван Щербина

Не понимаешь — ну так и проходи мимо, хули ты тут пиздишь.

Ответить
Развернуть ветку
VVilliam Blake

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

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Спасибо! Постараемся сделать лучше чем было!

Ответить
Развернуть ветку
Нюська Абрамова

на Linux бы выкатили?

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Увы, пока нет в команде линуксоида:(

Ответить
Развернуть ветку
Lev Lybin

Что в gnome что в kde (xfce и др.) есть настройка запоминать раскладку на окно. Перешли в телеграм, переключились на русский, вернулись в код, там был английский, вернётся английский, кто-то написал в телеграм - перешли, с прошлого раза русский вернётся. Мне этого вполне хватает, только на паролях порой туплю ) и тут вопрос конфиденциальности, я бы не доверял проприетарному софту следить за всеми моими нажатиями. Но когда был молод пунтосвитчер юзал ;)

Ответить
Развернуть ветку
Sergey Moskalev
Автор

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

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Откройте версию для Win и посчитайте:) У меня получилось 96 настроек. Про их комбинации и говорить нечего.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Sergey Makhalov

Чудесная программа, при автопереключении раскладки при написании обычного текста на английском и русском - блеск, удобнее, чем Punto.
Но в том, что касается работы с кодом - адский ад. При написании кода частенько приходится переключаться с английского на русский для написания тех же комментариев и заметок для коллег - вот тут начинаются пляски. Приходится отключать автопереключение. Но параллельно работе с кодом перескакиваю в другие программы - мессенджеры, почту, документы - снова приходится включать автопереключение в Caramba. Неудобно от отсутствия возможности внести ряд программ или отдельных окон в режим исключения, от отсутствия возможности указания своих собственных исключений.
Дополнительными пожеланиями также хочу попросить реализовать когда нибудь возможность перевода текстов командами из uppercase в lowercase и из кириллицы в transkriptsiyu na latinitse.
И удачи проекту!

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Сергей, спасибо, что потратили время на тестирование и репорт! Мы сейчас собираем список программ в которых Карамба для Мак должна быть отключена. Пришлите, пожалуйста, сюда, что нужно добавить: [email protected]

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Yan Kazachkov

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Кирилл Лагучевский

все просто, глобальный поиск можно повесить на win+f если это винда.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Сергей, где конкретно помешала программа и чем? Внесем в исключения!

Ответить
Развернуть ветку
Кирилл Бородин

Я снёс после мучений написания кода в Sublime Text. Так и не удалось договориться со свитчером.

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Принято! В win версии автопереключение в Sublime Text отключено. Проделаем то же самое в Mac версии. Спасибо что потратили время на тестирование!

Ответить
Развернуть ветку
Кирилл Бородин

Были ещё проблемы с автоисправлением в Windows 10, когда свитчер и Виндоус одновременно пытались исправить текст. В итоге получались куски из разных слов и склеенные непонятным образом слова. Подробнее сейчас не напишу - в прошлом году было дело.

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Спасибо! Посмотрим, действительно конфликт может возникать.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Да, в средах разработки от автопереключения одни страдания!

Ответить
Развернуть ветку
GrimCap

В Visual Studio вроде норм

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Roma Razmiki

А функция Дневник у вас тоже включена и работает незаметно?)

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Да, тихонько так работает, отсылает все куда надо:)

Ответить
Развернуть ветку
Vitalii Vorobiov

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

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Виталий! Автопереключение в Карамбе основная фича! Не работает? Языки англ-русск стандартные?

Ответить
Развернуть ветку
Vitalii Vorobiov

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

Ответить
Развернуть ветку
Vitalii Vorobiov

Получил еще обратную связь - в Webstorm не переключает. Например вфеф.
В бразуере норм, переключил в data.

Ответить
Развернуть ветку
Vitalii Vorobiov

В sublime text такая же проблема

Ответить
Развернуть ветку
Denis Vasilyev

Выжимка. Экономия - 10 тыс. символов (без упрека автору).

Советы разработчикам от создателя Punto Switcher

1. в 2018 году мы запустили новый проект - Caramba Switcher. Ниже идеи, которые помогали нам создать этот продукт

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

3. следите, чтобы FAQ и чат-бот не стали препятствием для живого фидбека

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

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

6. не нужно удерживать пользователей любой ценой. Это создает бесполезную нервозность: «я уйду к конкурентам»; «вот только что вы лишились кастомера». Лучше всем иметь свободу и радость выбора

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

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

9. более перспективная (хотя и более сложная) задача - понять, что беспокоит тех, кто не знает как написать в поддержку

10. long tail pressure - несовершенства продукта, которые не видны на начальном этапе разработки, но которые всплывают при увеличении пользовательской базы

11. не давайте проекту «покрыться пылью» — обновляйте сайт и соцсети. Пользователь не хочет садиться в тонущий корабль. Изображайте “живость” проекта всеми силами. Обновляйте год в копирайте

12. 30-60 секунд должно быть достаточно для ознакомления с главной информацией на сайте

13. лучше сделать маленькую и важную задачу сначала, а большую и важную — потом. Иначе можно и большую задачу не решить, и не сделать то, на что ушёл бы час

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

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

16. изначально номера версий были понятны — Word 6 становился Word 7. Потом в номере добавилась дополнительная цифра для обозначение небольших изменений. Например, WinRar 2.1. Затем появилась третья цифра, обозначающая багфикс. Затем четвёртое число после точки — номера сборки или ревизии кодовой базы в SVN. В конце номер перестает что-то говорить пользователю: Foxit Reader 9.4.1.16828.

17. номер нашей программы содержит только информацию о ее свежести: Caramba Switcher 2019.06.20

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

19. чем меньше настроек, тем лучше. На самом деле, у нас сотни настроек, просто они спрятаны внутри «Карамбы» и активируются динамически

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

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

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

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

24. экономия в этом смысле - важный элемент разработки хороших продуктов

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

26. хелп - это капитуляция разработчика. Для ложки и вилки хелп не нужен

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

28. проблема может возникать не только в софте и компьютере, но и в сознании пользователя. «Я вам вчера писал, что не переключает, извините! Сегодня я проверил — оказывается, что переключает!»

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

Ответить
Развернуть ветку
Denis Vasilyev

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

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Paul Ternavskii

Что то не нашел информации о том как убрать программу из исключений,я тут доки заполняю в Adobe Acrobat reader а программа не переключает языки, По моему должен быть какой то минимум настроек для пользователя,не всё же машине решать.

Ответить
Развернуть ветку
Александр Довгуша

Вопрос - почему нет настройки, чтобы добавить слово - исключение? Аббревиатуры, части пароля и пр?

Ответить
Развернуть ветку
Vitaly Danilkin

Вы будто из нулевых к нам пришли)
1. FAQ и чат боты создают в первую очередь для того, чтобы разгрузить колл центр, иначе при росте пользователей будете множить косты на менеджеров
2. Одна из основных целей любого продукта увеличивать возвращаемость пользователей, у вас что продактов нет?
3. Конечно не нужно ориентироваться на продвинутых пользователей, кэп!
4. Обновлять дизайн и держать сети up to date надо в первую очередь для привлечения новых пользователей - не будете этого делать, подрастающее поколение к вам не придет
5. Действительно в 2019 году нельзя делать сразу большой и сложный продукт?) Вы серьезно решили об этом написать?)
6. Дальше одни клише, читать невозможно, пффф

Ответить
Развернуть ветку
Sergey Moskalev
Автор

Читать невозможно, но до конца дочитал:)))

Ответить
Развернуть ветку
Sergey Moskalev
Автор

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

Ответить
Развернуть ветку
40 комментариев
Раскрывать всегда