Иван Емелюшкин написал, что может предпринять дизайнер (не фрилансер), если у него кончились задачи.

1. Прошерстите продукт и найдите, что не так: кривая вёрстка, старые элементы интерфейса, плохой текст, иконки не подходят друг к другу, забыли про технические разделы или пустые экраны.

2. Залезьте в соседнюю область. Если работаете над приложением, обратите внимание на сайт, рассылку, печатку, рекламу или интерьер магазинов.

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

3. Сядьте с аналитиком или хотя бы Вебвизором, найдите проблемы и предложите решения.

4. Проведите пользовательское тестирование с опытными пользователями и новичками. Пройдитесь по основным и второстепенным сценариям.

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

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

7. Заявите о себе: напишите статью, распишите кейс, опубликуйте работу в портфолио.

https://designpub.ru/67ac0a28a732

Аврора Харли написала о непредсказуемой работе крестиков, закрывающих окна с формами.

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

Чтобы продукт вёл себя предсказуемо:

1. Запрашивайте подтверждение перед деструктивным действием, когда могут пропасть пользовательские данные. Например, если пользователь закрывает фильтр, не применив его, отобразите диалоговое окно: «Вы хотели бы применить фильтр перед возвращением в список товаров? Да / Нет».

2. Замените крестик на текстовую кнопку, которая чётко даст понять, что произойдёт: отмена или закрытие.

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

https://ux.pub/otmenit-ili-zakryt-dizayn-neodnoznachnyh-deystviy/

Евгений Арутюнов рассказал, как устроено дизайн-бюро «Интуиция».

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

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

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

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

Дизайнеры учатся писать код, текст, работать менеджерами, общаться с клиентами и управлять своим временем. В проекте люди выступают в разных ролях. Это не значит, что один человек делает в проекте всё (и работа на нём замыкается), но каждый умеет выступать в разных ролях.

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

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

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

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

Если есть проект, но под него надо взять ещё 3 дизайнеров и 10 разработчиков — проект не берут. Растут только когда есть готовые внутренние ресурсы. Подбирают проекты под команду (на момент записи это 7 человек).

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

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

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

Для мелких трат у всех есть доступ к расчётному счёту. Единственный риск — человек недооценит свою работу и будет просить слишком мало. Чтобы человек хорошо распределял деньги, он должен быть хорошо проинформирован. Координатору проекта Евгений продаёт свои услуги артдиректора. Это внутренний рынок.

Есть полочка, на которую надо отложить 20-25% от бюджета проекта. С неё можно брать деньги на развитие, обучение, компенсации ударов судьбы, офис и поездки (когда они были). На маркетинг трат сейчас нет. Если на полочке что-то пролежало 2 месяца и осталось невостребованным, это прибыль, которую забирает Евгений. Это мотивирует работать над развитием бюро на длинной дистанции.

Бюджет проекта не влияет на процесс. Всегда надо следовать своему дизайн-процессу и делать хорошо. Но и брать за свою работу надо по-максимуму.

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

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

Это не рецепт организации работы, это образ жизни. «Мы хотим играть, а не искать баланс между работой и жизнью». Этой схеме работы примерно 2 года, к которой пришли от более классического фриланса с помощниками.

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

https://www.youtube.com/watch?v=1oAAtHyh9cw

Валерий Пеньков из томской «Студии Т» беседует с руководителями диджитал-агентств. Уже есть 4 выпуска:

4. Руководитель Wow Николай Глухих
youtube.com/watch?v=QtMD0PytMZ4

3. Учредитель FINCH Дима
youtube.com/watch?v=Z8oYhybaot0

2. Гриша Коченов и другие из AGIMA
youtube.com/watch?v=VDClVpfbUPg

1. Исполнительный директор CreativePeople Сергей Прокофьев
youtube.com/watch?v=GiyRQa0a-vM

Подробнее о первом выпуске: t.me/uxnotes/459

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

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

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

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

Лучше, если респондент использует своё устройство, поскольку каждый подстраивает скринридер под себя: скорость произношения, произносить или нет знаки препинания и так далее.

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

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

Эффективно, когда команда встречается с незрячим тестировщиком, вместе с ним тестирует интерфейс и на месте договаривается о том или ином решении.

https://medium.com/Valeria.kurmak/73845933b550

Юлия Кингсеп написала о методиках парного тестирования в UX-исследованиях.

1. Co-discovery. Респонденты не знакомы с системой. Получив задание, они начинают совместно решать задачу, по ходу обсуждая возможные решения и возникающие проблемы. Оба респондента открывают для себя систему впервые, но у каждого — своя ментальная модель и познавательная стратегия, и это даёт возможность увидеть реальность с новых сторон.

2. Teaching. Один из респондентов самостоятельно изучает интерфейс, а потом объясняет неопытному респонденту, как им пользоваться. Эти объяснения позволяют узнать, как он понял принципы взаимодействия с системой и что осталось непонятным.

Считается альтернативой методике Think-aloud (мысли вслух), но Teaching лучше:
— Объяснения дают больше полезной информации;
— Мысли вслух — непривычная задача для большинства людей;
— Респондент увереннее и спокойнее себя чувствует с похожим на себя неопытным пользователем.

3. Coaching. Из двух респондентов один является опытным пользователем системы, второй — новичком. Опытному респонденту надо объяснить новичку, как пользоваться системой таким образом, чтобы он мог быстро и легко её освоить.

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

Ограничения:
— Подходят только для тестирования первого опыта взаимодействия с системой;
— Сложно проводить удалённо;
— Никакого айтрекинга.

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

https://medium.com/Julia_Kingsep/10c1279b293

При отзуме на картах в «Яндекс Драйве» появляется «Зачем».

Нашёл Михаил Озорнин:
https://twitter.com/mikeozornin/status/1197149958190833664

Вадим Митякин написал о проектировщике в рамках продюсерского подхода к созданию цифровых продуктов.

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

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

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

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

Как состояться в профессии:
1. Насмотренность — знакомство с разными областями знаний;
2. Исследования — освоение выбранной области знаний;
3. Мастерство — использование своих знаний и создание новых областей знаний.

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

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

https://mityakin.ru/paranoid-method-book-04

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping.

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

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

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Редактор UX Movement Энтони написал о цветовом контрасте и доступности интерфейса по стандартам WCAG.

1. Требования WCAG не всегда оптимальны. Алгоритм оценки контраста занижает её для белого текста на ярком фоне (синем или оранжевом), хотя читать его легче чёрного текста.

2. Контраст текста не обязательно тянуть на уровень 7:1. Это полезно, если большая часть вашей аудитории — люди старше 70 лет с потерей зрения 20/80. Для определённого контента достижение уровня 7:1 невозможно вовсе.

3. Так как текст надо читать, его стандарты контрастности выше, чем у других компонентов интерфейса. У текста 4,5:1 против 3:1 у иконок.

4. Если у иконки есть доступная подпись (контраст 4,5:1), контраст самой иконки не важен. Также не важен цвет кнопки, если находящийся на кнопке текст доступен. Требование контрастности не распространяется на неактивные компоненты (например, отключённые кнопки).

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

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

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

https://ux.pub/mify-o-dostupnosti-tsvetovogo-kontrasta/

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