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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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