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

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

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

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

Дмитрий Герасимов сделал выжимку из книги Яна Уайта «Редактируем дизайном».

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

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

Денис Золотарёв написал, как рассказывать в вебе истории, то есть как правильно подавать лонгриды, презентации товаров и прочие спецпроекты.

Надо ответить на вопросы:
1. Кто наша аудитория?
2. Какова цель проекта? Типы проектов: журналистика, реклама, PR и GR.
3. О чем и как мы хотим рассказать? С чего вообще люди захотят это смотреть? Возможные варианты ответа:
— Важная для аудитории тема, разобранная визуально;
— Наглядно оформленные интересные факты (тема, которая хорошо переводится в картинки);
— Хорошая журналистская история;
— Просто красивая история.
4. Как строить рассказ? Попробуйте рассказать историю собеседнику. В какие моменты вы захотите что-то нарисовать или найти видео в интернете?
5. В какую форму мы должны облечь нашу историю? Классические лонгриды, инфографика, иллюстрации, мемы и комиксы, фото и видео 360°, VR и AR, анимация и объясняющее видео, игры и чатботы.
6. Как доставить нашу историю пользователям? Где, как и когда публиковать?

В статье Дениса много ссылок на хорошие примеры.

Иван Дегтяренко сделал конспект книги Донны Личоу «The User’s Journey: Storymapping Products That People Love».

Книга рассказывает о сюжетных картах (Story maps), которые позволяют описать, как пользователи видят, используют и рекомендуют ваш продукт в виде сюжета, и сделать этот сюжет более вдохновляющим и привлекательным. Не путайте их с картами пользовательских историй в Agile-методологии (Agile user story mapping).

Дмитрий Ваницкий написал, как с помощью сторифреймов подружить исследования и прототипирование. И про другие артефакты, которые полезно сделать до вайрфреймов.

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

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

Чем абстрактнее, тем быстрее и дешевле вносить изменения. Вайрфреймы — далеко не отправная точка (максимум абстракции). Отправной точкой может быть простой текстовый рассказ о взаимодействии пользователя с продуктом (storyframe). Сторифреймы можно создавать ещё во время исследования.

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

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

Сторифреймы субъективны: они подойдут только для генерации удачного решения, но бесполезны в тестировании, так как каждый увидит в них своё. Если сторифрейм дополнить деталями, получится User’s journey map.

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

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

На готовых макетах можно провести эвристическое тестирование: 10 эвристик Якоба Нильсена или универсальные эвристики Бена Шнейдермана.

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

1. Для каждой нарисованной кнопки: что произойдёт, если нажать? Не обязательно должна быть прям картинка следующего состояния, но понадобится внятный ответ.

2. Для каждой кнопки «Закрыть», «Скрыть» и подобных: как снова открыть, показать?

3. Для каждой переменной величины: что, если значение будет отрицательным, нулём, единицей, в сто раз больше, в сто раз меньше, длиннее, короче? Что, если значение изменится в реальном времени?

4. Для каждого переменного числа элементов (список, матрица иконок и т.д.): что, если элементов будет ноль, один; в сто раз больше, чем нарисовано. Что, если число элементов изменится в реальном времени?

https://ilyabirman.ru/meanwhile/all/completeness-questions/

«Если бы я спросил людей, чего они хотят, они бы попросили лошадей побыстрее», — Генри Форд.

Вы наверняка слышали эту цитату, так как связаны с IT.

Музей Генри Форда провёл исследование и не нашёл подобной фразы в его письмах и статьях. Впервые она появилась в 2001 году в письме английскому журналу Marketing Week и, скорее всего, просто ему приписана.

Из книги Скотта Фаранелло Practical UX Design.

https://designpub.ru/дизайн-в-вакууме-adcdc0a039d2

Павел Шерер написал об особенностях проектирования стартапов, которые ещё не профинансированы так, чтобы топить офис деньгами.

1. Совмещение проектировщиком нескольких ролей: потребуется быть почти техническим директором (см. ниже), управлять проектом (в целом, хорошая практика) и знать его лучше всех остальных (документация быстро устаревает).

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

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

4. Понимание, чем отличаются разные лицензии: MIT, GPLv2, BSD, MPL CCA и т.п.

5. Масштабируемые решения: при создании дашборда надо учесть, что на нём могут выводиться не только 2−3 ключевых показателя, но и десяток второстепенных, о которых вы пока даже не знаете. Если вы создаете список пользователей для модераторов, нужно быть готовым, что за два дня их станет больше в 40 раз.

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

7. Планирование аналитики заранее: не продумаете аналитику сначала — потом будете терять какие-то показатели, потому что не готова серверная часть или связка попросту не реализуема.

8. Минимальные вложения в админку: должна быть только та функциональность, которая нужна на старте. Всю аналитику выносите вовне.

9. Главное: не перфекционируйте.

По законодательству РФ интернет-магазины не имеют права устанавливать дополнительные комиссии при оплате товара банковской картой.

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

Например, магазин на скриншоте защищён от Роспотребнадзора:
— Нигде не сказано, что цена при оплате картой больше из-за комиссии;
— В подсказке к цене на жёлтой подложке написано, что это цена со скидкой от базовой цены.

Кент Салливан написал о разработке дизайна Windows 95: использование в качестве основы Windows 3.1, итеративный подход, прототипы на Visual Basic, пользовательское тестирование (новички, средние и продвинутые), фиксирование проблем и решений в багтрекере, ранжирование проблем.

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

Золтан Коллин написал о трении в интерфейсе, как его уменьшить и в каких случаях этого лучше не делать.

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

1. Замедлиться, чтобы избежать ошибки:
— Подтверждение действий с серьезными последствиями;
— Предотвращение возможных ошибок. Gmail спрашивает, действительно ли пользователь хочет отправить письмо без прикреплённых файлов, когда он упоминал их в тексте письма;
— Задержка выполнения действий, которые нельзя отменить.

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

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

4. Обучение пользователей и стимулирование определённого поведения:
— Slack предупреждает перед отправкой уведомления группе;
— На кухне Google конфеты размещены в непрозрачных контейнерах, а фрукты в прозрачных.

5. Управление продуктом:
— Продажа. Всплывающие окна с акциями и предложением подписаться;
— Фильтрация клиентов. Сложный для родителей интерфейс Snapchat;
— Создание ценности. Рекламные вставки на бесплатном тарифе Spotify.

In English.

Давид Теодореску написал о манипуляциях с помощью дефицита.

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

Формы дефицита:
1. По времени: Lightning Deals на Амазоне;
2. По количеству товаров: поиск номеров на Booking, бронь билетов на Ryan Air;
3. Ограниченный доступ: подписка на Медиуме, присоединение к Tinder Select;

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

In English.

3 доклада с Open Epic Day, проведённого школой Epic Skills 10 марта:

1. Креативные методики против вдохновения — Никита Прядко из «Золотого сечения»: https://youtu.be/i3j3hyGeh-g

2. Тёмная и светлая сторона дизайнера интерфейсов — Анастасия Атюнина из Heads and Hands: https://youtu.be/MgFW6Sbp548

3. Как говорить о дизайне с заказчиком — Даша Почекуева из Kelnik: https://youtu.be/EkRmmosHj-0

Элеана Гожка написала об использовании принципов гештальта в дизайне интерфейсов.

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

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

In English.

Настя Травкина написала о дофаминовой петле.

В 2001 году стэнфордский ученый Брайан Кнутсон доказал, что дофамин отвечает именно за предвкушение удовольствия. Это способ мотивации и поощрения эволюционно верных действий, способствующих выживанию. Дофамин использует тягу к удовольствию как морковку перед мордой осла, чтобы заставить человека совершить правильные действия. Он вынуждает нас искать удовольствие — но не испытывать его. Работой именно этого гормона и обусловлены психологические болезни общества потребления.

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

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

Джим Росс написал о распространённых ошибках в прототипировании и как их избежать.

1. Приступать к созданию прототипов слишком быстро. Надо начать с бумажных набросков и поиска наиболее подходящей концепции;
2. Работать без чёткого плана. Надо определить, какие страницы и функции должны войти в прототип, и заниматься только ими;
3. Ошибаться с уровнем точности прототипа. Надо понять, какую задачу он решает и какие есть временные ограничения на его создание;
4. Включать в прототип слишком много всего. Надо показать основные страницы и функции, а на второстепенные переключаться только после получения обратной связи по основным;
5. Не объяснять клиентам и пользователям, что за прототип перед ними. Надо объяснять в начале и повторять перед каждым ревью. И проверяйте, что все ссылки в прототипе ведут туда, куда надо;
6. Не готовить инструкцию по навигации в прототипе. Для разработчиков стоит сделать отдельный документ с состояниями экранов и принципами взаимодействия, чтобы им было проще разобраться, как всё работает.

In English. Копия перевода в Вебархиве.

Митя Гизатов искал работу дизайнером, за 4 месяца прошёл более 30 собеседований и поделился впечатлениями.

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

Например:
— Стоит откликаться на вакансии, даже если не соответствуете требованиям на 100%;
— Знакомиться (проводить первое интервью в серии) лучше не лично, а по видеосвязи;
— Если тестовое задание обязательно, не надо спрашивать об отношении соискателя к тестовым заданиям. Никто их не любит делать;
— Обратная связь после выполнения тестового — обязательный пункт.

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

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

Видео.