Открытый UX
1.3K subscribers
100 photos
4 videos
5 files
143 links
UX-дизайн, интерфейсы и исследования.

Чат канала: @open_ux_chat
Download Telegram
Интерфейс. Новые направления в проектировании компьютерных систем.
#Книги

Небольшой конспект книги Джефа Раскина, который более 30 лет занимался интерфейсами, работал в Apple и был инициатором разработки Macintosh. В 1987-м он выпустил свой настольный компьютер Canon Cat. По ходу повествования автор тщательно подбирает аргументы и подкрепляет выводы интересными примерами и исследованиями.

Ключевые мысли книги:
▸ Не все существующие подходы правильные и не все кажущиеся удобными решения на самом деле таковы.
▸ Интерфейс должен обеспечивать сохранность данных пользователя.
▸ Нельзя вынуждать пользователя производить лишние действия.
▸ Пользователю нужно обеспечивать возможность самому устанавливать ритм взаимодействия (не заставлять ждать, не подгонять).

Раскин указывает на две типичные ошибки проектировщиков:
▸ Кажется, что проще всего снабдить интерфейс пользовательскими настройками, но это не так. Изменения настроек нигде не документируются и о них можно просто забыть. Также пользователь получает внезапную лишнюю задачу, которая никак не связана с его рабочими задачами.
▸ Еще представляется, что раз успех интерфейса в его простоте, то необходимо непременно стремиться к сокращений количества кнопок (или других регуляторов). На самом деле это не всегда является хорошим решением.

Открытый UX
Открытый UX
Интерфейс. Новые направления в проектировании компьютерных систем. #Книги Небольшой конспект книги Джефа Раскина, который более 30 лет занимался интерфейсами, работал в Apple и был инициатором разработки Macintosh. В 1987-м он выпустил свой настольный компьютер…
Лишние проблемы интерфейса

Продолжение конспекта #Книги Джефа Раскина «Интерфейс. Новые направления в проектировании компьютерных систем»‎

Несколько важных вещей, которыми по мнению Раскина не следует пренебрегать:
▸ Бесполезные сокращения
Лаконичность в обозначении элемента хороша не всегда. Гораздо важнее сразу донести смысл, чем сэкономить место.

▸ Неуместные пиктограммы
Если иконка нуждается в подписи и разъяснении, то лучше сразу заменить её текстом.

▸ Не простота, а понятность
Если интерфейс уже не возможно упростить, но он все еще не понятен пользователю, стоит оставлять инструкции. Не нужно сразу вываливать на юзера весь «мануал по использованию». Лучше просто делать уместные и понятные подсказки по ходу взаимодействия в нужных местах.

▸ Безопасное удаление
Имея дело с интерфейсами, где предусмотрены действия «удалить» или «вырезать», пользователь должен быть уверен, что он случайно не произведет необратимого действия. Всегда должна существовать возможность отмены или альтернативный вариант хранения удаляемых данных.

▸ Простой вход
Вход в закрытую часть интерфейса нужно делать простым. Чаще всего достаточно использования пароля без логина. Также допустимы другие быстрые варианты: голосовая команда и пр.

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

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

Открытый UX
Сила привычки
Продолжение конспекта #Книги Джефа Раскина «Интерфейс. Новые направления в проектировании компьютерных систем»‎

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

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

Режим опять же в книге — состояние интерфейса при котором только что осуществленный жест интерпретируется по прежнему.
Простой пример — карманный фонарик. Он имеет два режима: вкл и выкл. Переход из одного режима в другой осуществляется после совершения очевидного жеста — нажатия на кнопку.

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

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

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

Открытый UX
Психбольница в руках пациентов
#Книги

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

Ключевая мысль книги:
Деловой человек либо владеет высокими технологиями, либо… скоро перестанет быть деловым человеком, потеряв свой бизнес. Слишком широко вошло в нашу жизнь IT. Если инфо-система неэффективно внедрена в бизнес, компания будет нести колоссальные убытки. Именно поэтому в аналитику и проектирование программного продукта стоит вкладывать гораздо больше времени и денег, чем в его последующее производство и внедрение.

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

Говоря об этом термине, автор упоминает о распространенных формулировках «проектирование интерфейса», «поведенческое проектирование» и «концептуальное проектирование». Все они кажутся Куперу недостаточно ёмкими.

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

Слагаемые успеха
Существует всего три слагаемых качества продукта в сфере IT:

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

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

Открытый UX
Вредные советы из #Книги Алана Купера "Психбольница в руках пациентов"

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

Открытый UX