UX Notes
24.9K subscribers
56 photos
3 videos
1 file
1.07K links
Чат читателей: @uxnoteschat В соцсетях: vk.com/ux_notes и fb.com/uxnotes Вакансии: @uxwork Автор: @zGrav Est. 2016. Реклама на канале: https://uxnotes.ru/ads
Download Telegram
2-й фильм из серии «Техническая эстетика» о ленинградском дизайне.

Выходцы из академии Штиглица (Мухинского училища) и их проекты:
— Игорь Серебреников: атомный ледокол «Ленин» (внешний вид и внутренности вроде рубки «Дюна-1»), научно-исследовательские суда «Изумруд», «Академик Крылов», «Михаил Сомов», большой десантный корабль.
— Валентин Кобылинский: карьерный самосвал БелАЗ-540, первый прототип УАЗа «Буханки».
— Константин Кудрявцев: ЗИС-111 «Москва».
— Николай Васильев: Кировский завод.

Директор ленинградского ВНИИТЭ Алексей Печкин: «При создании ледокола „Ленин“ потребовалось несколько лет для того, чтобы огромное количество специалистов, которые работали в конструкторских бюро и на заводах, научить более-менее правильно думать. Никто из них не заканчивал Мухинское училище. Надо было приехать и за 2 недели научить человека дизайну в принципе. Таких было по меньшей мере 20 предприятий».

— Мастерская Ленпроекта под руководством Иосифа Вакса: трамвай ЛМ-57 «Стиляга».
— Александр Веснин: теплоход проект-301 «Владимир Ильич».
— Олег Фролов: теплоход «Метеор».
— Валерий Тимошенко для ПО «Равенство»: удлинитель-разветвитель, радиоприёмник «Невский».

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

ВНИИТЭ:
— Татьяна Самойлова: электробритва Strig, бритва «Харкiв» модели 6601 и 7101, концепты наручных часов.
— Евгений Монгайт: жеребьёвочный комплекс Олимпиады-80.
— Н. Белков: пиктограммы Олимпиады-80.

Космическая дизайн-программа СССР:
— Николай Якуничев: слесарно-монтажный инструмент, экзокомбайн.
— Борис Малык: комплект слесарно-монтажных инструментов.
— Виктория Стрельцова и Н. Шахова: рабочие места операторов наземных служб.

«Нам надо было проанализировать работу операторов: что они делают за пультом, когда могут отойти и так далее. Это вылилось в очень интересную ситуацию. Поскольку нас в центр управления не пускали, операторы приходили к нам, и мы вытягивали из них информацию. Мы просматривали их медицинские карты и видели, что у них были проблемы с желудком, опорно-двигательным аппаратом».

https://www.youtube.com/watch?v=4eL8BDZ-JUU
Олег Большаков написал о проектировании системы уведомлений.

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

2. Создайте каркас: первый столбец таблицы — для событий, остальные столбцы — для уведомлений для каждой пары «задействованная роль и канал связи» (пуш-уведомления, письма, персональная лента). Например: «Персональная лента: Исполнитель».

3. Выпишите события, которые могут произойти в рамках процесса. События группируйте по ролям, которые их создают.

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

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

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

6. Доработайте события. Добавьте формулировки:

— Для массовых событий. Например: «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»;
— Для последовательностей действий. Например: если пользователь удалил одного утверждающего и добавил другого, пишите «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ».

https://habr.com/ru/company/wrike/blog/479324/
Опубликованы записи докладов с митапа UX-редакторов в «Яндекс Деньгах»:

1. Таша Гермогентова, «Яндекс Деньги» — Сколько нужно редакторов, чтобы вкрутить смысл
youtube.com/watch?v=_v80BAO5Woo

2. Евгений Лёфквист, «Сбербанк» — Как разобрать 200 штрафов и не умереть
youtube.com/watch?v=YCMw4CD08ac

3. Маргарита Хохлова, Profi.ru — Сколько стоит плохой текст
youtube.com/watch?v=mmvw5vnFqUs
Алан Купер написал, почему сейчас трудно делать удобные продукты.

Чтобы сделать удобный продукт, нужно много времени, денег, знаний и ресурсов. Бизнес ищет способ делать всё быстрее, проще и силами наименее квалифицированных людей.

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

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

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

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

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

Мы ищем ответы не в том месте.

https://vc.ru/design/97289
Ирина Моторина написала о сторифреймах.

Сторифрейм — это диалог между продуктом и пользователем. Написать его можно после исследования, перед созданием прототипа. Занимаются этим чаще дизайнеры и UX-писатели.

Сторифрейм:
— Помогает увидеть разделённый на экраны сценарий взаимодействия;
— Становится основой для прототипа;
— Помогает быстро прописать термины и tone of voice.
Артур Абраров написал, чем отличаются нативные приложения на iOS и Android (Material Design). Выжимки из части пунктов:

3. Общепринятый размер экрана для Андроида — 360 × 640 dp. Для Айоса проектируют под размеры iPhone 5 (320 × 568 pt) или iPhone X (375 × 812 pt).

5. В Андроиде есть встроенный инструмент для навигации назад — Android Navigation Bar. Стрелка «Назад» возвращает пользователя по пройденному пути на шаг назад как внутри приложения так и между ними.

6. В Material каждый компонент находится в конкретном месте на оси Z. Надо осознанно подходить к созданию теней.

8. Для верхнеуровневой навигации Айос рекомендует только Tab bar. Андроид — Navigation Drawer (если пунктов больше 5), Bottom Navigation Bar (от 2 до 5 пунктов) и Tabs.

10. В отличие от Segmented Controls в Айосе, между Tabs в Андроиде можно переключаться свайпами. Если используете Tabs, не добавляйте на экран элементы с похожими жестами: карусель картинок или карточки со взаимодействием свайпами.

12. В Андроиде пользователь может раскрыть Navigation Drawer жестом Edge Swipe слева вправо. Этот жест нельзя использовать для чего-то иного вместе с Navigation Drawer. В Айосе жест возвращает пользователя к материнской странице.

13. Поиск может быть в виде иконки. В Айосе она открывает отдельный компонент Search Bar. В Андроиде поле поиска отображается в Top App Bar. В Айосе поле поиска можно спрятать под Navigation Bar и отобразить его, сдвинув содержимое страницы свайпом вниз. Не стоит этим же жестом обновлять содержимое страницы.

15. В Айосе нет аналогов:
— Navigation Drawer — бургерное меню;
— Banner — сообщить важную информацию и предложить связанные действия;
— Snackbar — кратко сообщить о результате пользовательского действия;
— Chips — показать введённый пользователем контент вместе с дополнительными данными или элементами управления;
— Floating Action Button — закреплённая кнопка основного действия;
— Standard Bottom Sheet — страница, часть которой закреплена в нижней части экрана.

16. В Андроиде нет аналогов:
— Page Control — показать, на какой из страниц находится пользователь;
— Toolbar — панель с элементами управления;
— Steppers — кнопки увеличения и уменьшения чисел, например, количества копий для печати;
— Popover — всплывающая панель, например, для настройки текста в читалках и браузерах.

19. В Андроиде контролы единичного и множественного выбора (чекбоксы и радиокнопки) отличаются визуально. В Айосе это всегда галочки. В Андроиде можно использовать родительский чекбокс для выбора всех вариантов.

22. В Айосе дата выбирается с помощью барабана. В Андроиде — календаря или поля ввода.

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

26. При работе с текстом после долгого нажатия в Андроиде можно продолжить выделение текста. В Айосе появится лупа для точного выбора места в слове.

30. В Айосе можно потрясти телефон, чтобы появился диалог отмены последнего совершённого действия.

https://vc.ru/design/93884
Собрал самые популярные публикации UX Notes по числу лайков и репостов в ВК.

В топ-20 попали:
— 7 переводов статей: Николай Бабич, Джон Мур, Дейв Фельдман, Энтони из UX Movement ×2, Алита Джойс, Шейн Дойл;
— 6 подборок записей докладов с мероприятий: Design Prosmotr СПб, ProfsoUX, 404fest, Dump, Everfest, UX.txt;
— 5 оригинальных статей: Михаил Греков, Сергей Абдульманов, Татьяна Гущина, Ольга Коновалова, Наталья Стурза;
— 1 гайдлайн: СКБ Контур;
— 1 конспект доклада: Анна Кочеткова.

Спасибо, что читаете и рекомендуете @uxnotes знакомым дизайнерам и проектировщикам. Спасибо авторам полезных и интересных материалов.

https://vandergrav.ru/popular-ux-notes-2019/
Евгений Яровой написал, как защитить интересы дизайн-студии в суде.

— Как лучше провести досудебное урегулирование;

— Почему лучше не судиться: Евгений потратил на юриста и перелёты 120к, один потенциальный клиент отказался от сотрудничества из-за незавершённого арбитражного разбирательства, потрачено время (желательно, чтобы в суд явился не только юрист, но и исполнитель);

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

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

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

— Что делать, если запахло жареным: запишите результат работ на диск и отправьте заказчику Почтой России с описью вложения; проверяйте списки арбитражных дел, чтобы увидеть иск в случае, если официальное уведомление не дойдёт; начинайте искать юриста;

— Как выбрать юриста;

— Что стоит обсудить с ним: если дело рассматривается по упрощённой форме, а вы хотите донести до судьи аргументы устно, просите о переходе на общий порядок (имеет смысл для дизайнерских услуг).

https://vc.ru/legal/88258
Игорь Штанг написал, как объяснить клиенту воздух в макете.

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

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

Защищая решение, лучше ссылаться на задачу:
— Я ориентировался на референсы, которые мы обсуждали. Вот смотрите, как там сделано…
— Свободное место — это запас для длинных заголовков (если такие действительно встречаются в книге).
— Вы говорили, что вёрстка должна выглядеть современной и лёгкой (таким в целом выглядит дизайн с большим количеством воздуха).

https://nobelfaik.livejournal.com/203705.html
Екатерина Рокитян разобрала, как благотворительные организации стимулируют людей помогать.

Нет доверия организации:
— Показывать, на что пойдёт пожертвование (ShareTheMeal);
— Публиковать прозрачную отчётность (Фонд борьбы с лейкемией);
— Показывать других жертвователей (Ночлежка).

Кажется, что маленького пожертвования недостаточно:
— Предлагать подписаться на небольшое ежемесячное пожертвование (Нужна помощь);
— Показывать общую сумму сбора и количество жертвователей (Нужна помощь);
— Предлагать оплатить обычные продукты (Дари еду).

Неудобная оплата. Смски хорошо работают, когда участвует телевидение, но плохо подходят для интернета:
— Добавить возможность оплаты картой, а также через Apple Pay или Google Pay (Линия жизни);
— Подключить автоматический ежемесячный платёж.

Не готовы жертвовать деньги:
— Вовлекать человека в иную деятельность: бег (Charitymiles), просмотр видео с рекламой (GoodLoop) или воздержание от алкоголя (Dryathlon). Деньги перечислят партнёры или рекламодатели;
— Дарить подарки и мерч (Фонд борьбы с лейкемией, Elbi);
— Предлагать купить что-то, что создают люди, которым нужна помощь (Выход в Петербурге, Антон тут рядом);
— Рассказывать истории нуждающихся (Нужна помощь);
— Объяснять, кто такие бездомные и как они (не по своей воле) оказываются на улице (Ночлежка);
— Мотивировать жертвователя поделиться тем, что он совершил хороший поступок;
— Позволять создать событие по сбору пожертвований, например, попросить друзей пожертвовать деньги вместо покупки подарков на день рождения (Нужна помощь).

https://vc.ru/design/98296
Лучшие доклады предыдущих UX-марафонов:

1. Ксения Стернина, Mail.Ru Group — Удачные и неудачные дизайн-решения. Проведено в UX-лаборатории
https://www.youtube.com/watch?v=94q-lTzInhs

2. Анна Кочеткова, Тинькофф Бизнес — С хорошим текстом понятнее
— Видео: https://www.youtube.com/watch?v=hDqJzydcHMc
— Конспект: https://medium.com/nancypong/6d66fa378a1f

3. Дмитрий Сатин, UsabilityLab — Что такое инженерная психология
https://www.youtube.com/watch?v=PZOYeCVSf8o

4. Светлана Ратнер, СКБ Контур — Как формулировать гипотезы для качественного исследования
https://www.youtube.com/watch?v=7Sn41K7g0V4

5. Эмилия Городовых, СКБ Контур — Опыт применения JTBD на примере сложного продукта
https://www.youtube.com/watch?v=bc4OUnp7vdg

6. Елена Пяткова, Риалвеб — UX и веб-аналитика: какие данные нужны и как их собирать
https://www.youtube.com/watch?v=YTInVRJB5q4
Илья Александров рассказал, как тестирование инструкции привело к изменению продукта.

Лайтпак похож на Philips Ambilight, но его можно установить на любой телевизор. Инструкцию по установке хотели сделать как у Икеи — без текста. Это позволяло не делать отдельные её версии на других языках.

Установка Лайтпака — процесс нетривиальный. Сложные моменты при создании инструкции:
1. В продукте много технических ограничений, и, как следствие, требований, которые пользователь должен соблюсти;
2. Авторы сами до конца не понимали, какой порядок действий будет самым удобным.

Решили протестировать 2 концепта инструкции:
1. Досконально шаг за шагом говорить человеку, что делать;
2. Говорить, что нужно получить в итоге и какие важные требования соблюсти. Как достигнуть цели, человек решал сам.

Респондентов так захватывал процесс, что в инструкцию они почти не смотрели. Тестирование показало:
— 2-й концепт работал гораздо лучше;
— Всё сильно усложняли умные уголки для крепления светодиодной ленты.

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

В итоге придумали протягивать ленту по периметру телевизора, не разрезая её. На программном уровне можно узнать длину всей ленты. Большинство телевизоров имеет соотношение сторон 16:9 или 16:10, поэтому получилось автоматически рассчитывать длины сторон.

Решение оказалось проще и дешевле для разработки, а также упрощало пользователям установку Лайтпака.

https://medium.com/yakostro/857142a2f4f0
Специалисты PromoPult написали, что можно показать на странице с нулевыми результатами поиска в интернет-магазине.

1. Ссылки на категории товаров, в которых пользователь может найти то, что искал. Запрос «красная зимняя куртка в клеточку» → Ссылка на категорию «Куртки» с применённым фильтром «Зима».

2. Результат поиска по альтернативному или более простому запросу. Запрос «яркий прочный чехол с арбузами для старого айфона» → Запрос «арбузы iphone чехол».

3. Ранее просмотренные товары.

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

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

6. Популярные товары и категории. Мотивация «другие люди покупают этот товар» всё ещё работает.

https://vc.ru/marketing/102028
UserTesting спросили дизайнеров, исследователей и аналитиков, что такое UX Design.

— Лора Кляйн, директор платформы Users Know, автор книги UX for Lean Startups:

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

UX Design происходит постоянно. Намеренно или нет, кто-то принимает решения и определяет, как человек будет взаимодействовать с продуктом. Хороший UX дизайн случается, когда мы принимаем решения так, чтобы понять и удовлетворить потребности наших пользователей и нашего бизнеса.

— Дан Макоски, вице-президент по дизайну в CapitalOne:

UX дизайна не существует. Опыт — это личное переживание человека, и дизайнеры не владеют им. Однако мы можем создать что-то для человека в момент переживания. Это тонкое, но важное различие.

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

http://tilda.education/articles-what-is-ux-design
Angry рассказали, как защитить дизайн перед заказчиком — отстоять до 80% функциональных решений и не прогнуться под градом правок.

1. Выбирайте правильных клиентов. Красные флажки: бюрократия уже на этапе продажи, если проект создаётся не для людей, а для освоения бюджета.

2. Собирайте аргументы — статистику и инсайты по теме проекта. Это проще, если вы специализируетесь на проектах одного типа или предметной области.

3. Если аргументов не хватило, спорные моменты проверяйте в финале на юзабилити-тестировании.

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

5. Обучайте заказчика.

6. Ставьте чёткие сроки на правки. У заказчика должен быть человек, ответственный за сроки предоставления и непротиворечивость списка правок.

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

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

9. Спрашивайте: «А зачем это нужно?» — хороший вопрос-маркер, который помогает отличить полезную идею заказчика от шальной.

10. Давайте потрогать интерактивный прототип. Ссылка на него может быть в презентации в виде QR-кода. Когда заказчики изучают приложение прямо на своём смартфоне, они видят продукт глазами пользователей, и многие вопросы отпадают сами собой.

11. Приглашайте третейского судью из команды заказчика.

12. Прокачивайте технический бэкграунд. Он пригодится, когда разработчики скажут о ваших решениях, что «так сделать нельзя».

https://vc.ru/design/100987
Опубликованы видео с секции «Дизайн» фестиваля G8 2019.

1. Денис Мосин — Карго-культ в создании продуктов
youtube.com/watch?v=nj_zU-UVGPs

2. Егор Коробейников, Miro — Распределённое будущее креативной работы
youtube.com/watch?v=DkNsAmDDjns

3. Денис Шумов, Mail.ru Group — Эмоциональная коммуникация в интерфейсе продукта
youtube.com/watch?v=1Dp3MkC6xeE

4. Дмитрий Глазырин — Как работать с любой компанией этой планеты
youtube.com/watch?v=IzuWGk3c_l0

5. Артем Щербаков, ZheeShee — Процесс поиска идеального проекта для студии
youtube.com/watch?v=KM6HylxFtPs

6. Юрий Нарвин, Молния — Трансформация сферы дизайн-услуг
youtube.com/watch?v=GYQLDKAaYeI

7. Владимир Зимин, Почта России — Дизайн для реального мира
youtube.com/watch?v=D0g8-7bHHiM

8. Иван Браун, Icon8 — Хорошие и плохие исследования для развития продукта
youtube.com/watch?v=tUs2vDVLaPU

9. Павел Колодяжный — Страх, боль и продукт
youtube.com/watch?v=SljrZIVMejU

Все видео в одном месте: youtube.com/playlist?list=PLzqQCeTtpSBrJs8X4URctZtugDJ9yTps3
Я написал, что делать с текстом в прототипе, если в команде нет UX-писателя.

1. Постоянно меняющийся текст (анонсы и текст новостей, имена сотрудников, пользовательский контент):
— Брать с текущего проекта или похожего, если проект делается с нуля;
— Писать реалистичный заголовок и генерировать текст с помощью Яндекс Рефератов или Рыбатекста. В начало такого текста полезно добавить, что он не несёт никакого смысла и нужен для объёма.

2. Справочный (о компании, политика конфиденциальности):
— Генерировать, но обозначать суть, зачем он вообще нужен, кто и с какой целью будет его читать.

3. Решающий определённые задачи (преимущества компании, важные особенности продукта, порядок работы):
— Формулировать черновую версию текста. Часто проектировщик довольно хорошо понимает, о каких преимуществах компании и особенностях продукта надо рассказать, чтобы убедить покупателя сделать заказ. И знает, что написать;
— Обозначать суть сообщения, не формулируя его.

4. Микротекст (подписи к полям, надписи на кнопках, пункты меню, служебные сообщения):
— Писать конкретные формулировки, придерживаясь общих правил вроде использования глаголов на кнопках;
— Закладывать идеи вроде написания на кнопке «Стать благотворителем» вместо «Пожертвовать», чтобы кликов на неё было больше.

https://vandergrav.ru/text-in-prototype/
Ксения Стернина рассказала, о чём не надо писать в сопроводительном письме на вакансию дизайнера.

1. Информация, не имеющая отношения к работе: откуда вы родом, семейное положение, увлечения;
2. Фразы о том, что вы хотите развиваться. Работодатель хотел бы видеть сфокусированность на развитии продукта;
3. Много текста и вода. Попытки сделать удобно в виде дополнительных кратких версий не работают;
4. Рассказы о своей уникальности. Работодатели не любят незаменимых людей. Часто такие рассказы — признак посредственности или высокой сложности при взаимодействии;
5. Достижения, которые сложно трактовать. Стали быстро создавать дизайн? А раньше за сколько справлялись? А что с качеством?
6. Ментальная нагрузка. «Занимаюсь дизайном с 2014 года» → «6 лет опыта»;
7. Недосказанности. «И так далее, и тому подобное, и многое другое» → Удалить;
8. Округления и преувеличения. «Сделал более 50 проектов» → «Сделал 52 проекта». Руководил командой «от 5 человек» → «в 5 человек»;
9. Жалобы на предыдущего работодателя. Если были сложности, расскажите, как вы с ними справились;
10. Намерение учиться в компании. Вы ещё ничего компании не дали, но уже хотите, чтобы её специалисты тратили время на ваше обучение;
11. Самоуничижение. Научитесь интересно рассказывать о себе. Почему работодатель должен поверить в вас, если вы сами не верите?
12. Ссылки на скачивание. Если что-то нельзя посмотреть онлайн, не ссылайтесь на это вовсе;
13. Битые ссылки, ошибки в орфографии и пунктуации. Если вы не проверили текст письма, возможно, вы так же халатно относитесь и к работе;
14. Заискивание. Всем хочется иметь в окружении сильных людей. Найм — это сотрудничество, а не отношение благодетеля и просящего.

https://blog.uxssr.com/2020/01/29/cover-letter-for-designers/
Джон Айзлвуд написал, как избежать раздробленности дизайна при гибкой разработке продукта.

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

1. Постарайтесь в самом начале (нулевой спринт) как можно лучше изучить продукт и связанные с ним ограничения;
2. Сделайте концептуальное проектирование: используя полученные знания, набросайте эскизы всех возможных экранов. Найдите и заполните выявленные пробелы;
3. Определите точное креативное направление, создайте элементные коллажи — мудборды вымышленных и реальных элементов интерфейса;
4. Подключите разработчиков как можно раньше. Они укажут на технические ограничения и не решённые дизайнерские задачи;
5. Запустите дизайн с форой минимум в один спринт перед разработкой;
6. Запланируйте остановки, чтобы взглянуть со стороны на то, что в целом получается;
7. Выделите 10% времени спринта на исправление ошибок в дизайне, чтобы повысить целостность и улучшить восприятие продукта.

https://deadsign.ru/workflow/agile-and-design-how-to-avoid-frankensteining-your-product/
Дима Хими написал, что надо учесть при создании юзабилити-лаборатории.

1. Простой вход для респондентов, без предъявления документов и заказа пропусков;
2. Туалет поблизости, чтобы не отвлекать исследователей на сопровождение гостей по офисным закоулкам;
3. Отсутствие прозрачных стен и дверей, чтобы респонденты не отвлекались на проходящих мимо людей;
4. Хорошее освещение, которое не слепит и не бликует на экранах;
5. Наличие окон. Респонденты бывают разные, иногда надо хорошо проветрить помещение;
6. Возможность напоить респондента водой, кофе или чаем;
7. Звукоизоляция, чтобы респонденты не отвлекались на посторонние звуки;
8. Доступный вайфай, чтобы легко протестировать сайт на устройстве респондента;
9. Вешалка для одежды и стул для вещей респондента;
10. Отсутствие растений или цветов, которые могут вызывать аллергию;
11. Большие и непрозрачные столы. Респондент не должен быть слишком близко к исследователю. Респондентам в коротких юбках может быть некомфортно за прозрачным столом;
12. Комфортная температура.

И ещё:
— Оборудование должно быть постоянно подключено и настроено, необходимые программы обновлены, их лицензии продлены;
— В комнате должны быть дублирующие кабели, зарядки и розетки;
— Должны быть источники бесперебойного питания.

https://medium.com/dimahimi/71e4b240a10e
Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

В первой статье разбирается просмотр данных.

1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
6. При наличии цветовых индикаторов полезно отображать легенду цветов.
7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
10. Нет ничего страшного при появлении горизонтальной прокрутки.
11. В некоторых случаях полезно маркировать просмотренные записи.
12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
13. Переход к просмотру записи удобно сделать по двойному клику.
14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».

https://designpub.ru/5ea60df37f12