Простой интерфейс

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

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

А вот как не обмануть:
https://antonz.ru/simple-ui/

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

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

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

Защита прошла!

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

Что ж, теперь можно обсудить, что ребята показали жюри, и чем эта защита отличалась от прошлых.

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

Теперь о самих проектах, точнее о тех, что зацепили.

Всех поразил проект Labyrinth Алины Русаковой (facebook.com/rusakova.alina) — приложение для горнолыжников и сноубордистов. Когда она выступала, и зал, и жюри были полностью поглощены, само собой, кто-то достал телефоны и снимал. И даже после защиты обсуждение проектов так или иначе заканчивалось её проектом. Если бы у нас были приз зрительских симпатий и признание выпускников, она бы унесла их оба.

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

А вот приложение для борьбы со словами–паразитами Tomato Word от Ани Васильевой (facebook.com/annvasiliska) однозначно мой фаворит. Все эти «эм», «и», «ну», «как бы», «собственно» и прочие — настоящая головная боль для тех, кто готовится к выступлению (Аня сама честно призналась, что была бы рада наличию такого приложения, когда готовилась к выступлению). Простое визуальное решение и платный режим со штрафом в 1₽ за каждое слово–паразит — это огонь.

Идём дальше. Кто бы мог подумать, что между кураторами и художниками нет чёткого канала коммуникации?! Оказывается, так и есть. Аня Пестич (facebook.com/anya.pestich) узнала, почему так происходит, и взялась решить эту проблему и свести их друг с другом в своём приложении re: art (жаль, не знаю, как и почему она докопалась до этой боли). Приятно, что она провела такой ресерч и смогла предложить решение проблем пользователей — именно так и должен работать дизайнер.

Ира Кухтерина (facebook.com/ira.kuhterina) нашла боль в том, что она сильно пала духом, пытаясь найти тему для своего проекта, и это сильно цепляет (год назад сам прошёл через такое же). Чтобы как-то с этим справиться, она создала Nevergiveapp (нейминг, кстати, огонь; у ребят на курсе с этим вообще хорошо) — приложение для поддержки и поднятия самооценки. Жюри очень высоко оценило степень проработки MVP, ведь она практически показала бета–версию, которую уже завтра можно протестировать на себе. Не могу сказать, что такое решение сработает (всё–таки эмоциональные состояния уникальны), но сам факт того, как много она сделала, впечатляет.

Остальные ребята тоже старались, и я мог бы продолжать и дальше, но у нас ограничение по времени (ba-dum-tss), поэтому ограничимся этим топ-4. Впереди у ребят второй семестр, где они будут работать в командах над проектами по брифам реальных заказчиков (даже самому интересно, что за проекты у них будут). Увидимся с ними и с вами уже в 2019 году!🎄

Немного о том, есть ли жизнь после британки

Как я говорил ранее, я уже больше трех месяцев работаю в hh.ru. За это время мы неплохо поработали и полностью изменили навигацию в приложении. Теперь там удобный таббар (ура). На протяжении нескольких месяцев мы отбирали разные варианты, спорили, тестировали. В итоге остановились на компромиссном решении, со своими плюсами и минусами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://bit.ly/2UqfhOs