Эмодзи передают легкомысленность и неряшливость, это понятно, борюсь с этим раком текста везде, где могу. И вот мне попадается исследование, в заголовке которого написано: «Эмодзи в теме письма вызывают негативное отношение к письму и не увеличивают шансы открытия».

Ну разумеется! Казалось бы, я должен ликовать: вот оно, научное подтверждение моей правоты! Любой дизайнер на моём месте бы пошёл говорить: «Я читал исследование, что эмодзи бесполезны» и «Доказано, что эмодзи вредят репутации».

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

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

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

Причём все цифры отличаются еле-еле.

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

Это также открывает глаза на то, чего стоит провести реальное исследование. Казалось бы, простой вопрос: «Есть ли толк ставить эмодзи в письма?» Легко представляю себе совещание, где дизайнер поспорил с маркетологом, а менеджер сказал «давайте проведём исследование!». Ну давайте, проведите, ага.

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

Итак, дизайн давно принят, вовсю идёт разработка, и вот в ходе очередной плановой встречи в обсуждении каких-то деталей к дизайну возникает вопрос. Программисты видят непоследовательность и спрашивают: «Как это должно работать?». Дизайнер начинает объяснять, и в этот момент сам понимает, что дизайн небезупречен.

Недавно сам был в такой ситуации. Это довольно некомфортно: ты должен объяснять, как что-то работает, когда уже сам видишь, что не прям волшебно-то оно работает. Говоришь такой: «А если нажать вот сюда, то открывается то-то», а программисты такие вкрадчиво: «а если у меня экран прокручен ниже?..» И ты начинаешь метаться между тем, чтобы объяснить, как задумано, и тем, чтобы придумать улучшение.

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

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

Дорогие дизайнеры! Ошибки случаются, это нормально. Признание ошибки в уже принятом дизайне не означает, что вы становитесь должны всё переделать. Важно, чтобы и вы, и клиент это понимали. Иначе чтобы защититься от внеурочной работы вам придётся усиленно делать вид, что ошибки нет, а это некоторое безумие. Надо говорить уверенно: «Да, я накосячил, готов исправить за сто тыщ» (например). Ну и стремиться не косячить в следующий раз, конечно.

Бывает ситуации, когда встречи о дизайне с программистами идут туго. Программисты накидывают непонятные претензии к дизайну:
— Зачем нужна штука X? А почему бы не сделать вместо неё штуку Y.

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

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

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

Если же проблема в сложности реализации, то тут нужно не между вариантами X и Y выбирать, а разобраться, в чём сложность. Возможно, дизайнеры предложат вообще вариант Z с учётом технических ограничений.

Дорогие программисты! Не бойтесь говорить сразу о технических ограничениях, не пытаясь замаскировать их под разговоры о дизайне. Чем смелее вы будете в этом, тем быстрее дизайнеры начнут разбираться в том, что у вас там происходит, и тем проще вам в будущем будет находить общий язык. Возможно, дизайнеры сразу начнут приносить удобный для реализации дизайн. А с другой стороны, принося неудобный, они будут вынуждены убедительнее защищать его и обосновывать необходимость приложения особых усилий. Тогда и вы лучше начнёте лучше разбираться в том, что у нас тут происходит.

До какой степени дизайн может меняться при адаптации под мобилу?

У меня есть такой критерий: мобильный и десктопный дизайны должны быть взаимоузнаваемы. Если я пользовался сайтом на компьютере, а потом зашёл с телефона, всё должно быть в ожидаемых местах. Ну и наоборот.

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

Я не согласен с идеей разделения сценариев. Это когда рассуждают в духе: «На мобиле обычно люди смотрят на бегу, поэтому им важнее раздел X, чем раздел Y, так что давайте поставим его выше». Тут нарушается принцип взаимоузнаваемости.

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

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

— Единственный момент, у нас не работает терминал, нужно будет переводом оплатить.

— Единственный момент, я на встрече буду не один, а с коллегой.

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

Я сейчас поймал себя на том, что написал в сообщении «единственный момент» перед реально мелким нюансом, который ни на что не влияет, но получилось, будто я оправдываюсь. Удалил — стало нормально, просто проинформировал.

А в предыдущих моих примерах если удалить «единственный момент», нормально не получится.

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

В Иллюстраторе если выделить часть точек объекта, подвинуть эти точки, а потом нажать анду, точки-то вернутся на место, но выделение изменится. Придётся заново выделять, чтобы подвинуть правильно.

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

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

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

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

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

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

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

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

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

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

Поделюсь примером с недавней встречи с дизайнером. Она показывает дизайн опроса, где можно выбрать из набора галочек или дать свой вариант:

Я говорю, мол, странно, что это выбор — вдруг я хочу выбрать кофе и чай, а ещё дополнить своим вариантом? Логичнее было бы дать просто четвёртый чекбокс «Свой вариант», при включении которого появлялось бы поле. Она соглашается, но говорит, что программисты уже так запрограммировали бэкенд, что нельзя одновременно и предложение, и свой вариант прислать — типа он ожидает от фронтенда либо три логических значения, либо одно текстовое.

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

Рисуем нормально с четвёртым чекбоксом:

Если четвёртый чекбокс выключен, отправляем три логических значения первых трёх, а если включён, то отправляем текстом через запятую то, что выбрано в первых трёх, а потом ещё и свой вариант следом. Криво? Да. Но это у программистов криво, а у пользователя-то всё нормально.

Кстати, программисты когда увидели, прониклись и переписали фронтенд нормально.

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

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

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

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

Если в вашем продукте встречается такое использование, имеет смысл придумать отдельный компонент. Это как бы поле ввода без возможности ввода, поле ввода только для чтения или, если уж совсем честно, поле вывода. Его дизайн должен учитывать и требование удобства чтения, и требование «дружбы» с остальными элементами формы.

Например:

Выглядит шумновато, но зато передаёт ощущение, что это напечатано и неизменяемо.

Или можно так, если хочется поспокойнее:

Разберём такую задачку.

На некоем сайте рекламодатели могут купить размещение своего логотипа в профилях пользователей. Например, условная фирма «Спотифай» хочет как бы стать «спонсором» всех пользователей, которые любят музыку. Если пользователь бесплатный, то назначение такого спонсора — предмет договорённостей сайта и самих спонсоров. А вот платный пользователь может сам выбрать себе спонсора (вдруг ему кто-то напрямую заплатил за размещение своего логотипа) или запретить отображение спонсора вовсе.

Нужно сделать интерфейс управления спонсорством в личном кабинете пользователя, заодно показав преимущества платной подписки.

Исходный интерфейс работает так. Пока ты бесплатный, ты видишь «навязанного» спонсора и кнопку апгрейда рядом:

Если проапгрейдился, то интерфейс становится более развесистым. Можно назначить своего спонсора или удалить спонсора:

Типа назначили своего:

Чтобы убрать спонсора вообще, жмём Remove sponsor сверху. А круглая стрелочка — это вернуть как было, то есть поставить назначенного «сверху» спонсора, хоть ты и платник.

Что здесь не так?

Во-первых, интерфейс выглядит запутанно и неэлегантно. Зачем кнопка Remove sponsor, если я могу просто не заполнять спонсора? Или это чем-то отличается? Крутилка тоже непонятная без объяснения. Да и даже если всё понять, всё равно выходит каша из состояний, полный перечень которых неочевиден. Эти все состояния ведь надо ещё запрограммировать. Если я удалю спонсора, то видимо должна будет появиться какая-то кнопка «указать своего спонсора»? Или ремув просто очистит поля?

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

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

А вот как можно было бы сделать. Впрямую обозначить доступные варианты спонсорства:

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

Ну а если проапгрейдился — все те же варианты доступны в тех же местах:

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

Приходите на мой курс «Пользовательский интерфейс и представление информации», что ли.