Куда ни посмотришь — всюду статьи о лояльности клиентов, об удовлетворённости пользователей, об интуитивной понятности интерфейсов и о прочем подобном. Хватит уже об этом. Поговорим лучше о создании плохого софта, такого, поработав с которым, пользователь возненавидит и сам этот софт, и его разработчиков, и свои мышь с клавиатурой заодно.
Я — инженер-программист, занимаюсь разработкой коммерческих приложений более пяти лет. Со временем я начал замечать, что плохо спроектированные приложения могут вызывать у пользователей весьма и весьма отрицательные эмоции. То, насколько совершенна архитектура приложения с технической точки зрения, тут совершенно неважно. Если программа не помогает пользователю решить его задачи, если она не упрощает его жизнь и не соответствует ожиданиям — ждите волны негатива. Если именно этого вы и добиваетесь — значит — собранные здесь советы помогут вам довести ваших пользователей до белого каления.
А если серьёзно, то цель этой подборки — обратить внимание разработчиков на распространённые ошибки, напомнить о важных элементах программных проектов и помочь в деле построения здоровых взаимоотношений с пользователями.
Совет №1. Чем медленнее — тем лучше
Скорость — наш враг. Нельзя, чтобы приложение загружало что-нибудь быстрее, чем за пять секунд. А ещё лучше — пусть это будет хотя бы секунд пятнадцать.
Не используйте, ни в каком виде, фоновую обработку задач. Пусть пользователь смотрит на пустой неподвижный экран, не зная, что происходит, и проклинает всё и вся.
Совет №2. Игнорируйте предложения и пожелания пользователей
Пользователи предлагают добавить в программу новую возможность? Что бы это ни было, пусть, для выполнения просьбы нужна пара строк кода, отвечайте так: «Это невозможно». Даже не думайте о том, чтобы обсуждать подобные предложения с коллегами. Отшейте пользователя — и проблемы как ни бывало.
Если юзер вам попался очень уж упорный, можете накормить его пространными фразами: «Это не соответствует функционалу нашего приложения», или: «Я ничем помочь не могу, это обязанности другого сотрудника».
Совет №3. Не заботьтесь о времени безотказной работы приложения
Всякие «соглашения об уровне предоставления услуг» — глупости. Совершенно нормально, если система будет наглухо виснуть каждые несколько минут. А ещё лучше, если речь идёт о программе, которая, скажем, используется для обслуживания клиентов. Например — на кассе.
Когда сбой случается на рабочем месте, так или иначе огороженном от чужого внимания — это одно. Совсем другое — если ваш пользователь сможет объявить о том, что программа зависла, очереди из десяти человек. Это даст ему прекрасную возможность прилюдно выразить всё, что он думает об этой «программе».
Совет №4. Стремитесь к самому новому
Если вы делаете проект для крупной компании и вынуждены постоянно проводить совещания с её представителями, тратьте всё время совещаний, говоря о том, как замечателен этот новейший фреймворк XYZ, который вы используете. Очень важно, чтобы у вашего клиента не было возможности и рта раскрыть, в результате он не сможет сказать какую-нибудь ерунду о том, что его компании нужен какой-то там новый отчёт. Через полгода начинайте ругать тот же самый фреймворк по какой-нибудь случайной причине, говорите о том, что это было ошибкой — выбрать его на волне нездоровой популярности. Опять же, это очень важно — не давайте клиенту говорить, так как он непременно начнёт спрашивать об отчёте, разговора о котором вы очень долго и старательно избегали.
Если вы следите за событиями в среде JavaScript, значит — вы понимаете — о чём я говорю.
Совет №5. Обновляйте веб-страницы целиком
Интерфейс — это монолит. Нечто вроде асинхронной загрузки отдельных элементов — вредная практика. Все действия, которые выполняет пользователь, скажем, в веб-приложении, должны приводить к перезагрузке всей страницы. Позицию, где был пользователь до этого, запоминать не нужно. В результате у него появится возможность прокрутить страницу до того места, где он что-то делал, и посмотреть — что получилось.
Совет №6. Ваш софт — это просто, любой сможет его понять
Справки, всякие «руководства по началу работы», ненавязчиво знакомящие пользователей с основными возможностями программы — это излишество. Ваши программы настолько просты и понятны, что любой сможет работать в них без каких бы то ни было проблем.
Совет №7. Проверка форм — не ваше дело
Просто представьте, как это замечательно — ввести данные в форму, ошибиться в какой-нибудь мелочи, и, после её отправки и перезагрузки страницы, увидеть снова ту же форму с пустыми полями. Это не ваша вина, если пользователь неправильно понял, что куда надо вводить.
Совет №8. Ваше мнение — это единственное, что имеет значение
Никогда не спрашивайте у пользователей о том, что они думают о программе или о какой-нибудь её функции. Запомните — это очень важно. Никогда. Вы — гений, каких во всём мире можно пересчитать по пальцам одной руки. Вы — светоч программирования. Ваше мнение — это всё, что должно вас заботить.
Совет №9. Чем больше загадочности — тем лучше
Пусть всё в вашем софте будет загадочным. Например — не делайте никаких подсказок-заполнителей в полях ввода. Пользователю нужна программа — сам обо всём догадается. Кроме того, у такого подхода есть приятный побочный эффект — при случае можно с видом профессионала рассказывать друзьям о том, какие же ваши пользователи тупицы.
Совет №10. Никаких напоминаний, автообновлений и уведомлений
Электронные письма с напоминаниями, текстовые сообщения, push-уведомления, автоматическая загрузка новых данных из Сети — это для лентяев. Ваш пользователь должен сам всё проверять. Ждёт новое сообщение? Никакой автоматики — сам зашёл на нужную страницу, обновил её, ну а дальше — как повезёт. Как часто ему это придётся делать — нас не касается.
Совет №11. Побольше таинственных слов
Ваша программа — это ваши правила, это, кроме прочего, отражение вашего словарного запаса. Если некий усреднённый пользователь чего-то не поймёт — это исключительно его проблема. Вот пара примеров, на которые стоит ориентироваться: «Асинхронный запрос через прокси-браузер», «Криптографическая соль».
Совет №12. Интуитивная понятность — это не к нам
Делайте с интерфейсом всё, что пожелаете. Например, значок дискеты можете использовать для удаления записей, а звёздочку — в качестве кнопки выхода из системы. При этом не забудьте записать процесс работы с вашей системой, используя что-то вроде HotJar (и снимите пользователя скрытой камерой). Наберётся материал для смешных гифок.
Совет №13. Экран загрузки должен быть всегда и везде
Экран загрузки, а ещё лучше — такой, который держится перед глазами очень долго — это непременный атрибут любой софтины. Даже у простейшего калькулятора должен быть такой. Он позволит пользователю как следует настроиться на работу с программой, заранее оценить её возможности и преимущества.
Итоги
Надеемся, приведённые здесь советы помогут вам писать по-настоящему отвратительный софт. Как видите, это не так уж и сложно. Хотя, вполне возможно, найдутся и такие разработчики, которые нашим рекомендациям не последуют и решат сделать всё наоборот.
Уважаемые читатели! А какими «вредными советами» о разработке ПО можете поделиться вы?
Автор: ru_vds
