Яндекс здоровье продали
Недавно увидел новость о том, что еще в прошлом году Яндекс.Здоровье продали. Я афигел, если честно)
В свое время я около полугода проработал в команде Яндекс.Здоровья — это был мой первый серьезный опыт в мобильных приложениях.
Помню, как мы делали версию для супераппа Яндекс.Браузера. И там было куча ограничений: начиная от внешнего вида компонентов, и заканчивая связью с сервером.
Не могу сказать, что опыт исключительно положительный, но он первый — именно с него многое и закрутилось. И такое, конечно, не забывается.
Недавно увидел новость о том, что еще в прошлом году Яндекс.Здоровье продали. Я афигел, если честно)
В свое время я около полугода проработал в команде Яндекс.Здоровья — это был мой первый серьезный опыт в мобильных приложениях.
Помню, как мы делали версию для супераппа Яндекс.Браузера. И там было куча ограничений: начиная от внешнего вида компонентов, и заканчивая связью с сервером.
Не могу сказать, что опыт исключительно положительный, но он первый — именно с него многое и закрутилось. И такое, конечно, не забывается.
👍4❤2
Разбираемся, а не спорим
Я редко спорю — стараюсь договариваться и искать компромиссы. Но несколько лет назад так сделать не получилось.
Разработчик предложил решение, которое шло вразрез с базовыми принципами UX: он предложил модальное окно не закрывать по клику снаружи.
Я был против. Для пользователя такое решение будет странным и непривычным: везде оно закрывается, а у нас нет. Поэтому прямо сказал «нет» и пошел на конфликт.
Мои аргументы не работали, а разработчик запрашивал исследование — хотя для меня очевидно, что оно не нужно.
Тогда подключили к обсуждению моего руководителя. Он пришел с холодной головой, без эмоций, и начал не с аргументов, а с намерения «давайте разберемся». Копал вглубь, чтобы найти настоящую потребность разработчика.
Оказалось, он боится потери введенных данных. Пользователи могли долго заполнять форму и случайно кликнуть мимо — все бы исчезло. Опасения оправданы.
В итоге мы нашли великолепное решение: модальное окно закрывается, как положено, но данные сохраняются внутри. Были нюансы, были и мои эмоции, но главное, что удалось вовремя выйти из режима спора.
📌Самое интересное не в решении, а в подходе: не «давай спорить», а «давай разберемся». Не надо занимать какую-то позицию, прежде чем ты не понял собеседника полностью — это крутой подход, и его надо почувствовать.
Идеального финала никто не обещает. Но пассивная агрессия, молчаливое несогласие и уход в спор — точно не то, что помогает сделать нормальный продукт. От этого лучше избавляться.
Я редко спорю — стараюсь договариваться и искать компромиссы. Но несколько лет назад так сделать не получилось.
Разработчик предложил решение, которое шло вразрез с базовыми принципами UX: он предложил модальное окно не закрывать по клику снаружи.
Я был против. Для пользователя такое решение будет странным и непривычным: везде оно закрывается, а у нас нет. Поэтому прямо сказал «нет» и пошел на конфликт.
Мои аргументы не работали, а разработчик запрашивал исследование — хотя для меня очевидно, что оно не нужно.
Тогда подключили к обсуждению моего руководителя. Он пришел с холодной головой, без эмоций, и начал не с аргументов, а с намерения «давайте разберемся». Копал вглубь, чтобы найти настоящую потребность разработчика.
Оказалось, он боится потери введенных данных. Пользователи могли долго заполнять форму и случайно кликнуть мимо — все бы исчезло. Опасения оправданы.
В итоге мы нашли великолепное решение: модальное окно закрывается, как положено, но данные сохраняются внутри. Были нюансы, были и мои эмоции, но главное, что удалось вовремя выйти из режима спора.
📌Самое интересное не в решении, а в подходе: не «давай спорить», а «давай разберемся». Не надо занимать какую-то позицию, прежде чем ты не понял собеседника полностью — это крутой подход, и его надо почувствовать.
Идеального финала никто не обещает. Но пассивная агрессия, молчаливое несогласие и уход в спор — точно не то, что помогает сделать нормальный продукт. От этого лучше избавляться.
👍11
Ситуация, в которой я понял: молчать не стоило
Когда я был фрилансером, мы с другом делали сайт под ключ для мебельной сети: дизайн, разработка, тексты для описания, фото кухонь, контекстная реклама. Работы прилично, а договор нестандартный: сайт делаем бесплатно, а потом получаем % с продаж.
Общались все время через главу маркетинга, но перед самым запуском посмотреть на финальные макеты заглянул руководитель. Это было как в фильме — заходит босс, встает за спинами и одной фразой прерывает обсуждение:
— Здесь запятую забыли поставить.
— О, да, спасибо, что отметили.
— Какие ж вы профессионалы, если за вами надо перепроверять?
Мы отшутились, сказали, что тексты еще перепроверим. А он, все еще как в кино, молча ушел по своим делам.
Спустя годы я понимаю, что это была одна из ошибок, которые мы тогда сделали. Нас не восприняли всерьез, а мы отшутились — будто согласились с тем, что «так себе специалисты». Но нарекать всю работу непрофессиональной из-за запятой — это тоже ошибка.
📍Сейчас я стал бы не отшучиваться, а обозначил границы.
Например: «Если из-за пропущенной запятой вы не доверяете нам как специалистам, давайте обсудим, стоит ли продолжать работу». И собеседник может ответить: «Не доверяю, и давай, до свидания» — к этому надо быть готовым.
В нашем случае, доверие должно было быть обязательно: сайт делался за наш счет — мы, по сути, просто вкладывались в чужой бизнес.
В итоге мы расстались через три месяца, не заработав НИЧЕГО. Мы видели, что через сайт были звонки, но клиент говорил, что до продаж не доходило. Не знаю, правда или нет: цикл сделки у мебели длинный.
Если бы мы отреагировали на подкол, может, с нами бы и попрощались, но мы хотя бы время сэкономили. А может и восстановили бы доверие руководителя, потому что уважали себя и ценили свою работу — но это уже сюжет из кино.
А вы часто отшучиваетесь, вместо того, чтобы выяснить отношения?
P.S. Еще можно найти очень остроумный ответ, который разом решит конфликт. Но я так не умею 🙃
Когда я был фрилансером, мы с другом делали сайт под ключ для мебельной сети: дизайн, разработка, тексты для описания, фото кухонь, контекстная реклама. Работы прилично, а договор нестандартный: сайт делаем бесплатно, а потом получаем % с продаж.
Общались все время через главу маркетинга, но перед самым запуском посмотреть на финальные макеты заглянул руководитель. Это было как в фильме — заходит босс, встает за спинами и одной фразой прерывает обсуждение:
— Здесь запятую забыли поставить.
— О, да, спасибо, что отметили.
— Какие ж вы профессионалы, если за вами надо перепроверять?
Мы отшутились, сказали, что тексты еще перепроверим. А он, все еще как в кино, молча ушел по своим делам.
Спустя годы я понимаю, что это была одна из ошибок, которые мы тогда сделали. Нас не восприняли всерьез, а мы отшутились — будто согласились с тем, что «так себе специалисты». Но нарекать всю работу непрофессиональной из-за запятой — это тоже ошибка.
📍Сейчас я стал бы не отшучиваться, а обозначил границы.
Например: «Если из-за пропущенной запятой вы не доверяете нам как специалистам, давайте обсудим, стоит ли продолжать работу». И собеседник может ответить: «Не доверяю, и давай, до свидания» — к этому надо быть готовым.
В нашем случае, доверие должно было быть обязательно: сайт делался за наш счет — мы, по сути, просто вкладывались в чужой бизнес.
В итоге мы расстались через три месяца, не заработав НИЧЕГО. Мы видели, что через сайт были звонки, но клиент говорил, что до продаж не доходило. Не знаю, правда или нет: цикл сделки у мебели длинный.
Если бы мы отреагировали на подкол, может, с нами бы и попрощались, но мы хотя бы время сэкономили. А может и восстановили бы доверие руководителя, потому что уважали себя и ценили свою работу — но это уже сюжет из кино.
А вы часто отшучиваетесь, вместо того, чтобы выяснить отношения?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤6
Учитывайте опыт популярных конкурентов
Раньше я пользовался стандартным приложением на часах, чтобы считать шаги и фиксировать пробежки.
Нажал «закончить тренировку», и все данные сохранились. Никаких лишних действий.
А потом попробовал приложение Strava. Там после клика на «Finish» появляется экран со статистикой и крестик в углу.
Я на автомате закрывал окно, как и раньше, и снова видел кнопку «Finish». Подумал, что глюк. Переустановил — история повторилась.
И только со второй попытки понял, что экран с данными за тренировку надо было прокрутить вниз — там кнопка «Save».
Вот так привычки из одного приложения формируют поведение в другом.
Я ожидал, что все данные сохранятся сами, но интерфейс требовал еще одно подтверждение. Я до него не догадался.
📌Если вы делаете продукт — особенно в сфере, где уже есть устоявшиеся паттерны — не нужно изобретать велосипед. Лучше повторить то, что работает и к чему люди привыкли.
Ну или хотя бы дать пользователю подсказку, чтобы он не удалил ваше приложение сразу после первой тренировки.
Раньше я пользовался стандартным приложением на часах, чтобы считать шаги и фиксировать пробежки.
Нажал «закончить тренировку», и все данные сохранились. Никаких лишних действий.
А потом попробовал приложение Strava. Там после клика на «Finish» появляется экран со статистикой и крестик в углу.
Я на автомате закрывал окно, как и раньше, и снова видел кнопку «Finish». Подумал, что глюк. Переустановил — история повторилась.
И только со второй попытки понял, что экран с данными за тренировку надо было прокрутить вниз — там кнопка «Save».
Вот так привычки из одного приложения формируют поведение в другом.
Я ожидал, что все данные сохранятся сами, но интерфейс требовал еще одно подтверждение. Я до него не догадался.
📌Если вы делаете продукт — особенно в сфере, где уже есть устоявшиеся паттерны — не нужно изобретать велосипед. Лучше повторить то, что работает и к чему люди привыкли.
Ну или хотя бы дать пользователю подсказку, чтобы он не удалил ваше приложение сразу после первой тренировки.
👍7
Дизайн-долг: мелочи, которые редко чинят.
По мере развития продукта начинают копиться интерфейстные проблемы, о которых никто заранее не думал.
Например, добавляли фичу по одной, и интерфейс стал перегруженным. Разработчик отложил мелкую правку на потом и все забыли. На юзабилити-тесте увидели проблему, но исправить ее руки не дошли. Сюда же задачи, созданные на основе фидбэка от пользователей.
📍Все это — дизайн-долг. И чем дольше живет продукт, тем больше подобных задач появляется.
Просто копить задачи в одном списке — мало. Поэтому мы действуем по шагам:
0. Договариваемся, что будем делать дизайн долг
Пока не согласовали с командой, что задачи по дизайн-долгу будут попадать в спринт, смысла в остальном нет.
Поэтому нужно убедить разработчиков и руководителей, что эти проблемы влияют на деньги, пользовательский опыт и рупутацию продукта. На этом этапе согласуйте сколько задач вы будете брать в работу и как часто.
1. Собираем дизайн-долг
Весь потенциальный дизайн-долг надо фиксировать в тикеты — куда угодно, где у вас ставятся задачи. Главное, чтобы было легко найти: например, в Трекере, мы это делаем по тегу.
2. Приоритизируем задачи
Когда в списке десятки задач и, на первый взгляд, все важные, тяжело выделить что-то одно.
На этом этапе помогает приоритизация. Тема отдельного поста, если интересно про такое почитать — поставьте реакций. Кратко: придумал свою формулу по приоритизации задач.
3. Делаем задачи командой дизайна.
Тут, я думаю, все понятно.
4. Передаем в разработку
Последним пунктом важно регулярно передавать задачи из дизайн долга на реализацию в команду разработки, проводить дизайн-ревью.
Дизайн-долг не убрать разом — он будет всегда. Главное постепенно начать с ним работать, чтобы он не копился и стал частью процесса по улучшению продукта.
По мере развития продукта начинают копиться интерфейстные проблемы, о которых никто заранее не думал.
Например, добавляли фичу по одной, и интерфейс стал перегруженным. Разработчик отложил мелкую правку на потом и все забыли. На юзабилити-тесте увидели проблему, но исправить ее руки не дошли. Сюда же задачи, созданные на основе фидбэка от пользователей.
📍Все это — дизайн-долг. И чем дольше живет продукт, тем больше подобных задач появляется.
Просто копить задачи в одном списке — мало. Поэтому мы действуем по шагам:
0. Договариваемся, что будем делать дизайн долг
Пока не согласовали с командой, что задачи по дизайн-долгу будут попадать в спринт, смысла в остальном нет.
Поэтому нужно убедить разработчиков и руководителей, что эти проблемы влияют на деньги, пользовательский опыт и рупутацию продукта. На этом этапе согласуйте сколько задач вы будете брать в работу и как часто.
1. Собираем дизайн-долг
Весь потенциальный дизайн-долг надо фиксировать в тикеты — куда угодно, где у вас ставятся задачи. Главное, чтобы было легко найти: например, в Трекере, мы это делаем по тегу.
2. Приоритизируем задачи
Когда в списке десятки задач и, на первый взгляд, все важные, тяжело выделить что-то одно.
На этом этапе помогает приоритизация. Тема отдельного поста, если интересно про такое почитать — поставьте реакций. Кратко: придумал свою формулу по приоритизации задач.
3. Делаем задачи командой дизайна.
Тут, я думаю, все понятно.
4. Передаем в разработку
Последним пунктом важно регулярно передавать задачи из дизайн долга на реализацию в команду разработки, проводить дизайн-ревью.
Дизайн-долг не убрать разом — он будет всегда. Главное постепенно начать с ним работать, чтобы он не копился и стал частью процесса по улучшению продукта.
❤6🔥3
Приоритизация дизайн долга
Когда задач в дизайн-долге много, выбирать становится сложно. Конечно, брать задачи можно и наугад — интуитивно решая, что сейчас важнее. Но я советую разработать структуру: так процесс выбора становится проще и прозрачнее.
Хороший способ — оценивать задачи по метрикам. Например, на что они влияют:
— Деньги (конверсии);
— Качество (удобство использования);
— Отношение (восприятие пользователями бренда).
Также полезно оценивать то, какой процент пользователей затрагивает каждая бага и насколько сложно его реализовать.
Еще помогает логика сценариев. Долг можно разделить по платформам (веб/моб) и по зонам интерфейса. Например, если баг в сценарии покупки, то это напрямую влияет на бизнес. А задача по включению темной темы может немного подождать.
Во внутненних продуктах часто не считают деньги, поэтому, когда у меня были таковые, я придумал свою формулу для приоритезации задач. Может и вам подойдет:
1️⃣ Процент пользователей — примерно оцениваю то, сколько пользователей работают с этой страницей. Например, в админке я бы поставил 15%, а на основной странице — 100%.
2️⃣ Количество жалоб: сколько раз на это указывали (число).
3️⃣ Критичность проблемы: (оценка)
5 — вызывает разрушающие последствия — например, потерю пользовательских данных.
4 — неинтуитивное поведение, пользователь постоянно совершает ошибки.
3 — кажется «странным», непонятным. Приходится вчитываться, чтобы разобраться.
2 — визуально некрасиво, но работает приемлемо.
1 — что-то незначительное.
4️⃣ Доп фактор:
5 — принесли руководители. 😁
3 — чувствительные данные, ломает бизнес процесс какой то команде.
1 — ничего из перечисленного.
Примеры:
1 * 1 * 1 * 1 ✖️ 10 = 10 — может подождать
0.5 * 4 * 3 * 1 ✖️ 10 = 60 — стоит брать в работу
Оценивать задачи лучше сразу, а пересматривать скоуп задач раз в три или шесть месяцев — в зависимости от того, на какой период планируете.
Когда задач в дизайн-долге много, выбирать становится сложно. Конечно, брать задачи можно и наугад — интуитивно решая, что сейчас важнее. Но я советую разработать структуру: так процесс выбора становится проще и прозрачнее.
Хороший способ — оценивать задачи по метрикам. Например, на что они влияют:
— Деньги (конверсии);
— Качество (удобство использования);
— Отношение (восприятие пользователями бренда).
Также полезно оценивать то, какой процент пользователей затрагивает каждая бага и насколько сложно его реализовать.
Еще помогает логика сценариев. Долг можно разделить по платформам (веб/моб) и по зонам интерфейса. Например, если баг в сценарии покупки, то это напрямую влияет на бизнес. А задача по включению темной темы может немного подождать.
Во внутненних продуктах часто не считают деньги, поэтому, когда у меня были таковые, я придумал свою формулу для приоритезации задач. Может и вам подойдет:
Процент пользователей ✖️ количество жалоб ✖️ критичность проблемы ✖️ доп. фактор ✖️ 10
5 — вызывает разрушающие последствия — например, потерю пользовательских данных.
4 — неинтуитивное поведение, пользователь постоянно совершает ошибки.
3 — кажется «странным», непонятным. Приходится вчитываться, чтобы разобраться.
2 — визуально некрасиво, но работает приемлемо.
1 — что-то незначительное.
5 — принесли руководители. 😁
3 — чувствительные данные, ломает бизнес процесс какой то команде.
1 — ничего из перечисленного.
Примеры:
1 * 1 * 1 * 1 ✖️ 10 = 10 — может подождать
0.5 * 4 * 3 * 1 ✖️ 10 = 60 — стоит брать в работу
Оценивать задачи лучше сразу, а пересматривать скоуп задач раз в три или шесть месяцев — в зависимости от того, на какой период планируете.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2
Руководство — это навык, а не врожденный дар
Чтобы стать тимлидом, сначала надо стать сильным специалистом.
И так везде: сначала учишься писать код/проектировать интерфейсы, узнаешь все тонкости работы, и только потом становишься руководителем.
Но такая последовательность действий не обязательна и даже иногда не работает. Был случай: опытного разработчика назначили тимлидом. Через полгода он попросился обратно — хотел писать код, а не работать с людьми. Оказывается, быть профессионалом своего дела — мало.
Это нормально: далеко не все хотят становиться руководителями. Кто-то сразу понимает: «не мое». А кому-то надо попробовать, чтобы понять.
А знаете поговорку: "Лидерами рождаются, а не становятся"? Я не согласен с теми, кто считает, что лидерство — это врожденное, и если «не дано», то лезть не надо.
📍Я считаю, что лидерство можно развить, как и любой навык.
Конечно, у кого-то с детства есть предрасположенности к этому. Например, если во дворе ты организовывал ребят поиграть в футбол, управлять командой будет проще, потому что этот навык ты уже развивал. Так же было и у меня, когда я до тимлидства руководил своим бизнесом, нанимал и увольнял продавцов, экспедиторов.
Но если подобного опыта нет, шансов стать лидером не меньше. Главное — это желание развиваться в этой сфере.
Если есть сомнения, то стоит попробовать. Через практику легче понять, подходит или нет.
А если уже решил, что хочешь расти в эту сторону, то начни с малого: организуй тимбилдинг для команды или устрой сбор денег на подарок. Ну или сразу по жести — попробуй собрать друзей 30+ лет в один день в одном месте. Справишься — считай, почти руководитель🙃
Чтобы стать тимлидом, сначала надо стать сильным специалистом.
И так везде: сначала учишься писать код/проектировать интерфейсы, узнаешь все тонкости работы, и только потом становишься руководителем.
Но такая последовательность действий не обязательна и даже иногда не работает. Был случай: опытного разработчика назначили тимлидом. Через полгода он попросился обратно — хотел писать код, а не работать с людьми. Оказывается, быть профессионалом своего дела — мало.
Это нормально: далеко не все хотят становиться руководителями. Кто-то сразу понимает: «не мое». А кому-то надо попробовать, чтобы понять.
А знаете поговорку: "Лидерами рождаются, а не становятся"? Я не согласен с теми, кто считает, что лидерство — это врожденное, и если «не дано», то лезть не надо.
📍Я считаю, что лидерство можно развить, как и любой навык.
Конечно, у кого-то с детства есть предрасположенности к этому. Например, если во дворе ты организовывал ребят поиграть в футбол, управлять командой будет проще, потому что этот навык ты уже развивал. Так же было и у меня, когда я до тимлидства руководил своим бизнесом, нанимал и увольнял продавцов, экспедиторов.
Но если подобного опыта нет, шансов стать лидером не меньше. Главное — это желание развиваться в этой сфере.
Если есть сомнения, то стоит попробовать. Через практику легче понять, подходит или нет.
А если уже решил, что хочешь расти в эту сторону, то начни с малого: организуй тимбилдинг для команды или устрой сбор денег на подарок. Ну или сразу по жести — попробуй собрать друзей 30+ лет в один день в одном месте. Справишься — считай, почти руководитель
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2
Лекция про дизайн-систему
Когда был на Дизайн Выходных в Казани, пробегал мимо лекции про дизайн-систему (ДС) от Сергея Мухина. Нашел запись — делюсь с вами и рекомендую к просмотру. Особенно полезно для тех, кто начинает разбираться в этой теме.
Сергей говорит, что ДС влияет на мышление дизайнеров, и делится своим опытом ее создания. Я бы выразился иначе: ДС создает «правила игры» в дизайне продукта и экосистемы в целом.
Из интересного:
— Удачные примеры подхода к неймингу токенов, разделения на группы переменных. Я думал, что про семантические переменные давно всем понятно и очевидно, но видел, как ребята фоткали слайды.
— Мысль о том, что M-size должен быть размером по умолчанию, рекомендуемым для использования.
— Техническая палитра цветов лежит отдельно и скрыта от дизайнеров. Она нужна только команде ДС.
— Прикольное понятие «рецепт» — сложный компонент, собранный на слотах.
В целом лекция понятная, на 1,5х можно пробежаться.
Когда был на Дизайн Выходных в Казани, пробегал мимо лекции про дизайн-систему (ДС) от Сергея Мухина. Нашел запись — делюсь с вами и рекомендую к просмотру. Особенно полезно для тех, кто начинает разбираться в этой теме.
Сергей говорит, что ДС влияет на мышление дизайнеров, и делится своим опытом ее создания. Я бы выразился иначе: ДС создает «правила игры» в дизайне продукта и экосистемы в целом.
Из интересного:
— Удачные примеры подхода к неймингу токенов, разделения на группы переменных. Я думал, что про семантические переменные давно всем понятно и очевидно, но видел, как ребята фоткали слайды.
— Мысль о том, что M-size должен быть размером по умолчанию, рекомендуемым для использования.
— Техническая палитра цветов лежит отдельно и скрыта от дизайнеров. Она нужна только команде ДС.
— Прикольное понятие «рецепт» — сложный компонент, собранный на слотах.
В целом лекция понятная, на 1,5х можно пробежаться.
VK Видео
Сергей Мухин - Дизайн-система как инструмент формирования мышления дизайнера, Дизайн-выходные, 2025
МОЖНО СМОТРЕТЬ НА YOUTUBE! https://youtu.be/EvOunGvDB4c Сергей Мухин Дизайн-директор, архитектор дизайн-систем, автор проекта UXFLOW (Волгоград) Дизайн-система как инструмент формирования мышления продуктового дизайнера. Философия и подходы, с помощью которых…
❤4👍2
Тимбилдинг в Калининграде
В августе наконец-то встретились всей распределенной командой вживую — на тимбилдинге. Из разных городов прилетели в Калининград.
Круто, что мы не просто ели и пили, а занимались делом. Продакты подготовили реальные задачи, а команды по 7 человек искали решения. Каждый включился и принял участие в общем деле — это сплотило сильнее любого тоста.
Было шумно: много спорили, перебивали друг друга, потому что у каждого есть свои идеи и всем хотелось ими поделиться. Людям небезразличен продукт, их глаза горят — это и делает команду сильной.
Хорошо провели время — такие встречи мотивируют с новыми силами двигать продукт вперед.
В августе наконец-то встретились всей распределенной командой вживую — на тимбилдинге. Из разных городов прилетели в Калининград.
Круто, что мы не просто ели и пили, а занимались делом. Продакты подготовили реальные задачи, а команды по 7 человек искали решения. Каждый включился и принял участие в общем деле — это сплотило сильнее любого тоста.
Было шумно: много спорили, перебивали друг друга, потому что у каждого есть свои идеи и всем хотелось ими поделиться. Людям небезразличен продукт, их глаза горят — это и делает команду сильной.
Хорошо провели время — такие встречи мотивируют с новыми силами двигать продукт вперед.
❤8👍4
Не портите презентацию оправданиями
Часто на дизайн-синках слышу фразы: «Ребята, это черновик, особо не смотрите» или «Я не успел проработать, было много встреч. Да и задачу плохо поставили».
Мне кажется, что этого можно не говорить. Почему?
В начале встречи внимание к спикеру максимальное. Но когда он сам говорит о том, что это «сырая» работа, желание что-либо смотреть пропадает.
Я понимаю, почему люди так говорят: фраза как бы заранее снимает ответственность, даёт пространство для ошибки. Но на деле — отбивает желание обсуждать работу и вникать.
Не надо говорить, что работа пока «черновик» — это и так понятно, мы же и собрались, чтобы ее обсудить.
Чем заменить?
Если очень хочется в начале обозначить, что это не финал, можно сказать: «Сейчас покажу вам три варианта решения и хочу, чтобы вы подсказали, что я мог забыть».
А лучше уже в процессе сказать: «Сценарий обработки заявки я еще не доработал, не него не смотрите». Или заранее сделать что-то вроде заглушки «тут будет такой-то сценарий».
Короч, показывайте черновик и не начинайте встречу с самоуничижения.
Часто на дизайн-синках слышу фразы: «Ребята, это черновик, особо не смотрите» или «Я не успел проработать, было много встреч. Да и задачу плохо поставили».
Мне кажется, что этого можно не говорить. Почему?
В начале встречи внимание к спикеру максимальное. Но когда он сам говорит о том, что это «сырая» работа, желание что-либо смотреть пропадает.
Я понимаю, почему люди так говорят: фраза как бы заранее снимает ответственность, даёт пространство для ошибки. Но на деле — отбивает желание обсуждать работу и вникать.
Не надо говорить, что работа пока «черновик» — это и так понятно, мы же и собрались, чтобы ее обсудить.
Чем заменить?
Если очень хочется в начале обозначить, что это не финал, можно сказать: «Сейчас покажу вам три варианта решения и хочу, чтобы вы подсказали, что я мог забыть».
А лучше уже в процессе сказать: «Сценарий обработки заявки я еще не доработал, не него не смотрите». Или заранее сделать что-то вроде заглушки «тут будет такой-то сценарий».
Короч, показывайте черновик и не начинайте встречу с самоуничижения.
3❤4👍3
Приложение Яндекс Трекер
Примерно четыре года развиваю Яндекс Трекер, но про мобильное приложение совсем не писал.
Почему? Потому что раньше на развитие было мало ресурсов, и делали на «энтузиазме».
В этом году взялись за него всерьёз. Сделали исследование, выяснили самые необходимые сценарии и начали дорабатывать продукт.
Большую часть приложения спроектировал ведущий дизайнер из команды, я тоже чуть приложил руку — сделал сценарии для учёта времени и напоминаний (про них, возможно, отдельно расскажу).
Отдельное спасибо команде разработки: они затащили огромную часть работы.
Сейчас приложение ощущается совсем по-другому: появились новые разделы, доски, удобное создание тикетов, переходы в сервисы, уведомления. Сам кайфую от того, насколько мне стало удобнее просматривать задачи на ходу.
А ещё рад, что рейтинг приложения меняется: он раньше был ожидаемо низкий, а сейчас честно становится лучше. Горжусь тем, как сильно мы выросли!
🙏 Если вы пользуетесь приложением, поставьте оценку или напишите отзыв в App Store / Google Play. Это помогает нам расти и мы читаем все комментарии.
Примерно четыре года развиваю Яндекс Трекер, но про мобильное приложение совсем не писал.
Почему? Потому что раньше на развитие было мало ресурсов, и делали на «энтузиазме».
В этом году взялись за него всерьёз. Сделали исследование, выяснили самые необходимые сценарии и начали дорабатывать продукт.
Большую часть приложения спроектировал ведущий дизайнер из команды, я тоже чуть приложил руку — сделал сценарии для учёта времени и напоминаний (про них, возможно, отдельно расскажу).
Отдельное спасибо команде разработки: они затащили огромную часть работы.
Сейчас приложение ощущается совсем по-другому: появились новые разделы, доски, удобное создание тикетов, переходы в сервисы, уведомления. Сам кайфую от того, насколько мне стало удобнее просматривать задачи на ходу.
А ещё рад, что рейтинг приложения меняется: он раньше был ожидаемо низкий, а сейчас честно становится лучше. Горжусь тем, как сильно мы выросли!
🙏 Если вы пользуетесь приложением, поставьте оценку или напишите отзыв в App Store / Google Play. Это помогает нам расти и мы читаем все комментарии.
1🔥5❤4👍2
Кредит доверия: часть 1
Кто-то делает 10 вариантов логотипа, чтобы угодить клиенту. А кто-то один, да еще и за 100.000 долларов. Дело не только в скиле, но и в кредите доверия, когда заочно верят твоему решению.
Я прочитал эту историю в книге-биографии Стива Джобса: он обращался к Полу Рэнду, известному как гуру корпоративного дизайна, за логотипом для новой компании Next.
Когда Джобс попросил создать несколько вариантов, Рэнд ответил:
Джобс согласился: его удивил такой подход к делу. Через две недели он получил готовую презентацию, логотип и даже новое название компании: NeXT, с единственной буквой е в нижнем регистре.
Джобс попробовал изменить цвет этой буквы, но получил простой ответ: «Я занимаюсь этим уже пятьдесят лет и знаю, что делаю!».
И Джобс согласился — не потому что побоялся спорить, а потому что доверял.
Если бы такой логотип предложил неизвестный дизайнер, Джобс заставил бы его 10 раз перекрасить букву. Но Пол Рэнд мог позволить себе такую уверенность. У него был кредит доверия, который даже неоднозначной идее дает шанс.
📍Когда тебе верят, ты продаешь не логотип, а уверенность в решении.
А как дизайнеру заработать свой кредит доверия расскажу в следующем посте.
Кто-то делает 10 вариантов логотипа, чтобы угодить клиенту. А кто-то один, да еще и за 100.000 долларов. Дело не только в скиле, но и в кредите доверия, когда заочно верят твоему решению.
Я прочитал эту историю в книге-биографии Стива Джобса: он обращался к Полу Рэнду, известному как гуру корпоративного дизайна, за логотипом для новой компании Next.
Когда Джобс попросил создать несколько вариантов, Рэнд ответил:
Я решу вам проблему, и вы мне за это заплатите. Вы можете воспользоваться тем, что я создам, а можете и не воспользоваться. Но никаких вариантов я не предлагаю.
Джобс согласился: его удивил такой подход к делу. Через две недели он получил готовую презентацию, логотип и даже новое название компании: NeXT, с единственной буквой е в нижнем регистре.
Джобс попробовал изменить цвет этой буквы, но получил простой ответ: «Я занимаюсь этим уже пятьдесят лет и знаю, что делаю!».
И Джобс согласился — не потому что побоялся спорить, а потому что доверял.
Если бы такой логотип предложил неизвестный дизайнер, Джобс заставил бы его 10 раз перекрасить букву. Но Пол Рэнд мог позволить себе такую уверенность. У него был кредит доверия, который даже неоднозначной идее дает шанс.
📍Когда тебе верят, ты продаешь не логотип, а уверенность в решении.
А как дизайнеру заработать свой кредит доверия расскажу в следующем посте.
4👍4❤2🔥1
Кредит доверия часть 2
Когда неизвестный дизайнер приходит в новую команду, его кредит доверия на старте либо нулевой, либо построен на ожиданиях и первом впечатлении. Дальше этот кредит нужно зарабатывать.
Как это работает?
1. Предложил простое и красивое решение задачи, которое увеличило продажи/улучшило пользовательский опыт — плюс к доверию.
2. Сделал дизайн, но не смог объяснить идею и убедить команду — доверие падает.
Чем выше кредит доверия, тем более необычные и прорывные идеи удастся продвигать и реализовывать. И наоборот: если доверия нет, даже хорошее решение могут воспринять в штыки. Увы, в некоторых случаях, остается только «обнулиться»: сменить команду или компанию.
А еще кредит доверия можно тратить, почти как в магазине. Например, ты можешь запросить дополнительную статистику, договориться провести исследования, потестить в А/Б тестах «необычный» вариант, сделать анимацию и прочее.
📍Короч, кредит доверия важен — копи его, чтобы продвигать прорывные решения, и трать с умом. И не уходи в минус, чтобы твои нормальные решения не воспринимали в штыки.
Когда неизвестный дизайнер приходит в новую команду, его кредит доверия на старте либо нулевой, либо построен на ожиданиях и первом впечатлении. Дальше этот кредит нужно зарабатывать.
Как это работает?
1. Предложил простое и красивое решение задачи, которое увеличило продажи/улучшило пользовательский опыт — плюс к доверию.
2. Сделал дизайн, но не смог объяснить идею и убедить команду — доверие падает.
Чем выше кредит доверия, тем более необычные и прорывные идеи удастся продвигать и реализовывать. И наоборот: если доверия нет, даже хорошее решение могут воспринять в штыки. Увы, в некоторых случаях, остается только «обнулиться»: сменить команду или компанию.
А еще кредит доверия можно тратить, почти как в магазине. Например, ты можешь запросить дополнительную статистику, договориться провести исследования, потестить в А/Б тестах «необычный» вариант, сделать анимацию и прочее.
📍Короч, кредит доверия важен — копи его, чтобы продвигать прорывные решения, и трать с умом. И не уходи в минус, чтобы твои нормальные решения не воспринимали в штыки.
5👍8
Наконец-то сделали сайт для нашей команды!
На сайте немного информации о нашей крутецкой команде, наших принципах и талантливых ребятах, которых мы продолжаем искать себе в команду.
📌Если ваши знакомые ищут работу, киньте им ссылку — прямо сейчас требуются backend-разработчики.
С фото получилась забавная история. Изначально хотели вставить мою старую фотку из открытых источников, но когда ее разместили на сайте, я выглядел слишком угрожающе 😬
Пришлось в последний момент просить моего руководителя взять фотоаппарат и устроить экспресс-фотосессию прям на улице возле офиса. Получилось хорошо, особенно если сравнивать с тем, что было. Дневной свет все-таки решает.
На сайте немного информации о нашей крутецкой команде, наших принципах и талантливых ребятах, которых мы продолжаем искать себе в команду.
📌Если ваши знакомые ищут работу, киньте им ссылку — прямо сейчас требуются backend-разработчики.
С фото получилась забавная история. Изначально хотели вставить мою старую фотку из открытых источников, но когда ее разместили на сайте, я выглядел слишком угрожающе 😬
Пришлось в последний момент просить моего руководителя взять фотоаппарат и устроить экспресс-фотосессию прям на улице возле офиса. Получилось хорошо, особенно если сравнивать с тем, что было. Дневной свет все-таки решает.
👍8❤1
Пишите сразу по делу
Не люблю, когда в рабочих переписках пишут по два абзаца вступлений перед сутью:
Зачем это, если после приветствия можно было сразу перейти к просьбе? Или вот еще в постах любят писать так:
Извиняться стоит только тогда, когда вы обязались что-то делать регулярно — к примеру, раз в две недели писать пост/отчет. Чаще всего, когда звучит такая фраза, обязанности не было.
Я считаю, что длинные вступления перед сутью — полная фигня.
Время — ограниченный ресурс, его всегда мало. И для меня короткое сообщение, написанное четко и по делу — это уважение к человеку, который его читает.
Только я говорю про деловую переписку. Другое дело в жизни: там уместен смолток. Я спрошу как у человека дела, хорошо ли он долетел, как прошла конференция. И не потому что «это надо спросить», а потому что интересно.
В рабочих переписках это выглядит странно. Ну ответят тебе «хорошо», и смолток закончится. Зачем он нужен был-то?
Для приличия достаточно простого «привет» в начале предложения. Только не пишите его отдельным сообщением, когда специально не пишешь вопрос, пока с тобой не поздороваются в ответ 😄
Короч, пишите сразу по делу и экономьте время тем, кто вас читает.
Не люблю, когда в рабочих переписках пишут по два абзаца вступлений перед сутью:
Здравствуйте! Как у вас дела? Простите, что отвлекаю, есть минутка? Хотелось бы задать вам вопрос. Поможете?
Зачем это, если после приветствия можно было сразу перейти к просьбе? Или вот еще в постах любят писать так:
Здравствуйте! Простите, что давно не писал, исправляюсь!
Извиняться стоит только тогда, когда вы обязались что-то делать регулярно — к примеру, раз в две недели писать пост/отчет. Чаще всего, когда звучит такая фраза, обязанности не было.
Я считаю, что длинные вступления перед сутью — полная фигня.
Время — ограниченный ресурс, его всегда мало. И для меня короткое сообщение, написанное четко и по делу — это уважение к человеку, который его читает.
Только я говорю про деловую переписку. Другое дело в жизни: там уместен смолток. Я спрошу как у человека дела, хорошо ли он долетел, как прошла конференция. И не потому что «это надо спросить», а потому что интересно.
В рабочих переписках это выглядит странно. Ну ответят тебе «хорошо», и смолток закончится. Зачем он нужен был-то?
Для приличия достаточно простого «привет» в начале предложения. Только не пишите его отдельным сообщением, когда специально не пишешь вопрос, пока с тобой не поздороваются в ответ 😄
Короч, пишите сразу по делу и экономьте время тем, кто вас читает.
👍9🔥2❤1
Матрица согласований
У дизайнера найдется десяток людей, которые «пытаются помочь» ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид.
Типовая ситуация: дизайнер приносит макет, вокруг собираются разработчики, менеджеры, подруга жены босса и каждый начинает «накидывать». Дизайнер погружает новых людей в задачу и доказывает, что сценарий решается интерфейсом. Бонусом идут редкие сценарии, которые «нужно обязательно учесть».
После этого интерфейс превращается в компромисс, пытающийся учесть все и сразу.
Оговорюсь — я не против фидбека от команды, но он должен быть в формате рекомендаций, а финальное решение остается за дизайнером.
У меня были такие же общие синки: куча мнений и бесконечные согласования. По ощущениям, такие встречи затягивали процесс. Нашел для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть.
Решение — поделить участников по категориям:
— кто реально принимает решения,
— кого просто держим в курсе,
— кого стоит исключить из процесса.
Это я назвал матрицей согласований.
Матрица экономит время на синках и помогает строить отношения внутри команды: так проще понять, хорошая ли связка дизайнер+продакт или нет.
А еще матрица увеличивает эффективность и ответственность: отвечать за решения будут конкретные люди, а не вся команда по чуть-чуть.
В блоге я оставил пошаговый разбор и ссылку на шаблон, чтобы вы могли использовать матрицу для себя.
P.S. Этот пост — начало серии заметок для начинающих тимлидов. Пишите, какие темы еще разобрать.
У дизайнера найдется десяток людей, которые «пытаются помочь» ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид.
Типовая ситуация: дизайнер приносит макет, вокруг собираются разработчики, менеджеры, подруга жены босса и каждый начинает «накидывать». Дизайнер погружает новых людей в задачу и доказывает, что сценарий решается интерфейсом. Бонусом идут редкие сценарии, которые «нужно обязательно учесть».
После этого интерфейс превращается в компромисс, пытающийся учесть все и сразу.
Оговорюсь — я не против фидбека от команды, но он должен быть в формате рекомендаций, а финальное решение остается за дизайнером.
У меня были такие же общие синки: куча мнений и бесконечные согласования. По ощущениям, такие встречи затягивали процесс. Нашел для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть.
Решение — поделить участников по категориям:
— кто реально принимает решения,
— кого просто держим в курсе,
— кого стоит исключить из процесса.
Это я назвал матрицей согласований.
Матрица экономит время на синках и помогает строить отношения внутри команды: так проще понять, хорошая ли связка дизайнер+продакт или нет.
А еще матрица увеличивает эффективность и ответственность: отвечать за решения будут конкретные люди, а не вся команда по чуть-чуть.
В блоге я оставил пошаговый разбор и ссылку на шаблон, чтобы вы могли использовать матрицу для себя.
P.S. Этот пост — начало серии заметок для начинающих тимлидов. Пишите, какие темы еще разобрать.
blogdm.ru
Матрица согласований
У дизайнера найдется десяток людей, которые «пытаются помочь» ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид
5🔥10❤3👍1
Дизайнер должен уметь писать текст
Если дизайнер вместо текста ставит Lorem ipsum и говорит, что кто-то другой допишет его позже — это рэд флаг 🚩
У нас долгое время не было редактора: все тексты дизайнеры писали вместе с продактом. Возможно, не всегда консистентно: например, где-то кнопка называлась «отменить», а где-то «отмена». Но самое главное — доносили смысл дизайна в том числе через текст.
Относительно недавно у нас появился UX-редактор — теперь наводим порядок в подсказках, кнопках в меню и вообще везде, где есть буквы. Тексты стали короче и информативнее.
Из минусов: работа идет дольше. Нужно погрузить редактора в задачу, объяснить контекст, показать сценарии. Но результат стоит того.
Из плюсов — финальные тексты можно примерить в дизайне и посмотреть, как все стало красиво. Да и разработчику проще: до этого правки по тексту могли прилететь уже после выкатки, потому что их в последний момент решили переписать.
Считаю, что у дизайнера должны быть базовые навыки письма. Даже если в команде есть редактор, дизайнеру полезно разбираться в текстах, потому что именно он держит в голове весь сценарий. Он знает, какие экраны до и какие после.
Не обязательно писать так же круто, как UX редактор — достаточно базовых навыков. Советую прочитать:
— «Пиши, сокращай» Максима Ильяхова;
— «Этой кнопке нужен текст» Кирилла Егерева.
Короч, пишите тексты для интерфейсов: слова важны так же, как и пиксели
Если дизайнер вместо текста ставит Lorem ipsum и говорит, что кто-то другой допишет его позже — это рэд флаг 🚩
У нас долгое время не было редактора: все тексты дизайнеры писали вместе с продактом. Возможно, не всегда консистентно: например, где-то кнопка называлась «отменить», а где-то «отмена». Но самое главное — доносили смысл дизайна в том числе через текст.
Относительно недавно у нас появился UX-редактор — теперь наводим порядок в подсказках, кнопках в меню и вообще везде, где есть буквы. Тексты стали короче и информативнее.
Из минусов: работа идет дольше. Нужно погрузить редактора в задачу, объяснить контекст, показать сценарии. Но результат стоит того.
Из плюсов — финальные тексты можно примерить в дизайне и посмотреть, как все стало красиво. Да и разработчику проще: до этого правки по тексту могли прилететь уже после выкатки, потому что их в последний момент решили переписать.
Считаю, что у дизайнера должны быть базовые навыки письма. Даже если в команде есть редактор, дизайнеру полезно разбираться в текстах, потому что именно он держит в голове весь сценарий. Он знает, какие экраны до и какие после.
Не обязательно писать так же круто, как UX редактор — достаточно базовых навыков. Советую прочитать:
— «Пиши, сокращай» Максима Ильяхова;
— «Этой кнопке нужен текст» Кирилла Егерева.
Короч, пишите тексты для интерфейсов: слова важны так же, как и пиксели
1👍6❤4
Тимлид должен работать руками
Кто-то считает, что тимлид не должен работать руками: он строит процессы, управляет командой, фидбечит макеты других дизайнеров. Я с этим не согласен.
Да, тимлид отвечает за процессы, коммуникацию со смежниками, согласования, мотивацию команды. Но быть сильным дизайнером «когда-то в прошлом» недостаточно — нужно работать руками, чтобы не потерять навык.
Интерфейсы постоянно меняются, старые паттерны устаревают, появляются новые. В этом нужно постоянно вариться, чтобы не терять навык: приносить свежие идеи, замечать слабые места в макетах и постоянно пополнять базу знаний «интерфейсов».
Что помогает держать форму?
Следить за трендами, смотреть на конкурентов, обсуждать общие решения на дизайн-синках и, конечно же, работать руками хотя бы 20-30% времени.
Это могут быть глобальные задачи, где нужно придумать направление или концепт, а проработку деталей уже передать дизайнерам. Или это могут быть задачи без горящих сроков, но важные.
В этом процессе тимлид как шеф-повар на кухне. Он готовит свои фирменные блюда и руководит кухней целиком: от получения заказа до выдачи в зал. Но, если будет нужно, он готов засучить рукава и сделать любое блюдо сам.
Короче, тимлид должен чутка работать руками. Это классный способ поддерживать навык дизайнера.
Кто-то считает, что тимлид не должен работать руками: он строит процессы, управляет командой, фидбечит макеты других дизайнеров. Я с этим не согласен.
Да, тимлид отвечает за процессы, коммуникацию со смежниками, согласования, мотивацию команды. Но быть сильным дизайнером «когда-то в прошлом» недостаточно — нужно работать руками, чтобы не потерять навык.
Интерфейсы постоянно меняются, старые паттерны устаревают, появляются новые. В этом нужно постоянно вариться, чтобы не терять навык: приносить свежие идеи, замечать слабые места в макетах и постоянно пополнять базу знаний «интерфейсов».
Что помогает держать форму?
Следить за трендами, смотреть на конкурентов, обсуждать общие решения на дизайн-синках и, конечно же, работать руками хотя бы 20-30% времени.
Это могут быть глобальные задачи, где нужно придумать направление или концепт, а проработку деталей уже передать дизайнерам. Или это могут быть задачи без горящих сроков, но важные.
В этом процессе тимлид как шеф-повар на кухне. Он готовит свои фирменные блюда и руководит кухней целиком: от получения заказа до выдачи в зал. Но, если будет нужно, он готов засучить рукава и сделать любое блюдо сам.
Короче, тимлид должен чутка работать руками. Это классный способ поддерживать навык дизайнера.
👍7❤2