Евген Эсану прочитал обновлённую версию «Не заставляйте меня думать» Стива Круга и сформулировал рекомендации, которые могут пригодиться даже опытным дизайнерам.

1. Люди не читают, а сканируют. Дробите текст, выделяйте ключевые слова.
2. Создавайте явную визуальную иерархию. Делайте заметнее более важные объекты, группируйте связанные.
3. Не изобретайте колесо. Придерживайтесь сложившихся сценариев взаимодействия. Предлагая новое решение, прикиньте, во сколько (времени и усилий) обойдётся его внедрение.
4. Убирайте инструкции, интерфейс должен быть понятен без них. Если без инструкций не обойтись, смотрите пункт 1.
5. Учитывайте, что люди не знают, как работает ваш продукт, и не хотят разбираться.
6. Людям не так уж важны едва уловимые детали и эффекты в ваших продуктах. Убедитесь, что пользовательский сценарий полностью проработан, и полируйте дизайн после этого.
7. Не путайте фокус-группы и юзабилити-тесты. Первое — обмен мнениями и групповое обсуждение (например, продукта). Второе — наблюдение за человеком, который использует продукт.
8. Помните, что люди не похожи на вас. Принимая решения, не концентрируйтесь только на личных ощущениях.
9. Учитесь задавать правильные вопросы.
10. Пользователь не должен думать «где я», «с чего мне начать», «куда делось …», «что здесь самое важное», «почему они так назвали это», «это реклама или часть сайта?». Это отвлекает его от более важных вопросов: «Зачем я здесь» и «Что мне надо сделать».

В переводной статье почему-то нет ссылки на оригинал и даже его названия, так что стоит сослаться здесь:
— Перевод: https://usabilitylab.ru/blog/10-melkih-oshibok-v-dizajne-kotorye-my-po-prezhnemu-sovershaem/
— Оригинал: https://uxplanet.org/1cd5f60bc708

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

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

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

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

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

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

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

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

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

https://designpub.ru/67ac0a28a732

Наталья Стурза, автор канала @UX_sturzaman, рассказала, когда продуктам полезны UX-исследования:

1. Проверить идею, не создавая продукта. Хотели запустить маркетплейс для пенсионеров. Исследование показало, что люди старше 60 лет спокойно пользуются обычными интернет-магазинами.

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

3. Улучшить то, что работает. Клиенты банка заполняли юридически значимое поле «Назначение платежа» всякой белибердой. Юзабилити-тесты показали, что люди считают поле второстепенным и заполняют только затем, чтобы кнопка платежа активировалась. В итоге в плейсхолдере поля показали пример, и таких ситуаций стало на 30% меньше.

4. Сравнить между собой конкурирующие продукты или отдельные фичи.

5. Понять, сколько потенциальные клиенты готовы платить.

6. Найти ошибку в интерфейсе.

Исследования не пригодятся:

1. Сервисам про фан вроде MSQRD и сервисам-витаминкам вроде приложений для медитации. У них сложно выделить пользовательскую потребность или проблему.

2. Любым проектам в ситуации «Мы хотим, чтобы вы пришли и сказали, как решить наши проблемы». В этом случае лучше обратиться к консалтерам.

https://vc.ru/design/86942

Про самоорганизацию

Про самоорганизацию

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

Что меняется в концепции 👇

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

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

В треугольнике "задачи, время, мой ресурс (эффективность)" я фиксировал задачи, а время растягивал.

Этот подход оказался неверным:
☹️ Волны успеваемости сменяются волнами апатии и прокрастинации.
☹️ Ощущение "я много работаю" позволяет чаще делать непроизводительные паузы-награды: соцсети и прочее.
☹️ Если растягиваешь время — меньше думаешь о производительности: она не в фокусе. Ну, посплю поменьше — зато, сделаю побольше.

В какой-то момент (не так и давно, на самом деле) я стал фиксировать не задачи, а время: у меня есть 8-9 часов на все рабочие задачи и свои инициативы. Успевай.

И тут началось самое интересное в самоорганизации:
🙂 Работаю над действительно важными задачами.
🙂 Острее ощущается ограничение времени: стал меньше отвлекаться на постороннее.
🙂 Делегирование и работа с подрядчиками заиграли новыми красками.
🙂 Думаешь больше о самоэффективности: больше мотивации точить пилу и выбирать максимально эффективные инструменты.
🙂 Не надо жертвовать важными нерабочими делами: семья, спорт, саморазвитие и т.п.
🙂 Появляются левел-апы и вызовы: а можно ли успеть всё не за 8-9, а за 6-7 часов?

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

У меня появляются большие вопросы к людям, которые: "я работаю по 12-16 часов в день" — как долго они так могут работать и почему они считают это поводом для гордости?

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

Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Итеративный процесс в дизайне и инженерном творчестве

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

Итеративный процесс работы в проекте может быть сложным если не учитывать нескольких факторов:
— Желаемый результат, финальная функциональность и потребности людей должны изначально описываться в четырех группах. Обязательные, измеряемые показатели, устанавливаются заказчиком.
— Возможные, измеряемые показатели, параметры успешности и критерии заказчика ограниченные максимальными возможностями разработчиков.
— Конкурентные, зависимые от возникающих обстоятельств в процессе разработки и прогнозируемые как потенциальные, измеряемые.
— Коллаборативные результаты, факторы синергического влияния на результат возможных в процессе разработки объединений компетенций, реакция на контекст изменений в потребностях людей и возникновений новых условий и инструментов разработки.
— Необходимо оберегать и сохранять промежуточные проектные разработки. Итеративный процесс не исключает возврат к прошлым шагам, решениям и условиям и пересмотру «проектной истории»
— Важно сохранять единый список критериев и стандартов требований ко всем этапам итераций в разработке, не меняя критерии, или при изменениях стараться заново проверить прошлые версии решений на соответствие новым стандартам и критериям.
— Надо понимать, что итеративный этап разработки может при перспективной идее показать неудовлетворительный результат, но по возможной причине качества реализации замысла. Стоит уметь оценивать идею отдельно от этапа реализации и видеть как измерять и сравнивать разные характеристики. Два прототипа, один ориентирован на проверку самой идеи и ее барьеров и ограничений. Второй прототип проверяет качество реализации выводов после активного тестирования первого прототипа, но используя технологии близкие реальному производству.
— Команда разработчиков привычно проверяет и выносит независимые суждения по эффективности решения, если есть желание пойти на компромисс, пожертвовать функциональностью в целях материальной экономии, то для этого нужны веские аргументы целесообразности и компенсации недостатков опорными действиями. Ограничиваем функциональность, значит увеличиваем режим обучения, возможно объединяем отдельные действия в функциональные блоки.
Итеративный процесс разработки чувствителен к данным и наблюдениям. Сама разработка может повлиять на сам внутренний процесс работ и на методы, как и на трансформацию первичных требований и технических заданий, основываясь на возникающем постепенно понимании потребностей и инструментов реализации этих потребностей, как и возникающих рисках и вызовах.

Например, «ОКБ Сухого» Информационно-управляющее поле кабины самолета СУ-35 / Т-50 было разработано в нескольких вариантах в виде тренажера, прототипа геометрии кабины и интерфейса управления с обратной связью в среде купола виртуальной реальности, через который пропустили несколько сотен курсантов с летных училищ с типичными заданиями.

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

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

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