Любое изменение в разработке имеет значение

Перевод материала из блога компании Intercom.

«Мы хотим уменьшить размер отзывов на продукт до 140 знаков, потому что когда-нибудь, возможно, захотим использовать SMS. Это незначительное изменение, ведь так?»

Нет, не так.

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

Опыт работы в консалтинге, где платят за время, научил меня задавать некоторые вопросы, прежде чем приниматься за «незначительные изменения». Давайте начнём с нескольких простых.

Что делать, если отзыв больше 140 знаков? Убрать лишние строки или просто вывести на экран ошибку? Если выводить ошибку, где её показывать? Что писать? Кто будет писать текст ошибки? Как объяснить пользователю, почему установлен лимит в 140 знаков? Как будет выглядеть ошибка? Стиль уже выбран? Если нет, то кто будет его разрабатывать?

Даже если вдруг у нас и есть ответы на все выше поставленные вопросы, это ещё не конец. Выдавать ошибку на стороне сервера — плохое решение. Это должно быть на стороне клиента. Но если мы решаемся на валидацию со стороны клиента, следует ещё ряд вопросов…

Кто будет писать JavaScript? JavaScript будет отображать тот же тип ошибок, что и код сервера? Если нет, то какой новый стиль использовать? Как он работает без JavaScript? Как убедиться, что лимит в 140 символов работает с валидацией на стороне сервера и на стороне клиента?

И это тоже ещё не конец. Посмотрите на эту ситуацию глазами пользователей. Они уже недовольны тем, что их отзыв ограничен 140 знаками по какой-то странной причине, непонятной им, а теперь мы предлагаем им угадать, насколько длинное у них сообщение? Должен быть иной путь. Давайте добавим счётчик знаков. Ах да, ведь тогда появляется ещё больше вопросов…

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

Кстати, а где этот счётчик будет отображаться? Как он выглядит? Конечно, стиль должен поменяться, когда пользователь приближается к лимиту, и должен отображать ошибку, когда пользователь превысит лимит... Или нужно запретить ввод символов после превышения лимита? Если да, то что произойдёт, когда пользователь скопирует и вставит текст в окошко? Нужно разрешить редактирование или предупредить о превышении лимита?

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

Всё вышеописанное не учитывает замешательство пользователя, который не понимает, почему кто-то до него смог написать отзыв на 80 слов, а ему теперь даётся только 140 символов. Очевидно, служба поддержки должна быть готова к вопросам от пользователей, а мы должны обновить документацию, API, приложения на iPhone и Android. Кстати, что делать с прошлыми отзывами? Убрать лишние символы или оставить без изменений?

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

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

Да, это были пустые слова. Опытные разработчики могут быстро решить большинство перечисленных проблем. Но не все проблемы. Да, можно использовать "maxlength", но это снимает только один из вопросов (и только при кодировании в HTML5).

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

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

#дизайн