Просмотр исходного текста страницы Блог:ТС-Магазин/О конференции ProfsoUX—2015

[[Image:Logo_profsoux.45a753e62c3f.png|thumb|230px|Конференция по юзабилити и проектированию взаимодействия «ProfsoUX—2015»]]

25 апреля в Санкт-Петербурге уже в четвёртый раз прошла конференция [http://2015.profsoux.ru/ ProfsoUX—2015]. Конференция вышла неплохая, несоизмеримо лучше, чем 
[[Blog:ТС-Магазин/О конференции ProfsoUX—2014|в предыдущем, 2014 году]] и сравнимо с тем, как это было [[Blog:ТС-Магазин/О конференции ProfsoUX—2013|в 2013-м]]. 

В этом году организаторы конференции выпустили мобильное приложение. Это, вероятно, странно, но удобно. Простой программы, распечатанной на бумажке, обычно недостаточно, хочется почитать аннотации к докладам. В приложении же это всё есть. Туда же встроили поток твитов с хештегом [http://twitter.com/search?q=%23Profsoux #profsoux] и возможность задавать докладчику вопросы.

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

Видеосъёмкой на конференции по-прежнему занимается Стас Фомин. Сейчас он готовит к публикации видеозаписи докладов (несколько уже готовы), остальные обещает опубликовать в течение двух недель. Их все можно будет найти [http://talks.rosalab.com/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:ProfsoUX-2015 здесь]. Напомню, что все доклады идут по двадцать минут, так что просмотреть видеозапись можно совсем быстро.

== Проектирование как технология и искусство ==

; Докладчик : Анна Галахова ([http://uxify.it/ Uxify.it])

; Презентация : [http://www.slideshare.net/ProfsoUX/profsoux-agalakhovaverifiedfinal тыц]

; Видео : пока не опубликовано.

; Статья от докладчика : [http://2015.profsoux.ru/media/presentations/2014/design-as-technology-and-art.docx тыц]

; В двух словах : как-то немного ни о чём.

----

Самый скучный доклад, откровенно выбивается на общем фоне в худшую сторону. 

Первая половина про общение:
* UX-специалисту не достаточно знать технологию и паттерны работы, нужна ещё коммуникация. Из-за недостаточных коммуникаций (или слишком многозвенных коммуникаций) происходят недопонимания, и все расстраиваются.
* Нужно добавлять общения напрямую (избегать посредников). Учиться слушать и слышать. Важное может всплывать между строк.
* Немного мешает тезис «Если вам не хватает информации, ни в коем случае не спрашивайте клиента — вы же проектировщик и должны сами всё знать».

Вторая — про выгорание. Про то, что специалист перестаёт получать удовольствие от работы, воспринимает её как рутину, а заказчики просят «какую-то ерунду». Докладчик советует получать удовольствие от процесса и находить мотивацию. Для этого нужно привносить творчество в работу, избегать излишнего перфекционизма, работы над слишком большим числом задач одновременно, учиться управлять своим временем.

== Особенности проектирования UI крупных профессиональных систем ==

; Докладчик : Александр Овчаренко ([http://www.electronxray.com/ НИПК «Электрон»])

; Презентация : [http://www.slideshare.net/ProfsoUX/ui-47503866 тыц]

; Видео : [http://talks.rosalab.com/%D0%9E%D1%81%D0%BE%D0%B1%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_UI_%D0%BA%D1%80%D1%83%D0%BF%D0%BD%D1%8B%D1%85_%D0%BF%D1%80%D0%BE%D1%84%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_(%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80_%D0%9E%D0%B2%D1%87%D0%B0%D1%80%D0%B5%D0%BD%D0%BA%D0%BE,_ProfsoUX-2015) тыц]

; В двух словах : об UX-проектировании систем наподобие рентгеновских аппаратов или судовых систем.

----

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

Определение профессиональным системам докладчик дал такое (на правах кандидата): системы, используемые для выполнения задач в сложных предметных областях. Под это определение попадают, например, Photoshop, AutoCAD и среды разработки.

'''Особенность 1'''. Высокая сложность предметной области. Чтобы к этому подступиться, докладчик предлагает начинать с разработки концептуального видения, которое соответствует модели пользователя. Если делать сразу интерфейсы, то скорее всего за деревьями не увидишь леса. Нельзя считать, что известны все сценарии использования системы, так как предметная область слишком сложная.

В качестве примера была приведена концептуальная модель управления рентгеновского аппарата: 
* Обычный монитор был предназначен для CRM-деятельности, завести нового пациента и т. п. Для медицинских целей только медицинский монитор. 
* Пульт управления имеет как джойстики, так и сенсорные органы управления. Джойстики должны управлять физическими характеристиками аппарата — координатами в пространстве, поворотами и т. п. Сенсорные органы предназначены для менее осязаемых характеристик — разрешения камеры, вид съёмки и т. п.

На вопрос о том, не рухнет ли концептуальная модель, когда дело дойдёт до погружения в детали, докладчик ответил, что рецепт в том, чтобы хорошо со всеми пообщаться, расспросить о недостатках текущей системы.

'''Особенность 2'''. Разнообразные пользователи. Тезис «А, бабушки, ну их нафиг», который можно слышать от некоторых проектировщиков, совершенно неприменим для профессиональных систем. С одной стороны, есть пользователи с негативной мотивацией и даже такие, которые ненавидят систему (и, возможно, работу тоже недолюбливают). С другой стороны, есть лаборанты, которые умеют гораздо больше, чем должны уметь и даже делают часть работы за врачей. Нужно учитывать и тех, и других. В случае с немотивированными пользователями — нужно просто предоставить им возможность делать свою работу и не слишком это усложнять.

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

'''Особенность 3'''. Специфичные контексты использования. Тут привели пример о том, как предполагали ввод каких-то показаний в машинном отделении корабля в ноутбук. Когда попали в жаркое, грязное, тесное и шумное машинное отделение, поняли, что с ноутбуком там не развернёшься и предложили реализовать это на планшете.

В общем случае, предлагается выходить за пределы «мышки и экрана», использовать штрихкоды, RFID-метки и т. п. Для программно-аппаратного комплекса это всё допустимо.

'''Особенность 4'''. Эффективность превыше всего. Если пользователь постоянно использует систему, важнее, чтобы он мог быстро и эффективно делать свою работу. Понятность и юзабельность интерфейсов уходит на второй план. Никто не требует от кабины самолёта, чтобы она была понятной.

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

Также требуется контроль за мелкими ошибками. Проблема в том, что мелкие ошибки могут не замечать. Но несколько мелких ошибок могут сложиться в цепочку, которая приведёт к серьёзным последствиям<ref>Действительно, если почитать, например, разборы железнодорожных происшествий, то почти всегда так и бывает.</ref>.

Финальный тезис: профсистемы — это инструменты. Спроектировать новый хороший инструмент невозможно, если не проектировать сами способы решения задачи, для которых инструмент используется<ref>Хотя на мой взгляд тезис применим не только к профсистемам.</ref>.

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

== Семь ошибок модератора в юзабилити-тестировании ==

; Докладчик : Дарья Куликова ([http://usethics.ru/ Usethics])

; Презентация : [http://www.slideshare.net/ProfsoUX/newverified тыц]

; Видео : пока не опубликовано.

; В двух словах : смешные и очень круто нарисованные комиксы про то, как не надо делать на юзабилити-тестировании

----

Докладчик — руководитель проекта по разработке нового интерфейса для нашего приложения РМ Лайт, мы тут недавно [http://wiki.office.custis.ru/wiki/index.php/%D0%91%D0%BB%D0%BE%D0%B3:%D0%A2%D0%A1-%D0%9C%D0%B0%D0%B3%D0%B0%D0%B7%D0%B8%D0%BD/%D0%9E_%D0%BD%D0%BE%D0%B2%D0%BE%D0%BC_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%B5_%D0%A0%D0%9C_%D0%9B%D0%B0%D0%B9%D1%82#.D0.9F.D1.80.D0.BE.D1.82.D0.BE.D1.82.D0.B8.D0.BF_.D0.BE.D1.82_Usethics писали] об этом. Доклад был хорош, а презентация с комиксами вообще прекрасна.

'''Гиперактивное слушание'''

<pre>
 — И тут я нажимаю сюда-а-а...
 — Конечно-конечно! Нажимайте. Нажали? А сейчас? И-и?
</pre>
Как вариант, модератор может просто угукать и кивать, и это всё равно портит релевантность, так как респондент чувствует поддержку.

Нужно вести себя как робот:
<pre>
 — Я нажимаю, но ничего не происходит! Почему, ПОЧЕМУ?!
 — ...
</pre>

Иногда совсем уж отмалчиваться не получается, на этот случай лучше задавать вопросы:
* Как вы сами думаете?
* Где бы вы стали искать?
* Что сейчас происходит?
 
'''Закрытые вопросы'''

<pre>
 — Вам всё понятно на этой странице?
 — Нам всё понятно на этой странице.
</pre>
Закрытые (общие) вопросы склоняют респондента к тому, чтобы, не приходя в сознание, эхом повторить фразу из вопроса, заменив интонацию на утвердительную. Если закрытый вопрос всё же был задан, то можно попробовать выкрутиться:
<pre>
 — Вы нашли всё, что вам нужно?
 — Нашёл всё что, мне нужно.
 — А расскажите-ка, что вам нужно?
</pre>

'''Параллельная реальность'''

Респондент смотрит на сайт, в котором есть два последовательных экрана с выбором типа оплаты (наличные или карта). Его задача — оплатить любым способом. Но с этими экранами он путается и платит картой, хотя собирался расплатиться наличными. Более того, он думает, что расплатился наличными.
<pre>
 — Всё, я оплатил... (имеет в виду наличные)
 — Как вам этот способ? (имеет в виду карту)
</pre>

Модератору следует убедиться, что его видение ситуации совпадает с видением респондента. Пример из жизни:
<pre>
 — А как вы это понимаете?
 — Что «это»?
 — То, что вы видите.
 — Но я ничего не вижу.
</pre>

'''Новая реальность'''

<pre>
 — Итак, вы нажали сюда, потому что подумали, что спишется комиссия, но потом заметили <...>
 — Д-да...
</pre>
Респондент соглашается с модератором вместо того, чтобы сказать, о чём думает сам. Как правило, проблемные фразы начинаются со слов «То есть», «А правильно ли я понимаю» и т. п. Чтобы убедиться в своей гипотезе, нужно задать правильный вопрос, а не озвучивать саму гипотезу.

'''Ускоренный модератор'''

Респондент в какой-то момент видит на интерфейсе окошко, в котором написано, что ему следует отправить SMS, чтобы завершить платёж. Он, особо не вчитавшись, тянется к кнопке «Закрыть». Модератор встревает: «Что это за экран, как вы понимаете?». Респондент начинает читать и понимает, что должен отправить SMS. Однако это свидетельствует о том, что реальные пользователи SMS отправлять не будут.

Модератору не следует торопить респондента.

'''Долгий-долгий тест'''

<pre>
— Я прочитал условия, но не знаю, соглашаться с ними или нет... Нужно перечитать.
— ...
</pre>

Здесь не всегда что-то можно сделать, для некоторых респондентов это просто такая скорость существования. Тем не менее имеет смысл важные задания помещать в начало сценария и заранее сообщать респонденту план. Если он будет знать, что за час необходимо сделать 100 заданий, он не будет застревать слишком долго на каждом.

'''Профессиональная лексика'''

<pre>
— Как вы относитесь к идее, что сервисы раскрыты по умолчанию?
— ...
</pre>
<pre>
— Почему вы не перешли по хлебным крошкам?
— ...
</pre>
<pre>
— Нажимали ли вы на аккордеон?
— ...
</pre>

Следует избегать таких вопросов. Кроме того, следует избегать канцеляризмов. Вместо «Осуществляете операции в интернет-банке» просто «оплачиваете мобильный».

== Не смотря на экран ==

; Докладчик : Виктор Иванов

; Презентация : [http://www.slideshare.net/ProfsoUX/profsoux-new тыц]

; Видео : пока не опубликовано.

; В двух словах : кул-стори про разработку терминала самообслуживания для универсамов.

----

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

Такие терминалы внедряются в универсамах «Spar», «Лента», «Азбука вкуса», «О'Кей» (в Москве, я так понял, только в «Азбуке вкуса», остальное в Петербурге). Любопытно кстати, что сами интерфейсы разрабатывал уже упоминавшийся Usethics.

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

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

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

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

В итоге терминал самообслуживания привлекает внимание покупателя следующими способами:

'''Изображения'''. В этом месте докладчик немного ушёл в лирическое отступление и показал эксперимент с [http://ru.wikipedia.org/wiki/Тахистоскоп тахистоскопом] — устройством, которое проецирует изображение в течение коротких промежутков времени, например, 100 или 40 мс. Эксперименты показывают, что испытуемый в состоянии понять смысл картинки за эти 100, 40 или даже 10 мс. А следовательно, по мысли докладчика, если нарисовать хорошую картинку-подсказку, то покупатель будет правильно понимать её после одного лишь мимолётного взгляда.

Так что они попытались нарисовать хорошие картинки (не фотографии, которые перенасыщены деталями). Сразу, тем не менее, получилось не все. Так на юзабилити-тестировании, когда терминал просил покупателя провести через считыватель, 40% участников пытались провести карту через терминал, используемый для оплаты банковскими картами<ref>Объединять эти считыватели в одном неправильно из соображений безопасности оплаты по платёжным картам.</ref>. В этом месте им помогло нарисовать на мониторе большую стрелку, которая указывала на нужный считыватель.

'''Выскакивание того, что значимо'''. Здесь тоже не обошлось без теоретического обоснования. Докладчик привёл два слайда. Один из них был заполнено беспорядочно расположенными буквами O, среди которых была одна буква Q. Слайд демонстрирует, что буква Q ищется очень быстро. На следующем же слайде было всё наоборот — много букв Q и среди них одна буква O. И там её найти в разы дольше.

Практический вывод — выделять самое важное. На картинках минимум деталей, контекст обесцвечен, самое важное выделено цветом. Примеры см. в презентации (базовое оформление от Usethics и версия для «Азбуки вкуса», которая приведена в соответствие с их правилами фирменного стиля), листы 25 и 26.

'''Звук при ошибках'''. Несмотря на приведённые выше соображения против голосовых подсказок иногда без звукового оповещения не обойтись. На юзабилити-тестировании был поставлен такой эксперимент — участник покупал бутылку воды и макароны. Но из бутылки предварительно вылили часть воды. Покупатель сканирует воду (при этом монитор попадает в поле зрения, но там всё в порядке), затем откладывает его на стол для покупок (он же весы) и тут терминал понимает, что вес неправильный. Показывает ошибку. Но покупатель, отложив бутылку, сразу тянется за макаронами. Отсканировав макароны, он снова бросает мимолётный взгляд на монитор и видит, что там ошибка. Затем покупатель начинает беспомощно крутить пачку макарон в руке и пытаться сканировать их повторно, полагая, что проблема в них (в презентации всё это демонстрируется видеозаписью с показаниями eye-tracking).

Поэтому в терминале всё-таки сделали звуковой сигнал об ошибке. Более общий вывод: обратную связь об ошибках нужно давать немедленно.

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

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

== Как добывать правду из пользователя и сок из менеджера ==

; Докладчик : Михаил Фролов ([http://fotostrana.ru/ Фотострана])

; Презентация : [http://www.slideshare.net/ProfsoUX/ss-47503511 тыц]

; Видео : [http://talks.rosalab.com/%D0%9A%D0%B0%D0%BA_%D0%B4%D0%BE%D0%B1%D1%8B%D0%B2%D0%B0%D1%82%D1%8C_%D0%BF%D1%80%D0%B0%D0%B2%D0%B4%D1%83_%D0%B8%D0%B7_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F_%D0%B8_%D1%81%D0%BE%D0%BA_%D0%B8%D0%B7_%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%B5%D1%80%D0%B0_(%D0%9C%D0%B8%D1%85%D0%B0%D0%B8%D0%BB_%D0%A4%D1%80%D0%BE%D0%BB%D0%BE%D0%B2,_ProfsoUX-2015) тыц]

; В двух словах : О том, как UX-менеджер в «Фотостране» заставляет менеджеров проектов исправлять UX-дефекты

----

Эффектный доклад, но несколько специфичный — о сложностях UX-менеджера, который сообщает о проблемах менеджерам проектов. Те в ответ охают, но исправлять не спешат. Поэтому кратко:
* Нужно правильно подавать обоснования проблем. Вместо восьми часов видео ссылка на конкретный таймстамп со скриншотом и фразой-заманухой («Сбил пальцы в кровь на десятой минуте», « — Я чувствую себя тупой!»).
* Детали и конкретика. Без фраз типа «Поведение системы не соответствовало ожиданиям пользователя». 
* Показывать и положительные эмоции — смеющаяся девушка, вот это всё. В начале презентации у докладчика кстати тоже был слайд с девушкой, вероятно по схожим соображениям. Из зала последовал возмущённый голос: «А можно было разрешения спросить, прежде чем включать мою фотографию в презентацию?».
* Индивидуальный подход к менеджерам, которые динамят исправления (в презентации скриншот переписки со стихами от докладчика и ответным умилением от менеджера проекта).
* Статистика в UX-блоге о том, кто ведёт себя хорошо и исправляет дефекты интерфейса, а кто нет.
* Напоследок чуть-чуть упомянуто о группах на «ВКонтакте», где можно искать респондентов для юзабилити-тестирований. Там люди в теме, привыкли что им могут платить деньги за такие вещи и не отвечают на приглашения фразами «фу, бордель!».

== Когда одного респондента достаточно? ==

; Докладчик : Алексей Бакушин ([http://www.1c.ru/ 1С])

; Презентация : [http://www.slideshare.net/ProfsoUX/bakoushinverified-47504760 тыц]

; Видео : пока не опубликовано.

; В двух словах : Чтобы понять, что яйцо тухлое, не обязательно пробовать его всемером.

----

Принято считать, что для грамотного юзабилити-тестирования требуется минимум пять респондентов. На практике, в компании 1С такой подход вылился в то, что юзабилити-тестирование проводят в конце цикла разработки, находят дефекты, времени на их исправление не остаётся, поэтому они так и не исправляются<ref>По поводу компании 1С из зала кто-то спросил, как там вообще дела с интерфейсами. Спрашивающий, по его словам, в последний раз сталкивался с 1С несколько лет назад и тогда интерфейсы были «не очень». Докладчик ответил обтекаемо: «Мы понимаем важность этого и мы стараемся».</ref>.

Предлагается делать тестирование по ходу разработки, но не набирать сразу пятерых респондентов, а начать с одного. Исследования учат нас, что один респондент вскрывает 35% проблем, а пять — 85%, однако даже в тестировании на одном респонденте всё равно есть польза. Во-первых, обозначаются очевидные проблемы. Во-вторых, одна треть обычных проблем. Под очевидными проблемами докладчик понимает вот что:
* Очевидно, что это проблема.
* Очевидно, что она будет массовой (важной, позорной).
* Очевидно, как её устранить.

Пример очевидной проблемы: сделана новая функциональность отправки чего-то там по электронной почте. Респондент (единственный) на тестировании не справился с задачей, потому что не нашёл кнопку. В итоге кнопку сразу переносят на видное место, и тестирование можно повторять. Таким образом, всплывает ещё одно преимущество, тестирование по ходу разработки. Эдакий Agile. Решение проблемы тестируется уже на следующих респондентах. Покрытие юзабилити-тестирования увеличивается. Ну и в случае с 1С есть ещё одно важное преимущество — проблемы решаются, и на них не забивают.

Похожий метод предложила Microsoft, они его называют [http://en.wikipedia.org/wiki/RITE_Method RITE].

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

== Хорошо ли русскому то же, что и немцу? ==

; Докладчик : Анастасия Режепп ([http://www.dataart.com/ DataArt])

; Презентация : [http://www.slideshare.net/ProfsoUX/presentation2404verified тыц]

; Видео : пока не опубликовано.

; В двух словах : О любопытных критериях различия культур и о том, что в разных культурах должны быть разные интерфейсы

----

Докладчик начала с пары любопытных примеров.

Первый пример — скриншоты [http://www.rakuten.com/ международной] и [http://www.rakuten.co.jp/ японской] версий какого-то японского интернет-магазина. Международная выглядит прилично, а японская на наш глаз как минимум выглядит перегруженной. При этом здесь не обвинить сайт в том, что он устарел — международная версия очень даже ничего. Докладчик обосновывает это различие тем, что на Западе низкоконтекстуальная культура, а в Японии — высоконтекстуальная.

Приведу признаки японских сайтов с [http://randomwire.com/why-japanese-web-design-is-so-different/ ссылки], предоставленной докладчиком:
* Плотно сжатый текст.
* Маленькие картинки скверного качества
* Колонок больше, чем можно посчитать
* Яркие ядовитые цвета и мигающие баннеры
* Злоупотребление использованием устаревающих технологий, например, Flash.

Следующий пример — [http://www.kfc.co.at/ австрийский] и [http://www.kfc.dk/ датский] сайты KFC. Различие между ними докладчик объясняет большим различием индексом маскулинности — в Австрии 79, в Дании — 16. Поэтому в датской версии на заднем фоне ложка-поварёшка.

Индекс маскулинности — один из индексов по классификации Гирта Хофстеде. Другие критерии в классификации — дистанция власти, индивидуализм, избегание неопределённости, стратегическое мышление и потакание слабостям.

Различие в критерии избегания неопределённости было продемонстрировано [http://www.ikea.com/fr/fr/ французской] и [http://www.ikea.com/sg/en/ сингапурской] версиями сайта IKEA (хотя IKEA по словам докладчика не очень практикует различные интерфейсы для разных стран). В Сингапуре очень низкий индекс избегания неопределённости (8), поэтому сингапурская версия более лаконична и воздушна. Во Франции значение этого же индекса 79 и сайт гораздо более заполнен (для более полного впечатления см. скриншот в презентации).

Посравнивать индексы для разных стран можно на [http://geert-hofstede.com/countries.html сайте Гирта Хофстеде].

Следующий пример — сервисы такси. Сравнивается строгий, почти чёрно-белый интерфейс Uber (для США) и интерфейс какого-то его популярного аналога из Колумбии. Колумбийский сервис при прибытии такси к пассажиру проигрывает песенку и у водителя, и у пассажира. Так, по песенке они могут видимо друг друга найти. Так что видимо заказ такси в Колумбии похож на сцену из мюзикла. Uber выходит и на колумбийский рынок, но, по мысли докладчика, его строгий интерфейс может не выдержать конкуренции с музыкальным соперником.

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

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

Там же была приведена таблица перевода:
* Если англичанин говорит «Да», это значит «Может быть».
* Если англичанин говорит «Может быть», то это значит «Нет».
* Если англичанин говорит «Нет», то это не англичанин.

Для шведов была похожая табличка, но наоборот. Ещё докладчик рассказала, что на переговорах с теми же англичанами всегда важно вначале поддержать Small Talk — ничего не значащий разговор о погоде или пробках. Если его опустить, то у англичан будет такое же ощущение, как и у нас, когда кто-то придёт на совещание и, не поздоровавшись и не представившись, начнёт говорить по делу.

Для сверки текстов в пользовательском интерфейсе обязательно нужен носитель языка. Он же желателен для корректировки текстов, отправляемых клиенту, даже если их авторы владеют английским языком (он всё равно найдёт проблемы).

Из зала задали вопрос, как бороться с английским Yes. Ответили, что нужно уточнять всё по пять раз. С американцами (про них тоже было вопрос) при этом гораздо проще, они гораздо прямолинейнее. Хотя какой-то рудимент от этой английской культуры есть и у них: «Всё очень круто, но вот, что нужно переделать» и дальше перечисление, после которого становится ясно, что переделать нужно всё. Ещё был интересный вопрос о том, как идёт в мире глобализация и можно ли будет в будущем перестать учитывать культурные контексты. Докладчик ответила, что в целом конечно говорить сложно, но вот например Аргентина очень сильно впитывает в себя американскую культуру, поэтому интерфейсы для Аргентины можно проектировать не так, как для её соседей. Эдакий пример глобализации.

== Как не испортить прототип? ==

; Докладчик : Никита Гарейшин ([http://www.intermedia.net/ intermedia.net])

; Презентация : [http://www.slideshare.net/ProfsoUX/kak-neisportitprototipprofsoux2015gareyshinverified тыц]

; Видео : пока не опубликовано.

; В двух словах : О том, что жёсткое разделение обязанностей между UX-проектировщиком и UI-дизайнером — не всегда хорошо

----

Принято считать, что UX-специалисты — это те, кто думают, а UI — те, кто рисует и не думает. По мысли докладчика это плохая идея. Если UX-специалист внезапно заболел или у него не хватило времени подумать, то UI не должен подвести.
* UI-дизайнеру следует знать логику и следовать ей. Не стоить что-то рисовать, если не понимаешь смысл (скриншот с примером, где вместо вкладок нарисована иерархия).
* Нужно улучшать восприятие интерфейса.
* И нужно быть инженером: следить за сеткой и за тем, чтобы psd-файл был чистым<ref>Я не знаю, что это значит.</ref>.

== Как люди ищут информацию ==

; Докладчик : Никита Ефимов ([http://selectel.ru/ Селектел])

; Презентация : пока не опубликована

; Видео : [http://talks.rosalab.com/%D0%9A%D0%B0%D0%BA_%D0%BB%D1%8E%D0%B4%D0%B8_%D0%B8%D1%89%D1%83%D1%82_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8E_%28%D0%9D%D0%B8%D0%BA%D0%B8%D1%82%D0%B0_%D0%95%D1%84%D0%B8%D0%BC%D0%BE%D0%B2,_ProfsoUX-2015%29 тыц]

; В двух словах : о новом подходе к использованию персон в UX-проектировании. Немного непонятно с точки зрения практики.

----

Есть в UX такой метод — построение персон. Мы придумываем нескольких характерных пользователей приложения, у каждого из которых есть свои цели<ref>Более подробно об этом рассказывалось на [[Blog:ТС-Магазин/О конференции ProfsoUX—2013#Взаимодействие пользователя и системы. Методики описания и визуализации|ProfsoUX—2013]].</ref>. Но некоторые UX-проектировщики забывают о том, что каждая черта персоны должна быть подтверждена исследованиями, вместо этого «упарываются» и начинают придумывать цвет глаз или имя собачки.

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

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

Уже какое-то время ведутся исследования на тему того, как люди ищут информацию. В 1977 г. появилась «Классическая модель», которая, впрочем, по словам докладчика не внесла никакой ясности. В 1995 г. появилась какая-то модифицированная модель. В ней уже появляются тезисы о том, что поиск нелинеен и что то, что мы находим, влияет на то, что и как мы ищем.

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

Ещё одна модель поиска вводит две входные точки для запуска поиска — «Осознание потребности» (хочу айфон) или «Получение информации» (зазвенел телефон в кармане). Эта же модель вводит конечную фазу — «Анализ и интерпретация результатов». Далее добавляется тезис о том, что процесс может быть итеративным (зацикленным).

Для нас важно то, что люди ищут информацию по-разному. В самом простом случае один человек говорит, что хочет «айфон 6 плюс, 32 Гб оперативной памяти, чёрный», другой — что хочет «новенький Андроид, что-нибудь помощнее, чтобы держал долго», а третий хочет купить подарок другу, но совсем не знает пока, что тому нужно. Это всё формализуется режимами поиска. В разных теориях вводится от 4 до 10 режимов поиска, докладчику наиболее симпатична теория с девятью режимами, разбитых на три блока:
* Поиск
** 1. Обнаружение
** 2. Подтверждение
** 3. Мониторинг
* Изучение
** 4. Сравнение
** 5. Понимание
** 6. Исследование
* Принятие решения
** 7. Анализ
** 8. Оценивание
** 9. Обобщение

Кроме того, авторы этой теории выявили возможные связи между этими режимами:

<graph>
 digraph G{ 
  rankdir=LR;
  Подтверждение[shape="rectangle"];
  Мониторинг[shape="rectangle"];
  Сравнение[shape="rectangle"];
  Понимание[shape="rectangle"];
  Исследование[shape="rectangle"];
  Анализ1[shape="rectangle", label="Анализ"];
  Анализ2[shape="rectangle", label="Анализ"];
  Оценивание[shape="rectangle"];
  Обобщение[shape="rectangle"];
 
  Анализ1->Подтверждение;
  Анализ1->Понимание;
  Анализ1->Сравнение;
  Мониторинг->Анализ2;
  Исследование->Анализ2;
  Понимание->Обобщение;
  Понимание->Оценивание;
  Сравнение->Оценивание;
  Анализ2->Оценивание;
 }
 </graph>
 
По словам докладчика, не стоит безоговорочно полагаться на эти связи, но они отлично подходят в качестве стартовой точки.

Далее докладчик вводит понятие информационных персон. Для дальнейшего анализа используется следующий алгоритм. Для каждой категории пользователей выбираются точки взаимодействия с системой (touchpoint) и для каждой из них ставятся вопросы:
* Что ищет?
* Почему и насколько это для него важно?
* Как часто он выполняет эти действия?
* Что он знает об искомой информации?
* Какими словами описывает?
* Что собирается делать с информацией дальше?

Ответив на эти вопросы, можно понять, в каких режимах поиска находится пользователь и записать это примерно вот в таком виде:

<pre>
7 → 5 → 8
</pre>

Здесь цифры обозначают режимы. Рядом ещё указываются частотность повторения и важность. При этом нужно иметь в виду, что поведение в одном touchpoint может быть разным. Например, если пользователь с утра планирует работы на день, это одно, а если в середине дня он что-то перепланирует, то это совсем другое.

Далее устанавливаются возможные связи между touchpoint'ами.

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

== Примечания == 

<references/>
{{wl-publish: 2015-05-05 11:58:04 +0300 | ТС-РТ-Магазин }}
{{replicate-from-custiswiki-to-lib}}