Антон Жиянов неделю вёл коллективный твиттер продактов и по итогам составил статью с мыслями (и ссылками на материалы, которые эти мысли развивают) про продукт и фичи, B2B и кровавый энтерпрайз, API и документацию, техподдержку, разработку, интерфейс и людей.

«Главная проблема „долгоживущих“ продакт-менеджеров и вообще любых сотрудников: со временем у человека замыливается глаз. Команда перестаёт видеть очевидные извне проблемы продукта и упускает возможности.

Знаю один сервис, где нельзя зарегистрировать двух пользователей с одинаковым именем (то есть не может быть две „Анны“, например). Основатель мне на полном серьёзе объяснял, что это фича и так и должно быть».

«Самое „весёлое“ в российском B2B — это документооборот, так же известный как „счета и акты“. Если вы прискакали из мира мобилок на розовом пони, эта штука срежет вас как наточенный серп».

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

https://antonz.ru/productology/

Появились первые видео с ProfsoUX 2019 года:

1. Иван Бакаидов — Пандус для интерфейса
https://vimeo.com/324745869

2. Михаил Правдин — Собираем все UX-находки в одном месте. Как обработать и не потерять результаты исследований
https://vimeo.com/324745961

3. Нелли Кам — Образовательное выгорание
https://vimeo.com/324745915

4. Алёна Кирдина — Работа над ошибками
https://vimeo.com/324745933

5. Scott Sullivan — Machine Learning for Designers
https://vimeo.com/324745884

6. Hyacinthe Briand — Designing with Data
https://vimeo.com/324745892

7. Наталья Мануйлова — UX-стратегия — ценность продукта
https://vimeo.com/324745835

8. Тамара Кулинкович — Долина страданий. Как продавать исследования и продавать с помощью исследований
https://vimeo.com/324745949

9. Диана Вайнберг — Эвристики как база знаний по UX
https://vimeo.com/324745907

Станислав Хрусталёв описал идеальный customer journey посетителя ресторана.

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

«Все телефоны ресторана должны поддерживать функцию определения номера, чтобы не спрашивать номер клиента при бронировании, а просто подтверждать: „Записать номер, с которого звоните?“»

https://hardclient.com/restaurants

Интервью с Денисом Башевым, основателем дизайн-агентства DILETTANT.

«Большинство дизайнеров не понимают, в чём заключается их работа. Начинаются сравнения в духе „Лебедев или кто-то ещё нарисовал логотип, он похож на…“. Люди не понимают, что уникальности в проекте может вообще не быть.

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

«— Ты работаешь над проектом у клиента, просишь выделить себе место в его офисе. Делаешь так сейчас? Как тебе такой формат?

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

«— Ты не считаешь, что дизайн спасёт мир. Почему для тебя он важен?

— Мне удовольствие доставляет. То, что я навожу порядок в комнате по сути тоже бесполезно. Кому какое дело, чисто у меня или нет. Но испачкается, тебе приходится наводить порядок. В дизайне то же самое. Ты наводишь порядок в определённом визуальном куске. Мне комфортно быть дворником в этом плане. Оно моё».

https://designpub.ru/a5e7c1124203

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

«Мы дали респондентам задание: „Вот ваш чай, представьте, что вы пришли с работы домой, и у вас есть 20−30 минут свободного времени. Перед вами портал Mail.Ru, просто проведите время с интересом, читайте и смотрите, что хочется, а что не хочется — не читайте“. После чего исследователь перешёл в наблюдательную комнату.

Мы видим, как одна из девушек читает статьи про селебрити одну за другой. Когда исследователь вернулся в тестовую комнату, он спросил: „Расскажите, что вам больше всего запомнилось из того, что вы прочитали?“.

Та самая респондентка ответила: „Ну я тут почитала РБК…“

Люди врут. Цели у этого могут быть разные. В данном случае ей просто хотелось показаться лучше, чем она есть. Это называется „социально-желательное поведение“. При изучении темы нельзя ограничиваться только интервью, иначе вы узнаете, что все читают РБК, каждый день занимаются спортом и много зарабатывают».

https://www.sternina.com/notes/users-lie/

Тим Шеинер написал о «цифровой машине» — схеме, которая описывает цифровой продукт как совокупность 5 моделей: пользователя, ценности, взаимодействия, объекта, данных.

Они всегда существуют в виде неосознанных допущений в головах участников проекта. Такие допущения — основной источник неразберихи.

1. Модель пользователя описывает того, кто использует цифровую машину, и определяет цели, действия и эмоции. Для проекта это вымышленный персонаж с определёнными характеристиками.

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

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

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

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

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

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

Чем подробнее история в модели взаимодействия, тем выше детализация и точность описания объектов, вступающих во взаимоотношения. Верно и обратное: если разбить объекты на подобъекты, история их взаимодействия становится более подробной.

5. Модель данных строится на основе простого принципа — пара имя/значение.

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

https://sobakapav.ru/publications/designing-digital-mental-models

Андрей Клёц написал о популярных проблемах форм в банковских приложениях.

1. Отсутствие маски при вводе номера телефона. Используйте маску вида +7 ( ) _-__-. Автоматически исправляйте ошибки ввода.

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

3. Неинформативные подсказки. Не стоит повторять в них название поля, писать очевидные вещи и использовать непонятные термины. Полезно объяснить, что означает название поля, в каком формате вводятся данные, сколько символов надо ввести, откуда брать информацию для ввода.

4. Подсказки и названия полей, которые исчезают после начала ввода. Располагайте подсказки над полем, выносите их в заголовок после начала ввода или показывайте маску ввода.

5. Отсутствие возможности посмотреть введённый пароль. Его можно показывать временно при нажатии на специальный значок.

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

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

8. Активная кнопка отправки формы при незаполненных полях. Пользователь считает, что форма заполнена верно, и в итоге сталкивается с сообщением об ошибке.

9. Перегруженная форма (характерно для платежей по квитанциям). Выделите главные поля, ненужные скройте.

10. Буквенная клавиатура вместо цифровой при заполнении числовых полей (вроде поля «Сумма»).

http://usabilitylab.ru/blog/usability-form-vvoda/

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

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

И вот решила эта страховая компания сделать все по уму в наш век Человекоориентированного Дизайна, Юикса-Сиикса и прочего Хуикса, и отправилась она с заказом в Специализированную Юзабилистическую Контору. Специальная Юзабилистическая контора была клевая: она носила какой-то красивый термин в названии (типа, НИИ ЮИКС или, там, АРТ ОФ ИНТЕРФЭЙС), штат ее сплошняком состоял из специально обученных психологических людей, издали похожих на хипстеров, а в клиентах числился весь белый свет вплоть до ФГУП «ГУСЬ-ХРУСТАЛЬНЫЙ АЛМАЗВНЕШТОРГЭКСПОРТОБЪЕДИНЕНИЕ».

Эти серьезные ребята сходу включились в работу, подняли на крыло целый безумный аэроплан UX-процессов, исследований, групповых фасилитаций, кастдев-оргий и всего такого - и уже через два месяца с лишним принесли заказчику результат: нарисованные интерфейсы лучшего в мире ЛК. Интерфейсы были и правда клевые: от картинок веяло эстетической мощью, за каждой кнопкой скрывалась какая-нибудь UX-премудрость, а на любой вопрос «А почему здесь так?» творцы подпускали нервическую дрожащую ноту в голос и заявляли «ВЫ БЫ ВИДЕЛИ КАКОЙ ТАМ СИДЖЭЭМ» - после чего от них сразу отставали.

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

Заказчик был не против, так что все ударили по рукам, и работа над ТЗ закипела. Впрочем, «закипела» - это громко сказано, потому что она по факту и закипеть не успела: практически сразу же, с главного же экрана ЛК, стало ясно, что в интерфейсе творится что-то поганое.

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

Разработчик изрядно удивился, поднял брови и пошел к заказчику - выяснять, а с хера ли такая радуга в небе возникла. Заказчик, справедливости ради сказать, быстро въехал в тему, быстро забеспокоился и пригласил к себе ребят-юзабилистов - разобраться, как так-то.

И вот тут настает мой любимый момент. Юзабилистические ребята, представшие перед судом Ее Величества Логики, и глазом не моргнули и заявили следующее: «МЫ НЕ ИНЖЕНЕРЫ МЫ КОНСАЛТЕРЫ И ПСИХОЛОГИ И СДЕЛАЛИ УДОБНО А РАЗРАБОТКА ПУСТЬ ПОДТЯГИВАЕТСЯ ОНА ВСЕГДА ВОЗЬМЕТ СВОЕ ПУСТЬ РАЗРАБОТЧИКИ ПОСИДЯТ ПОДУМАЮТ И СДЕЛАЮТ ЭТО УЖЕ ИХ ЗОНА ОТВЕТСТВЕННОСТИ».

В общем, улавливаете, да? Ребята, которые занимаются интерфейсами, вертеть хотели какие-то там технические ограничения и сработали как настоящие Творцы в Сфере Чистого Разума, сделав Хорошо и Удобно. А уж что какие-то черти-разработчики не могут это сделать - это уже их проблемы, пусть учатся.

И вот тут, котаны, на белый свет выползла невообразимая херня: этим хуикс-гуру было невдомек, что доработки по их психологическим капризам потребуют столько денег и отнимут столько времени, что проще будет разогнать страховую компанию и организовать какую-нибудь новую. Под удар был поставлен весь продукт, потому что 3 месяца работы были потрачены впустую, деньги были съедены зря, и руководство страховой было готово махнуть рукой и сказать «ДАВАЙТЕ ЖИТЬ СО СТАРОЙ СИСТЕМОЙ А ЭТИХ UX ПИДАРАСОВ БОЛЬШЕ НЕ БУДЕМ ЗВАТЬ ОТ НИХ ВРЕД ОДИН» - и, что характерно, они были бы не так уж неправы.

В итоге все кончилось хорошо и интерфейс перерисовали под корень (и уже вместе с разработчиками), но вот эту фразу «МЫ НЕ ИНЖЕНЕРЫ МЫ ПСИХОЛОГИ», к сожалению, я сам слышал миллион раз, чтобы понимать - эта ебалайка будет играть вновь и вновь, пока все не поймут, что психология и инженерия - не космически разные явления, а стороны одной монеты под названием UX.

Впрочем, про это мы с вами еще поговорим - и не раз.

Николай Бабич составил правила написания интерфейсного текста. Наименее очевидные рекомендации:

3. Инструкции начинайте с пользовательской цели. «Нажмите на элемент, чтобы увидеть его свойства» → «Чтобы увидеть свойства элемента, нажмите на него».

5. Будьте последовательны. Если в одной части интерфейса вы назвали процесс «бронированием», не называйте его «резервированием» в других частях.

7. Убирайте лишние глаголы. «Видео было загружено» → «Видео загружено».

8. Пишите в активном залоге. «Кнопку „Поиск“ следует нажать, когда вы будете готовы искать статью» → «Чтобы найти статью, нажмите на кнопку „Поиск“».

9. Пишите числительные цифрами. «У вас два пропущенных звонка» → «У вас 2 пропущенных звонка».

10. Раскрывайте информацию постепенно (особенно в мобильных интерфейсах). Если пользователь заинтересовался одним из тезисов, пусть нажмёт кнопку, чтобы узнать больше.

14. Если речь о сегодняшнем, вчерашнем или завтрашнем дне, пишите «сегодня», «вчера» и «завтра» вместо даты.

https://contented.cd/media/text_ux

Михаил Греков написал об управлении табличными данными и их экспорте.

1. Действия с одной записью:
— Основное действие можно выполнять двойным кликом на строку, а полный список действий показывать по нажатию правой кнопки мыши. Не годится для тач-интерфейсов. Пример: веб-версия Google Drive.
— Можно показывать кнопку основного действия, а дополнительные прятать в кебаб-меню. Если поставить кебаб в начале строки, пользователь сразу его заметит при любом количестве столбцов. Пример: панель управления сайтом на Битриксе.
— Кнопки действий можно показывать при наведении курсора на строку. Минусы: строки мигают, кнопки закрывают часть информации, не годится для тач-интерфейсов. Пример: Gmail.

2. Действия с несколькими выделенными записями:
— Список действий можно показывать над таблицей (всегда или когда выбраны записи). Пример: Wordpress.
— Список действий для всех выделенных записей можно показывать по нажатию правой кнопки мыши. Минус: пользователю надо как-то рассказать об этом приёме.
— Выделенные записи можно перетаскивать на нужные действия. Минус: экзотика и для пользователей, и для разработчиков. Пример: Яндекс-почта.

3. Если у записей в таблице есть однородные свойства, работать удобнее, когда можно быстро изменить их для нескольких записей. Пример: Redmine.

4. При выборе нескольких записей удобны:
— Выбор интервала. Пользователь выбирает 1-ю строку, зажимает Shift и выбирает последнюю строку в интервале. Пример: Gmail.
— Выбор всех строк. Важно, чтобы пользователь понимал, выбраны вообще все записи или все записи на текущей странице.

5. Редактирование данных непосредственно в строке:
— Полезно, когда выводятся часто сменяемые свойства (приоритет, статус, ответственный менеджер).
— Удобно, если при изменении данных не надо вводить причину изменения и т.п.
— Требует подсказки: какие данные можно изменить в строке, как перейти к редактированию, как сохранить изменения. Понятнее всего — иконка карандаша для изменения и галка для сохранения.

6. Пользовательский экспорт данных (данные экспортируются для работы с ними в другой системе или передачи другому человеку):
— Для такого экспорта не годится формат CSV.
— XLS-файл надо готовить для дальнейшей работы с ним: соблюдать ширины столбцов, форматы данных, выделение шапки и т.п.
— Файл надо называть осмысленно с указанием даты и времени экспорта.
— Дату и время экспорта желательно продублировать перед таблицей на случай отправки её на печать.

https://designpub.ru/110fe6de533f

Илья Рудерман создал памятку с рекомендациями по оформлению текста для дизайнеров и редакторов.

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

Документ 2014 года не теряет актуальности:
— Отдельными слайдами: https://www.dropbox.com/s/d12ffcil0ttm06a/ria-rules.pdf
— В виде плаката: https://www.dropbox.com/s/hj0l185ji3kyxc5/ria-rules-poster.pdf

Забавная картинка о том, как называть разные иконки меню.

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

Ваня Соловьёв написал о подходе к мотивированию и развитию дизайнеров в DocDoc.

Продуктовый дизайнер может находиться на одном из 9 уровней с определёнными:
1. Ролью и обязанностями.
2. Скилами и требованиями. Каждый новый уровень включает скилы предыдущих.
3. Условиями перехода на новый уровень.
4. Книгами для прочтения (теоретическая база).

Дизайнер получает баллы за достижение поставленных метрик. Задача с метрикой «сделать имиджевую страницу» может оцениваться 1–2 балла, т.к. её сложно измерить в деньгах. А задача «достигнуть конверсии в заявку 12%» — в 4–5 баллов.

Подать заявку на повышение уровня можно 2 раза в год. Дизайнер проводит встречу с участием HR-директора, продуктового директора и директора по дизайну, где выступает с презентацией своего прогресса.

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

https://designpub.ru/8f0cdd5612ea

В компании «СКБ Контур» описали портрет продуктового проектировщика интерфейсов.

— Кто это.
— Идеальный процесс работы над задачей.
— Требования к прототипам и работе с ними.
— Матчасть: какие книги надо прочесть и принципы понять.
— Должен ли прорабатывать интерфейсный текст (спойлер: это его зона ответственности).
— Знания и навыки в дизайне и вёрстке, исследовании пользователей, веб-технологиях и статистике.
— Инструментарий (Sketch или Figma для интерфейсов).
— Требования по самоорганизации, саморазвитию и передаче опыта.
— Взаимодействие в команде.
— Развитие продукта.
— Этика.

Пример нескольких высокоуровневых характеристик проектировщика:

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

Интересное из раздела «Этика»:

— Работы, сделанные в Контуре, можно выкладывать в свое личное портфолио. Нужно указать, что именно сделал владелец портфолио в этом дизайне.
— В личное время проектировщик может делать коммерческие неконтуровские задачи. В определенной степени это даже приветствуется, так как способствует развитию.

https://guides.kontur.ru/principles/uidesigner/

Алексей Бородкин рассказал о методике создания текста для цифровых продуктов.

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

Если на старте ничего нет, готовят контентное задание, включающее ответы на вопросы:
— Что мы хотим сказать пользователю;
— Где и в каком контексте;
— Как мы это рассказываем (логическое ударение, стиль, голос);
— Ценные указания для копирайтера (например, «здесь хорошо бы перечислить 4 преимущества продукта»).

Копирайтер (желательно, штатный) пишет 1-ю версию текста, его подставляют в дизайн, примеряют и дорабатывают параллельно с дизайном.

Когда проект готов, составляют контентный гайд, похожий на контентное задание. Он нужен, чтобы будущие копирайтеры ничего не испортили.

https://medium.com/советы-по-проектированию-интерфейсов/18e27c85e066

Конспект ещё одного доклада с прошедшего UX-марафона — Марина Степанова рассказала, как писать текст для тех, кто не читает.

Пользователь не читает интерфейсный текст, когда:
1. Пользователь — ребёнок.
2. Текст на незнакомом языке.
3. Нет времени что-либо прочитать (за рулём).

Как написать:
1. Убедитесь, что текст помогает достичь цели.
2. Сократите объём (даже если получается слишком сухо).
3. Говорите с пользователем на одном языке (общайтесь с представителями вашей аудитории, тестируйте текст).
4. Не путайте разные символы (ее → её).

Также в конспекте: как оформить, как не убить мотивацию к чтению, как обойтись без текста.

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

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

https://vandergrav.ru/writing-for-users-who-dont-read/

Наталья Хродская написала о работе с сетками в вебе.

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

Сначала дизайнер определяет структуру макета и уже потом создаёт под неё сетку.

Виды сеток:
1. Блочная или манускриптная — стандартизированный прямоугольник, который содержит контент. Например, страница книги или статья блога;
2. Колоночная — имеет в своей структуре колонки;
3. Модульная — имеет как вертикальное членение, так и горизонтальное. Модуль — блок размером с заданное количество столбцов и строк;
4. Иерархическая — интуитивное размещение блоков с фокусом на пропорциях и визуальном весе элементов.

Также в статье:
— Что такое базовая сетка. Преимущества 8-пиксельной базовой сетки;
— Понятия hard и soft сеток;
— Вертикальный ритм и разделение макета на строки;
— Преимущества 12-колоночной сетки и работа с ней в адаптивном дизайне.

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

https://medium.com/design-spot/410cfc1df74d

Инесса Шилло написала о профессиональном выгорании дизайнера.

Лёгкая усталость и опустошённость по будним дням. Проблемы со сном. Сложнее попадать в состояние потока. Неохотнее встречаться с друзьями.

Предпосылки к выгоранию в дизайнерской работе:
1. Работа под NDA.
2. Ощущение, что вы — чьи-то руки. Например, когда артдиректор (или в запущенном случае — клиент) говорит, как делать.
3. Работа над чужими концепциями. Опять же, когда артдиректор задаёт идею, а дизайнер её прорабатывает.
4. Проекты в стол.
5. Переработки.
6. Мысль о несерьёзности работы. Когда студия дизайна кажется менее серьёзным бизнесом, чем завод или заправка.
7. Финансовый потолок. Чтобы каждый год удваивать или утраивать доход, надо становиться управленцем в виде артдиректора или создавать своё агентство.
8. Отчуждённость труда. Ваш дизайн — деталь для машины, которая состоит из кучи других деталей и на которой зарабатывает другой человек (заказчик).

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

https://designpub.ru/588259b30142

Михаил Греков написал, как появляются заботливые продукты, о которых хочется рассказать друзьям.

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

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

Примеры заботы, вызывающей вау-эффект:
— Лондонский убер ViaVan  за 2 минуты до конца поездки напоминает, что скоро выходить. Боль: поездка заканчивается для пассажиров внезапно, и они покидают такси в спешке, забывая свои вещи.
— Магазин «Лабиринт» сообщает, что покупатель выбрал доставку на праздничный день. Боль: покупатели забывают, что будет выходной, и не могут получить заказ, так как куда-нибудь уезжают.
— Ещё примеры смотрите в статье.

https://designpub.ru/a3ea75f4a129