Рассмотрим такой пример:

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

Как же решить эту проблему? Ну типа, всегда же может случиться ошибка? Это же не специально.

А ответ простой: никогда не нужно в интерфейсе призывать нажать на кнопку по её названию. Это само по себе означает дебильный дизайн, даже если всё внимательно проверили и такая кнопка на экране есть.

Нахрена объяснять, для чего жать на кнопку? Я что, по названию кнопки не пойму? Чтобы дать доступ, нужно нажать на кнопку «Дать доступ», чтобы продолжить — на кнопку «Продолжить», а чтобы привязать — на кнопку «Привязать». Тут авторы запутались в трёх глаголах, а глагол должен быть в принципе один на это действие. Тогда и проверять его на совпадение с чем-то ещё не придётся.

Короче:

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

Во-первых, шуточки дурацкие. То валенки называются «Неваляшка», то логистическая компания вообще «Передаст». Отдельный класс шуточек — попытка передать макетом привет преподателю, типа в описании валенок написать, что они идеальны для похода в Бергхайн, или вообще просто влепить в отзывы на услугу подпись «Бирман рекомендует».

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

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

Навал Равикант, обсуждая свою серию твитов о том, как стать богатым, называет пять самых важных навыков для человека:

• чтение,
• письмо,
• арифметика,
• убеждение,
• программирование.

Вот эта же мысль в пересказе-переводе Вани Замесина:

Я бы сказал, что есть пять самых важных навыков — это, конечно, чтение, письмо, арифметика и ‹...› навык убеждения, то есть умение говорить. Плюс, я бы добавил сюда программирование, потому что это прикладная форма арифметики, которая даёт вам много бесплатных рычагов в любой сфере, в которой вы работаете.

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

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

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

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

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

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

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

— Привет, я от Марины. Она сказала написать тебе.

От какой Марины? О чём речь?

— Привет, это Вика по поводу конференции.

Какой конференции? Когда, где? Ну у вас же не единственная конференция во вселенной!

— Привет, хочу сказать спасибо за твой удобный продукт!

Очень приятно, а какой?

— Привет, Маша сказала у тебя был какой-то вопрос по поводу завтра.

Какая Маша? Что именно завтра? У меня много вопросов по поводу каждого дня.

— Привет, раньше вы переписывались с Михаилом. Насчёт рекламы всё в силе?

Ну вы поняли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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