Личная продуктивность

Что думал в начале 2019:
- Энергичный сфокусированный человек всегда выиграет у уставшего и раздёрганного.
- Чтобы быть энергичным и сфокусированным, нужно качественно спать (http://t.me/desprod/80), правильно питаться (http://t.me/desprod/123), много двигаться (http://t.me/desprod/145), ограничивать приток входящей информации (http://t.me/desprod/270), медитировать (http://t.me/desprod/343).
- Вообще страшно интересно узнавать о том, как работает твой организм, откуда у тебя берётся энергия, и максимально использовать это знание.
- Некоторые ребята пытаются ещё усилить эффект с помощью фармакологии (http://t.me/desprod/153), но, на мой взгляд, это супер-опасно — всё равно, что ковыряться обычной отвёрткой в тончайшем часовом механизме. Мы слишком мало знаем о долгосрочных последствиях приёма всех этих препаратов.

Что думаю в начале 2020:
- Вся эта «физиологическая» продуктивность не является достаточным условием того, чтобы у тебя что-то путное получалось. И даже необходимым условием не является.
- Всё это — гигиена. Не медитировать — то же самое, что не чистить зубы.
- Гораздо важнее, на чём именно мы собираемся фокусировать свою энергию и зачем нам это.
- Можно сколько угодно высыпаться, правильно питаться и заниматься физкультурой, но если у тебя нет чёткого честного ответа на вопрос о том, зачем ты работаешь, то толку от всей твоей энергии никакого.
- Уставший раздёрганный человек с сильной внутренней мотивацией вполне может выиграть у энергичного и сфокусированного. Особенно если последний не понимает, зачем в это всё ввязался, и на самом-то деле ничего не хочет. Зато когда у человека есть настоящая причина, которая его вдохновляет, он даже невыспавшийся готов свернуть горы.
- Так что, кажется, настоящая продуктивность начинается с ответа самому себе на вопросы «что надо сделать» и «зачем». Но это уже тема для отдельного разговора.

Редактор 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/

Контекст пользователя

Контекст пользователя

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

Помимо задачи пользователя, важен еще и контекст, с которым он к вам приходит. Выдерживает ли интерфейс этот контекст? Способны ли мы правильно "встретить" человека и провести по сценарию?

Пример

- Собираем карточку товара. Кладем сюда фото, сюда описание, а сюда кнопку "Купить". - Представим, что запущена реклама с коммуникацей про скидку.
- Предусмотрели ли мы состояние карточки под это? Заложили ли состояние, когда на фотках появляется бейдж с жирным скидоном? Можем ли этим гибко управлять? Или каждый раз делаем релиз под очередную акцию?

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

Рекомендации

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

Увидел рекламу - считал сообщение/решение задачи - пришел с сообщением в интерфейс - решил задачу.

Практика

В своей работе мы часто используем сценарии пользователей. Вот реклама с такой коммуникацией, вот пользователь переходит на карточку товара, вот жмет кнопку "Купить". На первом этапе можно хоть из квадратов собрать, а потом уже дизайн под это рисовать.

Эта штука позволяет увидеть всю картину. Каждый шаг, мотивацию и целевое действие в конце. По итогу сборки сценариев всплывают штуки, про которые забыли. Думаете, шлифуете, выкатываете.

Итого

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

Принцип «Направляй, а не ругайся»

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

Если клиент не заполнил поле и жмёт на кнопку «далее» — направьте его: поставьте фокус на это поле, откройте клавиатуру. Можно написать аккуратное «Укажите» под полем ввода. Главное — не скатываться в нахально-безразличное «Обязательно для заполнения». Звучит, будто тётка на почте нахамила.

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

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

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

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

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

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

Если во время тестирования эксперименты будут независимыми, а выборка по крайней мере квазислучайной, то мы можем предположить, что при тестировании 5 пользователей мы обнаружим 85% ошибок, с которыми сталкиваются не менее 31% пользователей.

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

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

http://bit.ly/2UqfhOs

Хорошей практики пост

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