Не портите презентацию оправданиями

Часто на дизайн-синках слышу фразы: «Ребята, это черновик, особо не смотрите» или «Я не успел проработать, было много встреч. Да и задачу плохо поставили».

Мне кажется, что этого можно не говорить. Почему?

В начале встречи внимание к спикеру максимальное. Но когда он сам говорит о том, что это «сырая» работа, желание что-либо смотреть пропадает.

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

Не надо говорить, что работа пока «черновик» — это и так понятно, мы же и собрались, чтобы ее обсудить.

Чем заменить?

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

А лучше уже в процессе сказать: «Сценарий обработки заявки я еще не доработал, не него не смотрите». Или заранее сделать что-то вроде заглушки «тут будет такой-то сценарий».

Короч, показывайте черновик и не начинайте встречу с самоуничижения.

Приложение Яндекс Трекер

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

Почему? Потому что раньше на развитие было мало ресурсов, и делали на «энтузиазме».

В этом году взялись за него всерьёз. Сделали исследование, выяснили самые необходимые сценарии и начали дорабатывать продукт.

Большую часть приложения спроектировал ведущий дизайнер из команды, я тоже чуть приложил руку — сделал сценарии для учёта времени и напоминаний (про них, возможно, отдельно расскажу).

Отдельное спасибо команде разработки: они затащили огромную часть работы.

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

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

🙏 Если вы пользуетесь приложением, поставьте оценку или напишите отзыв в App Store / Google Play. Это помогает нам расти и мы читаем все комментарии.

Кредит доверия: часть 1

Кто-то делает 10 вариантов логотипа, чтобы угодить клиенту. А кто-то один, да еще и за 100.000 долларов. Дело не только в скиле, но и в кредите доверия, когда заочно верят твоему решению.

Я прочитал эту историю в книге-биографии Стива Джобса: он обращался к Полу Рэнду, известному как гуру корпоративного дизайна, за логотипом для новой компании Next.

Когда Джобс попросил создать несколько вариантов, Рэнд ответил:

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

Джобс согласился: его удивил такой подход к делу. Через две недели он получил готовую презентацию, логотип и даже новое название компании: NeXT, с единственной буквой е в нижнем регистре.

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

И Джобс согласился — не потому что побоялся спорить, а потому что доверял.

Если бы такой логотип предложил неизвестный дизайнер, Джобс заставил бы его 10 раз перекрасить букву. Но Пол Рэнд мог позволить себе такую уверенность. У него был кредит доверия, который даже неоднозначной идее дает шанс.

📍Когда тебе верят, ты продаешь не логотип, а уверенность в решении.

А как дизайнеру заработать свой кредит доверия расскажу в следующем посте.

Кредит доверия часть 2

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

Как это работает?

1. Предложил простое и красивое решение задачи, которое увеличило продажи/улучшило пользовательский опыт — плюс к доверию.

2. Сделал дизайн, но не смог объяснить идею и убедить команду — доверие падает.

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

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

📍Короч, кредит доверия важен — копи его, чтобы продвигать прорывные решения, и трать с умом. И не уходи в минус, чтобы твои нормальные решения не воспринимали в штыки.

Наконец-то сделали сайт для нашей команды!

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

📌Если ваши знакомые ищут работу, киньте им ссылку — прямо сейчас требуются backend-разработчики.

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

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

Пишите сразу по делу

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

Здравствуйте! Как у вас дела? Простите, что отвлекаю, есть минутка? Хотелось бы задать вам вопрос. Поможете?

Зачем это, если после приветствия можно было сразу перейти к просьбе? Или вот еще в постах любят писать так:

Здравствуйте! Простите, что давно не писал, исправляюсь!

Извиняться стоит только тогда, когда вы обязались что-то делать регулярно — к примеру, раз в две недели писать пост/отчет. Чаще всего, когда звучит такая фраза, обязанности не было.

Я считаю, что длинные вступления перед сутью — полная фигня.

Время — ограниченный ресурс, его всегда мало. И для меня короткое сообщение, написанное четко и по делу — это уважение к человеку, который его читает.

Только я говорю про деловую переписку. Другое дело в жизни: там уместен смолток. Я спрошу как у человека дела, хорошо ли он долетел, как прошла конференция. И не потому что «это надо спросить», а потому что интересно.

В рабочих переписках это выглядит странно. Ну ответят тебе «хорошо», и смолток закончится. Зачем он нужен был-то?

Для приличия достаточно простого «привет» в начале предложения. Только не пишите его отдельным сообщением, когда специально не пишешь вопрос, пока с тобой не поздороваются в ответ 😄

Короч, пишите сразу по делу и экономьте время тем, кто вас читает.

Матрица согласований

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

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

После этого интерфейс превращается в компромисс, пытающийся учесть все и сразу.

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

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

Решение — поделить участников по категориям:

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

Это я назвал матрицей согласований.

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

А еще матрица увеличивает эффективность и ответственность: отвечать за решения будут конкретные люди, а не вся команда по чуть-чуть.

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

P.S. Этот пост — начало серии заметок для начинающих тимлидов. Пишите, какие темы еще разобрать.

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

Если дизайнер вместо текста ставит Lorem ipsum и говорит, что кто-то другой допишет его позже — это рэд флаг 🚩

У нас долгое время не было редактора: все тексты дизайнеры писали вместе с продактом. Возможно, не всегда консистентно: например, где-то кнопка называлась «отменить», а где-то «отмена». Но самое главное — доносили смысл дизайна в том числе через текст.

Относительно недавно у нас появился UX-редактор — теперь наводим порядок в подсказках, кнопках в меню и вообще везде, где есть буквы. Тексты стали короче и информативнее.

Из минусов: работа идет дольше. Нужно погрузить редактора в задачу, объяснить контекст, показать сценарии. Но результат стоит того.

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

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

Не обязательно писать так же круто, как UX редактор — достаточно базовых навыков. Советую прочитать:

— «Пиши, сокращай» Максима Ильяхова;

— «Этой кнопке нужен текст» Кирилла Егерева.

Короч, пишите тексты для интерфейсов: слова важны так же, как и пиксели

Тимлид должен работать руками

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

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

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

Что помогает держать форму?

Следить за трендами, смотреть на конкурентов, обсуждать общие решения на дизайн-синках и, конечно же, работать руками хотя бы 20-30% времени.

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

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

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

Мемы в интерфейсе

Недавно мне выскочило такое окошко. Окак. Вроде и смешно, но больше вопросов.

Мемы в интерфейсе — неоднозначная штука.

В ленте соцсетей они выглядят органично: увидел прикол, улыбнулся, пролистнул и через пару минут забыл.

Но интерфейс — это другое. Тут шутки за пару месяцев устаревают и быстро начинают бесить. Как и этот окак.

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

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

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

И в этот момент мысль была простая: а стоит ли мем того, если из-за него теряется смысл?

Мне кажется, что нет. А вы как думаете — юмор в интерфейсе помогает или всё же чаще мешает?

Записали первый выпуск подкаста про фидбэк

Мы с Ростиславом наконец-то записали первый выпуск подкаста «Кофе с тимлидами». Это пилот — слегка волнительно, немного сыро, но, надеюсь, полезно. Общались без лишней воды и по делу.

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

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

Слушать на Яндекс Музыке

Сначала сильный дизайнер, потом тимлид, не наоборот

Когда я еще был в другой команде, случалось так, что получал советы тимлида и ловил себя на мысли: «Эмм… а почему так поверхностно?».

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

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

Отсюда и последствия:

— Советы для дизайн команды поверхностные;
— Нет насмотренности, трендов, направления;
— Появляется риск микроменеджмента, потому что «так спокойнее»;
— И самое важное — непонимание тех проблем, через которые проходит дизайнер каждый день.

При этом тимлид не из дизайна — абсолютно нормальная история.
У такого руководителя много плюсов:

— Не тонет в текучке, не уходит делать все своими руками;
— Аккуратно выстраивает процессы и работает с людьми;
— Держит фокус на документации, систематизации.

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

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

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

Еще раз про важность демо

В период, когда многие подводят итоги работы, не лишним будет сделать демо вашей команды. Я уже писал ранее про свой опыт и советы.

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

📍На самом деле демо начинается еще до первого экрана. Проговорите вначале:

— о чём будете говорить;
— что покажете;
— и почему это важно.

Но со вступлением лучше не затягивать — посвятить этому 5-10 минут будет достаточно.

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

———

Недавно видел у Гоши Путилова подробный чек-лист о том, как правильно проводить дизайн-демо для клиентов и команды. Он дает советы, как настраивать собеседников на нужную волну, производить правильное впечатление и сглаживать углы, если сыпется критика или работой не довольны. Удобно, что есть примеры фраз.

Всё собрано в один файл, найти его можно в посте у Гоши. Рекомендую глянуть тем, кто презентует свои проекты.

Короч, готовьтесь к демо — это не просто отчёт, а возможность показать, как вы думаете и работаете.

Нами пользуется METRO

Недавно увидел новость, что METRO перешел на сервисы Яндекс 360.

Обычно я пишу здесь про команду, но не могу не поделиться успехами продукта, над которым мы работаем.

Приятно слышать, что на Трекер, Вики и Формы перешёл такой крупный клиент. Да еще и магазин, в котором я периодически бываю.

Подробнее в посте.