В студенческих работах изредка встречается такой дизайн, когда программа ожидает действия пользователя и показывает при этом крутилку:
Так не должно быть: крутилка означает, что пользователь ждёт программу, а не программа пользователя. Здесь возникает двусмысленность: с одной стороны, написано «наведите», а с другой — снизу крутится крутилка, как будто программа ещё не готова, и пока рано наводить. И кому верить — непонятно.
Некоторые дизайнеры любят приносить по несколько вариантов дизайна, когда об этом не просили. Не надо так делать: это вызывает фрустрацию и недоверие.
Если вы сели рисовать второй вариант дизайна, значит вы не уверены, что первый решает задачу. Из-за чего вы сомневаетесь? Какие вопросы о задаче у вас остались непрояснёнными? Нужно задать их арт-директору или клиенту, доразобраться в задаче и принести одно решение — лучшее, на которое вы способны. Иначе получается, что вы подменяете качество работы её количеством.
В каких случаях несколько вариантов — это окей?
Во-первых, если сама задача состоит в выборе направления. Заказчик сам не знает точно, чего хочет, и ваша помощь нужна именно в этом прояснении. Вас буквально попросили показать несколько вариантов, причём вы обсудили, каких именно. Например, арт-директор говорит: «примерь вот эти 4 шрифта к макету, пожалуйста». В этом случае несколько вариантов — это и есть единственное решение поставленной задачи, которое вы и приносите.
Во-вторых, если вам так самим проще прояснить задачу. Например, вы начали рисовать макеты; пошли в одну сторону, потом засомневались в своём понимании, пошли в другую... И думаете: «надо бы показать, чтобы понять, то ли я вообще делаю». В этом случае вы приходите к заказчику и говорите не «посмотри варианты», а задаёте конкретный вопрос: «смотри, вариант с Колобком получается привлекательным, но с Чубаккой по идее юридически корректнее; помоги выбрать?»
Принято называть «совами» тех, то поздно ложится и встаёт и «жаворонками» тех, кто рано. Но эта терминология сбивает с толку.
«Рано» и «поздно» — понятия относительные: можно менять часовые пояса, переводить часы, а границы светлого и тёмного времени суток вообще меняются в течения года в огромных пределах. Но жаворонки остаются жаворонками, а совы совами. Усилием воли поменять привычку можно, но долго она не продержится — одни будут ложиться всё позже, а другие вставать всё раньше. Почему?
У меня есть простое объяснение: совам жизнь по кайфу, а жаворонкам — в тягость! Сове всегда нормально то, как есть сейчас. Если не спишь, то хочется ещё подольше не спать. Если спишь, хочется подольше поспать. А вот жаворонки всё время недовольны тем, как сейчас. Когда они бодрствуют, они стремятся поскорее лечь спать. А когда спят, думают, как бы поскорее встать. Спешат поскорее отжить, что ли, не знаю.
Допустим, вы сделали интерфейс и какое-то объяснение спрятали за вопросик:
Вытащите информацию из-за вопросика, пожалуйста, и напишите её прямо тут.
Каждый раз, когда я об этом прошу, дизайнер сначала возражает, что типа тут будет перегруз, и вообще туда нажмут только те, кому интересно. И каждый раз, когда начинаем обсуждать, что именно там прячется, выясняется, что можно вытащить наружу без проблем. Я занимаюсь интерфейсами лет двадцать, и буквально ни одного раза не сталкивался с ситуацией, когда вопросик был бы хорошим решением. Так что рекомендую просто как механический принцип: увидели вопросик — убрали к чёртям.
Парижский Нотр-Дам сгорел из-за интерфейса. Датчик возгорания штатно и вовремя сработал, и сотрудник службы безопасности увидел на экране код: ZDA-110-3-15-1. Это идентификатор конкретного места, где сработал датчик — ценнейшее знание. Однако почти полчаса сотрудник искал, где же горит, потому что не знал, что значит код, а начальник не отвечал на телефон.
По мнению многих людей, дизайн — это что-то поверхностное и необязательное. Если инженеры спроектировали и установили продвинутую систему пожаротушения, зачем звать дизайнера? Зачем тут оформление или украшение? Ладно ещё в продукте для массового потребителя — там надо пустить пыль в глаза и повысить продажи, — но в таком специальном интерфейсе как панель управления системой пожаротушения это точно лишнее?
В заметке «Инструкция против интерфейса» я писал о своём опыте работы с промышленными интерфейсами, где постоянно появляются подобные магические сообщения. Инженеры говорят с пользователями на инженерном языке, а на любые слова о непонятности отвечают примерно одно и то же:
— Сотрудники проходят обучение перед работой, а случайный человек и не должен понимать это.
Это ошибочное мнение. Компании теряют на нём деньги. Начиная с того, что само обучение обходится дорого, и заканчивая тем, что в критический момент оказывается, что сотрудник забыл, чему его там учили.
В случае с Нотр-Дамом цена такого мнения — миллиард долларов.
Я предлагаю принцип «Без обучения». Прям декларировать его как основу для всех принимаемых в дизайне решений. Я прямо отвечаю инженерам:
— Понимаю, но у нас в интерфейсах используется принцип «Без обучения». То есть мы делаем интерфейсы такими, чтобы как раз таки случайный человек мог подойти и выполнять работу. Да, без опыта он будет делать медленнее, но нужно добиться, чтобы он в итоге сделал всё правильно.
В системе пожаротушения необходимо было нарисовать план собора и расставить на нём эти датчики. Каждому датчику кроме кода нужно было поставить в соответствие текстовое описание типа: «левый шкаф за алтарём». При срабатывании датчика на экране должен появляться план с обозначением точки и текстовой подписью, а не набор бессмысленных букв и цифр. И конечно должно быть словами написано, что именно в этой точки произошло: температура выше нормы, задымление или что-то ещё.
Очень важно настроить культуру разработки, чтобы сам этот довод «Сотрудники проходят обучение» не считался валидным. Считайте, что не проходят. Что тогда?
Эта мысль в виде трёх слов давно лежит у меня в черновиках: «мелодия обесценивает тембр». Вот вам попытка раскрыть эту мысль. Это не что-то, с чем нужно спорить, это просто один из способов взглянуть на вещи.
Мелодия — это простая и очевидная штука, она на поверхности. Её можно записать нотами, поставить рингтоном на Нокию и подпеть у костра. Тембр — это сложная и глубокая штука. Его никак не записать кроме как описанием волнового процесса.
По классике тембр — это просто следствие физического устройства музыкального инструмента. Скрипка звучит вот так, а фагот — вот так, потому что вот такие колебания воздуха происходят, когда с этими предметами что-то делаешь. Тембр не является предметом композиторства; ты просто выбираешь его из набора существующих.
Когда у тебя компьютер, ты можешь записать разные инструменты и потом использовать эти записи в качестве материала для написания музыки. Это называется сэмплирование. Но ещё ты можешь создать тембр, моделируя любые волновые процессы. Это называется синтез. Тембр бесконечно глубже и разнообразнее, чем любая мелодия, но это куда более тонкие нюансы.
Когда у меня спрашивали, почему в техно нет мелодий, я всё время чувствовал, что с идеей использования мелодий в техно что-то не то, как будто мелодия всё опошлит и испортит. Казалось бы, почему нельзя заморочиться и тембром, и мелодией? Почему нельзя сыграть интересую мелодию интересным тембром?
А именно потому, что мелодия — это намного, намного более «грубая» сила. В ней разрешение в тысячу раз ниже, она перетянет на себя всё внимание, полностью обесценив всю работу над тембром. Это как взять бриллианты и собрать из них сарай для дров. Такая вам аналогия.
Технологии несовершенны, поэтому иногда компьютерам нужно время, чтобы выдать результат. Иногда тормозит сеть, иногда нужны длительные вычисления.
Работа дизайнера интерфейсов — сделать так, чтобы тормоза были как можно менее заметны пользователю. То есть создать ощущение, что всё работает быстро, даже если в реальности это не так. Часть примеров этого были в моём минском докладе об обратной связи. К сожалению, бывает и наоборот: технологии быстрые, но дизайнер перемудрил с анимациями и эффектами, и в результате создаётся, наоборот, ощущение, что всё тормозит. Такие беспричинные тормоза бесят больше всего.
В обсуждении этой проблемы читатель прислал статью об искусственном замедлении интерфейса для солидности. Типа, во многих продуктах интерфейс замедляют даже не по ошибке дизайнера, а целенаправленно, чтобы создать у пользователя впечатление, что компьютер «очень постарался» и тем самым повысить доверие к результатам.
Это и плохая статья, и плохая практика.
В начале статьи автор рассказывает об окне проверки безопасности акаунта в соцсети. Проверка — мгновенная операция, но окно специально изображает, будто процесс занимает некоторое время. Глядя на это, автор статьи, по его собственным словам, «думает, что о нём внимательно заботятся». Я не верю. Я думаю, дело было так: автор узнал про идею искусственного замедления для солидности, решил написать про это статью, нашёл это окно в качестве примера, и уже потом выдумал вступление о якобы возникающем у него чувстве заботы. Такое вступление нужно было, потому что такой подаче учит американская журналистская школа.
Дальше автор приводит примеры интерфейса, где результат отображается мгновенно. Он пишет: «such speed can make users skeptical or even confused» — «такая скорость может вызвать у пользователь скепсис или растерянность». Утверждение бессодержательно: может вызвать, а может и не вызвать; у каких-то пользователей вызовет, у каких-то нет. Или вот фраза: «Human brains expect things to take longer» — «Мозг человека ожидает, что вещи занимают больше времени». Утверждение не просто не доказано, оно недоказуемо. Сколько секунд занимают «вещи» по ожиданию мозга человека? Неужели это касается всех «вещей»? Как это вообще померить?
Нашлось в статье место и аналогии: «Let’s say you sit down at a restaurant, you order your food, and it comes out one minute later» — «Садитесь вы в ресторан, заказываете еду, и её вам приносят через минуту». Типа, раз ты тут заподозришь, что качество еды не очень, то и в интерфейсе при слишком быстром получении результата тоже засомневаешься в его качестве. Аналогия неудачная: если еду невозможно было приготовить за минуту, значит её просто разогрели; это не «ощущение», а понимание. Но если эспрессо тебе несут пятнадцать минут, вряд ли ты уверуешь в его высокое качество.
В конце автор приходит к правильной мысли, что у пользователей есть ожидания, и интерфейс их иногда нарушает. С этого можно было бы как раз начать и написать нормальную статью. Что делать, если интерфейс нарушает ожидания?
Слабый ответ — подстроиться под ожидания.
Сильный ответ — сделать хорошо и приучить к хорошему, перенастроив ожидания. Лучшие продукты превосходят ожидания, а не просто имитируют привычное-плохое.
Возьмём то же окно проверки безопасности акаунта в соцсети. Автор пишет, что его медлительность даёт возможность человеку изучить и понять каждый шаг проверки по ходу дела, а мгновенный результат бы такого не дал. Но это чушь. Можно сделать мгновенно и при этом объяснить человеку суть сделанного сколь угодно подробно. А вот изучение «по ходу дела» как раз и не гарантирует, что человек успеет прочитать и понять.
В статье автор аналогичным образом защищает тормозной интерфейс системы, рекомендующей оптимальный тариф сотовой связи. Он пишет, что при выдаче мгновенной рекомендации пользователи считали, что система не учитывала их реальную статистику, а лишь выдавала шаблонную одинаковую для всех рекомендацию. И снова проблема решается объяснением, а не замедлением. Представьте мгновенный, но подробный отчёт: «Рекомедуем вам тариф СуперПлюс. Вы в среднем делаете 3 звонка на городские номера в месяц, например в январе вы звонили... Интернет вы используете в пределах... Единственное исключение за три года было в июле, когда вам пришлось заплатить за превышение, но это меньше, чем стоил бы более дорогой тариф за все эти годы». Какому пользователю бы пришло в голову, что шаблонная рекомендация?
Наконец, автор приводит пример переделки интерфейса заявки на ипотечный кредит. В первой версии он мгновенно выдавал заключение. Пользователи воспринимали мгновенное одобрение как «предварительное» и ожидали, что настоящее решение последует позже. Тогда дизайнеры добавили поддельный медленный прогрессбар, и пользователи стали «верить» результату! Хорошо, но при чём тут «особенности человеческого мозга»? У людей есть привычка, что в банках всё медленно. Статья американская, всё понимаю, но в России банки давно приучили людей к мгновенности всего. Мы на практике знаем, что если людям однажды показать, что что-то быстро, они перестанут ожидать, что это долго!
Да, с непривычки люди могут быть удивлены мгновенности ответа. Но кем надо быть, чтобы увидев такую реакцию, из всех решений выбрать именно «сделать медленнее»? Что мешает признать в интерфейсе удивительность этого факта, написав «Your loan has been instantly approved. What’s next: ...» — «Для вас кредит одобрен мгновенно. Что дальше: ...». Нужно сразу дать человеку то, что он ожидает увидеть после окончательного решения: документы на заполнение или назначение встречи в банке. Нужно взять пользователя за руку и повести, чтобы ему в голову не пришло, что надо чего-то ещё ждать.
Такие практики берутся из поверхностных исследований без понимания фундаментальных причин возникающих эффектов. Ответственный за продукт слышит от пользователя: «я удивился, что слишком быстро» или «я подумал, что результат некачественный» и принимает решение замедлить. Ему кажется, что он открыл интересную особенность мозга и ловко её использовал, но на самом деле он просто сдался в том месте, где даже препятствия особого не было.
Все знают фразу Генри Форда, что если спрашивать покупателей, то они бы сказали, что им нужна более быстрая лошадь. И даже в случае Форда нормальное решение — не лошадь допингом кормить, а автомобиль конструировать. А у наших героев покупатели хотят более медленную лошадь, и они покорно делают! Точнее даже не так, всё ещё хуже. Покупатели даже не просят медленную, они просто удивляются быстрой, — и всё, продавец уже бежит делать медленную!
Пока я читал статью про замедление, я вспомнил, как лет десять назад читал статью про электромобиль, где инженеры занимались эмуляцией звука обычного мотора через аудиосистему. Там прям были фотки какой-то особой студии звукозаписи, где куча микрофонов висели вокруг машины, и фотка какого-то звукоинженера, который делился тонкостями этой работы. И я думал: боже, насколько нужно вообще не понимать ничего, чтобы тратить свою жизнь на такую херню! Как же можно не видеть, что если не через год, так через два все будут воспринимать бесшумность электромобиля как само собой разумеющуюся вещь? Как же можно не видеть, что реально крутые инженеры, которые хотят вкладывать свои силы в развитие электромобилей, не пойдут к вам работать, увидев этот цирк?
Я не отрицаю, что в примерах без замедления была какая-то проблема, которую нужно было решить. И, действительно, могло быть так, что шоу с замедлением «сработало» — привлекло внимание, заставило пользователей задуматься, и всё это принесло какой-то выигрыш. Но замедление может быть лишь быстрым и дешёвым способ спасти какие-то метрики, пока все думают над настоящим решением.
На месте хороших дизайнеров, я бы не работал в компании, где нужно рисовать поддельные прогрессбары. На месте хороших программистов, я бы не работал в компании, где менеджеры замедляют твою работу. Использование подобных фокусов приводит к тому, что в команде теряются компетенции делать хорошо и способность конкурировать. На работу приходят люди, не особо ценящие свой труд.
Бывает, что для того, чтобы произвести некоторое впечатление на клиента, создают бессмысленный антураж. Типа, на входе в ресторан специальный мужчина в костюме открывает перед тобой дверь. На столах уже стоят пустые тарелки и лежат приборы, половину из которых унесут, когда ты сядешь. Тебе приносят специальную раскладную подставочку для сумки. В конце ты не можешь просто оплатить еду у кассы — нужно обязательно дождаться официанта. Весь этот спектакль позволяет брать вдвое больше денег за еду.
Здесь всё в порядке, потому что никто никого не обманывает. Если я раз в три года захочу сходить в такой ресторан, я буду готов, что потрачу больше времени и денег — я буду понимать, что для меня разыгрывают целый спектакль, и что я сам на него пришёл. Но если я узнаю, что еду там разогревают в микроволновке, а выносят через 15 минут, чтобы я ощутил премиальность, то к таким мудакам я больше не приду.
Вчера в «Что послушать» я выложил в том числе серию уроков чистоты кода. Техдиректор бюро Вася Половнёв, увидев, что там 9 часов, спрашивает, как я нахожу время столько слушать. Ответил ему, но предполагаю, что вопрос может возникать у многих, так что отвечаю ещё и здесь.
Номинальные 9 часов — это реально около 4 часов прослушивания. Во-первых, всё слушается как минимум на полуторной скорости, что уже превращает 9 часов в 6. Во-вторых, Оверкаст вырезает слишком длинные паузы между словами, а это очень существенно сокращает длительность всего. Когда отвечал Васе, я даже не знал, насколько, а это даёт в среднем ещё 1,4-кратное ускорение! Хотя зависит от особенностей говорящего, конечно.
Но 4 часа — это же всё равно много? Не знаю, в день я слушаю по ощущениями около 2 часов разного — лекций, подкастов, аудиокниг.
Во время еды получается минут 15-20, ведь еду надо приготовить или разогреть, съесть, потом убрать или помуть посуду. Это три раза в день — уже почти 1 час. Пока иду на кофе и обратно — это ещё 20 минут дороги (пока пью кофе я работаю).
В день я провожу когда 10, а когда и все 50 минут за рулём. Вот уже два часа прослушивания и набралось.
А ещё перед сном минут 10 могу послушать в качестве сказки на ночь. А дальше, если я бегаю — это ещё плюс 30 минут. Если иду в бассейн — то ещё около 1 часа на дорогу туда-обратно, переодевания и занятия в спортзале перед заплывом (делаю там несколько упражнений). То есть минут 20 в среднем ещё дополнительно есть в день.
И это всё зимой, когда я не гуляю! А ведь летом я ещё гуляю. И это ещё английский язык! А ведь на русском можно слушать на двойной скорости, особенно знакомых спикеров.
Вот и получается, что «9 часов» лекций про код — это пара дней без необходимости выделять хотя бы минуту специального времени.
Вот чего я реально не понимаю — так это как люди регулярно смотрят фильмы и сериалы.
Иногда ты работаешь с длинным документом или пишешь код, прыгаешь в какую-то другую его часть и хочешь вернуться к предыдущему месту. К сожалению, нигде не предусмотрено анду или кнопки «Назад» для простого перемещения курсора.
Но я заметил, что давно уже совершенно автоматически делаю ⌘Z, ⇧⌘Z — анду и сразу реду. Это отменяет последнее действие и тут же делает его снова, то есть документ в итоге не изменяется. А зато курсор возвращается туда, где был до этого!
Я недавно делился размышлениями о том, как в погоне за метриками компании разрушают сами себя. Там, конечно, можно долго спорить, но я хочу ещё одну мысль вынести.
Говорят, что метрики — это единственный объективный источник информации для принятия решения. Типа, дизайнер со своим чутьём или мнением может ошибаться, а метрики не врут. Это не совсем правда: метрики могут неправильно собираться и ошибочно интерпретироваться, но давайте для простоты представим, что они верны и объективны. Мне даже в этом случае не кажется, что на них можно полностью положиться.
Моё возражение связано с мыслью о замене дизайна эволюцией из 23-го выпуска подкаста «Думаем дальше». Если мы полностью доверяем цифрам, то наш продукт лишён стержня, задумки, плана. Он просто куда-то дрейфует по течению. Сегодня пользователям вкатило что-то, мы стали это развивать. Завтра стало модно другое — мы стали развивать другое. Куда мы придём такими шагами через десять лет? В мутанта, где банкинг с маркетплейсом приправлен рилсами и сторисами. Никто не понимает, что там где и зачем — просто вот так получилось. Главное на это не дышать.
Мне больше нравится подход, когда всё решают люди со вкусом и мнением. Они — авторы продукта, продукт несёт их идеи. Ты доверяешь продукту, потому что понимаешь, как думают и что ценят эти люди. Да, авторы могут хотеть фигню, которая никому кроме них не нужна. Но им не запрещено свои вкус и мнение менять, если они видят, что ошибаются. Даже Стив Джобс умел менять своё мнение, так уж и остальные как-нибудь справятся!
Важно, что мнение всегда есть! Мы идём куда-то, иногда смотрим на данные для оценки своей адекватности, и, в случае чего, корректируем курс, но у нас есть курс!
Проблема с метрологами в том, что у них нет ни вкуса, ни мнения, ни курса.