Архив | Сентябрь, 2010

Методики юзабилити-тестирования для эффективной разработки игр

23 Сен

(Перевод статьи «Usability Breakthroughs: Four Techniques To Improve Your Game«)

Эрик Прейс (Eric Preisz) директор компании Torque (aka Garagegames) и два доктора наук из исследовательского центра Full Sail представляют 4 метода юзабилити-тестирования, которые помогут сделать вашу игру лучше, даже если в вашем распоряжении нет огромной лаборатории и двух десятков исследователей.

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

Когда дело доходит до проектирования игр с удобным интерфейсом, важно определить не только реакцию целевой аудитории на те или иные фичи, но и то, как к ним отнесутся другие группы пользователей (на языке профессионалов – «хардкорные» игроки и «нубы»).

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

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

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

Заблаговременное проведение юзабилити-тестов может сыграть большую роль в финансовом благополучии проекта – практика показывает, что перерасход бюджета происходит в основном из-за проблем с юзабилити продукта, которые не были обнаружены в процессе разработки. 80% затрат на исправление и поддержку приходятся на исправление непредвиденных проблем с юзабилити.

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

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

1. Мысли вслух

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

Пример. Во время испытания игрок попытался зарядить пистолет питьевой водой из бутылки, посредством перетаскивания в инвентаре иконки бутылки (серо-голубой трубки с острым концом) на иконку оружия. Свое действие он прокомментировал так: «Похоже на пулю, так что, вероятно, это магазин для ствола». Это действие и последующее объяснение четко дало понять, что иконка бутылки с питьевой водой неоднозначна и подлежит редизайну.

Позитивные аспекты использования:

  • Разработчики получают возможность понять ход мыслей игрока. Методика позволяет определить и задокументировать проблемные для игрока (или нескольких игроков) моменты.
  • Метод хорошо работает при «поточном» тестировании. Исследования показали, что 75% недочетов в дизайне UI может быть обнаружено небольшой группой испытателей (пяти человек достаточно). Результаты тестирования могут быть получены, обработаны и переданы разработчикам на исправление в течение одного рабочего дня.
  • Члены команды разработки (программисты, дизайнеры, руководители проектов) могут лично присутствовать на тесте и убедиться в наличии ошибок в игре. Это позволяет сэкономить время на объяснения и помогает разработчикам понять, зачем необходимы те или иные правки. Иногда важно наглядно продемонстрировать, как игрок сталкивается с затруднениями в ситуациях, на которые сами разработчики в жизни не обратили бы внимания.

Сложности, возникающие при использовании техники:

  • Обычно у играющих не возникает проблем с комментированием своих действий, но некоторым не удается справиться с этой задачей. «Неразговорчивые» игроки никак не помогут в тестах, и с ними вы просто потеряете время.
  • «Думать вслух» – непривычно для игрока. В нормальных условиях геймер редко комментирует то, что делает. Вполне возможно, что, пытаясь вербализировать каждый свой шаг в игре, испытуемый начинает озвучивать выдуманные причины своего поведения вместо настоящих.
  • Некоторым не хватает ума, чтобы ходить и жвачку жевать, не то чтобы играть и параллельно об игре говорить. Часто подопытные скатываются к чему-то одному, что прямо влияет на результаты теста. Вы можете исправить ситуацию, спрашивая игрока, что он делает, в моменты, когда тот замолкает.

2. Эвристический анализ

(Совокупность исследовательских методов, направленных на открытие, познание нового, ранее неизвестного.)

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

Одна из таких «эвристик», состоящая из адаптированных практик Нильсена, была разработана Мелиссой Федеров (Melissa Fedefoff ) – их список можно найти на сайте автора. Если ни одна из эвристик не пришлась вам по душе, всегда можно разработать собственную, специально под вашу игру.

Что для этого нужно?

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

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

Обратите внимание, что отталкиваться необходимо от жанра игры – вам понадобятся разные эвристики для шутера от первого лица (first-person shooter) и для массовой многопользовательской ролевой онлайн-игры (MMORPG)

Пример. Один из пунктов эвристики Нильсена гласит: «Если процесс затягивается более чем на 10 секунд (к примеру, экран загрузки), нужно сделать так, чтобы пользователь получал однозначную информацию о ходе процесса (анимация, прогресс-бар)». Это поможет игроку не только понять, долго ли ждать загрузки игры, но и определить момент, если что-то пойдет не так (системный сбой).
Позитивные аспекты использования:

  • Вы можете использовать уже существующие работы экспертов отрасли или создать собственные списки важных аспектов и элементов UI дизайна, путем анализа игр, схожих с вашей. Это поможет вашему только запустившемуся проекту избежать враждебного отношения со стороны игроков, возникающего из-за очевидных косяков в сюжете, игровых механиках и элементах, характерных для игр вашего жанра.
  • Стоимость такого анализа сравнительно не высока, т.к. вы проводите оценивание самостоятельно или привлекая нескольких наемных экспертов, вместо того чтобы провести исследования на широкой группе пользователей.
  • Данный метод весьма эффективен, когда используется совместно с другим, более ресурсоемким (по временным и денежным затратам). Эвристический анализ помогает идентифицировать проблемы лежащие на поверхности, тогда как ресурсоемкие техники исследований помогают определить трудно выявляемые, но от этого не менее критические ошибки.

Сложности, возникающие при использовании метода:

  • Эвристики сами по себе могут казаться простыми, но их применение требует участия эксперта с наметанным глазом и значительным опытом оценки интерфейсов. Если ваша команда недостаточно опытна – это может стать проблемой.
  • Использование собственной команды для оценки интерфейса может исказить результаты – в конце концов, они уже имеют представление о том, как игрок «должен» использовать управление и трактовать главный интерфейс игры (HUD). В идеале вам нужен специалист, который разбирается в гейм-девелопменте и юзабилити, но не знаком с вашим игровым проектом.
  • Найти подходящего человека не просто. Это вдвойне проблематичнее при разработке собственных эвристик, т.к. вам понадобится больше специалистов для создания в первую очередь своего списка аспектов. Если экспертов нет, выходом для студий, одновременно разрабатывающих несколько игр, может стать вариант, когда разработчики одного игрового проекта становятся юзабилити-тестерами другого, в рамках компании.
  • Трудно решить, что и по какому принципу включать в список эвристик. К примеру, наличие мини-карты, которая позволяет игроку определить местонахождение своего игрового аватара, кажется очевидным для игр в жанре «шутер от первого лица», но как нам это расценивать? Решается ли этот вопрос ответами «да» и «нет», десятибалльной шкалой Ликерта, или субьективным мнением эксперта? Хуже того, эксперты могут разойтись во мнениях о выборе метода опроса в целом или оспорить какой-то вопрос в частности.
  • Строгое следование эвристикам может привести к ограничению творчества. Спросите себя, все ли игроки хотят играть в MMORPG с одинаковыми игровыми элементами, механиками и сюжетными линиями?

3. Фокус-группы

Методология. Участники группы разработки собираются вместе с небольшой группой потенциальных игроков и обсуждают их мнения о дизайне интерфейса, игровых механиках и сюжетных линиях. У команды разработчиков на такие встречи должен быть заготовлен список важных вопросов, на которые они хотят получить ответы. Модератор встречи курирует дискуссию, в ходе которой участников просят обсуждать особенности или аспекты игры, по очереди либо в формате открытой дискуссии. Фокус-группы часто используются для анализа концептов или прототипов, прежде чем те перейдут в фазу разработки.

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

Позитивные аспекты использования:

  • Несколько голов лучше одной. Фокус-группы способствуют обмену идеями между участниками. В процессе такого обмена могут рождаться новые идеи и мнения, равно как и стратегии дизайна, что ведет к повышению эффективности геймплея, игровых механик и сюжетных линий.
  • Все отзывы от участников фокус-группы собираются в течение нескольких часов. Метод хорош при «поточном» тестировании, вы можете быстро собрать и обработать данные и уже на следующий день, либо через неделю, провести новую фокус-группу для оценки новых концепций или даже новых прототипов.
  • Дизайнеры, разработчики и руководители проектов могут непосредственно следить за фокус группой или ознакомится с результатами с помощью видео- и аудиоматериалов. Отзывы игроков, полученные членами команды разработки, могут произвести потрясающий эффект – «Не могу поверить, что они затролили эту особенность геймплея, мы её считали необыкновенно клевой!». Более того, когда дизайнеры, разработчики и руководители лично наблюдают за реакцией аудитории, это снимает всякую необходимость тратить время на анализ и составление докладов.

Сложности, возникающие при использовании метода:

  • Такие исследования должен проводить опытный ведущий. Или хотя бы представитель команды, который умеет слушать (обычно руководители проектов в этом сильны). Но, в таком случае, им нужно быть предельно осторожными, чтобы не подталкивать ход дискуссии к ответам и выводам, которые предпочитают услышать разработчики, иначе фокус-группа становится бесполезной. Задавая вопросы особым образом, ведущий может подталкивать участников дискуссии к желаемым мнениям, что гарантированно уменьшает пользу от исследования.
  • Лидер может навязать остальным свое мнение. Если один из участников обладает собственным мнением и выражает его ясно и четко, другие могут соглашаться с ним под психологическим давлением. Когда это происходит, существенно снижается ценность группы. Запомните, что самый громкий и разговорчивый член фокус-группы не всегда придумывает лучшие идеи.
  • Важно, чтобы все участники чувствовали, что их мнения равноценны. Ощутимая разница в игровом опыте может привести к тому, что лидировать в группе начнет участник с наибольшим игровым опытом в данном жанре игр. В идеале необходимо собирать несколько групп, состоящих только их «новичков» или «опытных» игроков. Данные, полученные из таких раздельных исследований, помогут вам подстроить проект под требования обеих «каст».

4. Наблюдение за игроком в естественных условиях

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

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

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

Позитивные аспекты использования:

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

Сложности, возникающие при использовании метода:

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

Подача докладов по юзабилити

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

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

Когда вы докладываете о своих выводах, ответная реакция от команды разработчиков (сотрудничество/оппозиция) может зависеть даже от слов, которые вы выбираете или от вашего тона.

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

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

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

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

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

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

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

Вывод

Эта статья призвана помочь разработчикам, которые не могут нанять себе в штат профессиональных юзабилистов, внедрить некоторые базовые принципы юзабилити-тестирований, чтобы улучшить как процесс разработки компьютерных игр, так и качество финального продукта. Методы, рассмотренные в этом материале, могут быть эффективно использованы на этапе подготовки, разработки, тестирования, перед релизом игры и после него. Чем раньше вы начнете их использовать, тем лучшим будет результат.

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

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

Разработчики (программисты, художники, дизайнеры), участвующие в юзабилити-тестах, должны помнить о нескольких важных моментах. Цель исследования заключается в том, чтобы посмотреть на проект глазами игрока.

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

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

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

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

Перевод Сергея Паранько

В защиту A/B-тестирования

23 Сен

parakee.livejournal.com

(Оригинал статьи)

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

Как же не истратить ценные ресурсы в пустую?

В юзабилити-тестировании существует такой инструмент — A/B-тестирование. Оно не занимает много времени и сил и позволяет провести сравнительный анализ одного элемента относительно другого. У такого метода есть свои сторонники и противники, но метод, безусловно очень полезный и важный. В защиту этого метода и приводится очень полезная статья, опубликованная в Smashing Magazine.

В защиту A/B-тестирования

Не так давно A/B-тестирование попало под несправедливую критику со стороны разных Internet-сообществ. Несмотря на то, что в некоторых местах эта критика и является справедливой, основной аргумент против A/B-тестирования все же некорректен. Создалось ощущение, что происходит путаница между методом A/B-тестирования и его конкретной реализацией (например, тестирование красной и зеленой кнопки и другие тривиальные тесты). Давайте взглянем на замечания, которые всплывали на сайте [Smashing Magazine] за последнее время.

Аргумент №1: A/B-тестирование и локальный минимум.

Джейсон Коэн (Jason Cohen) в своем посте под названием «Из выгребной ямы в канализацию: ловушка A/B-тестирования» утверждает, что A/B-тестирование дает нам в результате локальный минимум, в то время, как целью является достижение глобального минимума. Те, кто не понимает разницу между локальными и глобальными значениями в контексте A/B-тестирования, могут представить себе зависимость степени посещаемости web-страницы от расположения элементов на этой странице. Эту зависимость можно представить в виде графика, каждая точка которого представляет собой одну из модификаций страницы (по оси Х) и процент ухода с нее (по оси У). Чем ниже точка на графике, тем лучше. Рассмотрим пример Джеймса с  противопоставлением глобального минимума локальному:
Local-minimum-global-maximum in In Defense Of A/B Testing

Однако дальше Джейсон признает в своем посту, что этот довод на самом деле не связан с A/B-тестированием, поскольку этот же метод может быть использован и для проверки радикальных изменений и это позволит добиться глобального минимума. Таким образом несправедливо называть это ловушкой тестирования, скорее этот аргумент указывает на бессмысленность тестирования небольших изменений.

Итак, A/B-тестирование это не преступление и достижение локальных минимумов не является реальной проблемой. Давайте представим себе ось Х как различные цвета фона, а ось У как степень уходов со страницы. В таком случае аргумент Джеймса звучит примерно так: если вы протестировали десятки оттенков синего фона, то вы сможете уменьшить показатель уходов, но если вы попробуете что-то совсем новое (например, желтый фон), вы сможете достичь абсолютного минимума этого показателя.

Но с этим аргументом есть две проблемы…

1. Вы не можете быть уверены, что достигли глобального минимума

Jason Scaled in In Defense Of A/B Testing

Глобальный минимум существует только в теории. Давайте вернемся к примеру с желтым фоном. Что, если при дальнейшем тестировании вы обнаружили, что не цвет фона дал вам самый низкий показатель уходов? Или еще лучше, фон с изображением смешных котов дал еще более низкий показатель? Дело в том что если вы не добились показателя ухода в 0%, вы не можете быть уверенны, что действительно достигли глобального минимума.

Существует еще один способ убедится, нашли ли вы глобальный минимум, после того, как вы исчерпали все возможности. Теоретически, если страница не содержит ничего, кроме цвета фона (и вы даже не можете добавить фоновый рисунок, потому, что ваш босс ненавидит его), вы можете просто перебирать разные цвета и определить, какой из них даст вам самый низкий показатель уходов.
Это подводит нас ко второму вопросу…

2. Друзья мои, существует не только цвет фона

При оптимизации web-страницы вы можете изменять буквально сотни или даже тысячи переменных (и цвет фона — всего лишь одна из них). Заголовок, верстка, длина страницы, видео, изображения и цвет текста — это несколько из таких переменных. Ваша цель на этой странице (с точки зрения посещаемости или степени уходов) определяется всеми такими переменными. Это значит, что график (изображенный выше) не может быть одномерным и не так прост, как кажется. На самом деле он носит многомерный характер с большим числом переменных, влияющих на максимумы и минимумы.
FitnessLandscape in In Defense Of A/B Testing
Пики на графике являются показателями посещаемости или уходов со страницы и определяются разным числом переменных (на графике их всего две, но в реальности существуют сотни переменных). В отличии от одномерного случая, перебрать все варианты в реальности невозможно. Таким образом вы не можете гарантировать, что добились глобального минимума. Урок, который из этого можно извлечь — искать локальные минимумы.

Аргумент №2: A/B-тестирование минимальных изменений.

Рэнд Фишкин (Rand Fishkin) из SEOmoz разместил статью под заголовком «Не попасть в ловушку мелочей A/B-тестирования», в которой он подтверждает вывод Джеймса о бессмысленности тестирования отдельных небольших элементов страницы. Его главный аргумент это то, что тестирование минимальных изменений отнимает слишком много энергии и времени. Ниже приведено изображение из его блога. Конечные изменения слишком малы, чтобы их хоть как-то отметить.
Abtests in In Defense Of A/B Testing

Первое, что необходимо сделать — уменьшить время, затрачиваемое на прохождение теста (часто несколько недель), но не время, необходимое для создания теста (занимающее, обычно, несколько минут). Есть очень много автоматизированных систем тестирования, поэтому, после того, как вы создали тест, вам необходимо потратить совсем немного времени на настройку. Что плохого, если инвестиции в 15 мин. на создание теста для цветных кнопок дают в итоге 1,5% увеличение конверсии траффика в действия?

Многие инструменты A/B-тестирования позволяют очень просто создавать небольшие тесты. Они могут проводить тестирование в фоновом режиме, тест может быть в любой момент автоматически остановлен. Чем вы рискуете, создавая такие тривиальные тесты? Я вижу только положительную сторону: рост конверсии и продаж.

В качестве иллюстрации Рэнд приводит в пример редизайн стартовой страницы Basecamp, после которого конверсия возрасла на 14%. Можете себе представить, сколько усилий было приложено, чтобы сделать такой редизайн (по сравнению с тестом цветных кнопок)? Действительно, как вы уже поняли, график испытаний многомерный и очень сложный, поэтому при глобальном редизайне велика вероятность сделать еще хуже. В проектирований появляется много мест для ошибок. Можно ошибиться не только в цвете кнопки. Но мы не должны делать вывод, что тестирование радикальных изменений эффективнее тестирования мелочей, только потому, что мы никогда не слышали, что в результате глобального исследования что-то пошло не так. К тому же тестирование радикальных изменений требует гораздо большего числа сил и времени, по сравнению с небольшим тестом красного против синего.

Мы точно знаем, что при попадании в локальный минимум повышается конверсия, и это ведет непосредственно к увеличению прибыли. Это не означает, что мы должны отказаться от стремления найти глобальный экстремум (минимум или максимум). Глобальный экстремум, как «мир во всем мире» — его невероятно сложно достичь, но всегда нужно двигаться в этом направлении. Урок, который можно извлечь из вышесказанного: идеальная стратегия представляет собой смесь небольших тестирований (красный или синий?) и тестирований глобальных изменений.

Аргумент №3: A/B-тестирование душит творчество.

Джефф Этвуд (Jeff Atwood) сравнивает фильм «День Сурка» с A/B-тестированием и приходит к выводу, что A/B-тестирование также терпит неудачи, как и герой фильма. Джефф полагает, что в A/B-тестировании нет места эмпатии и оно душит творчество. Он ссылается на твиттер Натан Боуэрс (Nathan Bowers):

A/B-тестирование как наждачная бумага — вы можете сгладить с помощью него какие-то шероховатости, но не  можете ничего реально создать.

Но кто утверждает, что A/B-тестирование необходимо для создания чего-либо? Создание происходит в уме, а не исключительно инструментом. Так же порочно эти рассуждения можно применить и к обычной кисти:

Кисточка как палка с мехом — вы можете с ее помощью пощекотить кошку, но вы не можете ничего реально создать.

A/B-тестирование, как кисть, просто инструмент. И как все инструменты оно имеет свои свойства и ограничения. Оно не диктует вам, что вы можете проверить, таким образом тестирование ограничивается только вашей фантазией. С A/B-тестированием или без него вы можете применять всю вашу эмпатию и фантазию в создании дизайна вашего сайта. Только от вас зависит, осуществлять все изменения сразу, или взять более научный подход и попытаться определить, действительно ли новый дизайн обеспечит большую конверсию. Полученный урок: A/B-тестирование это инструмент, а не инструкция по проектированию.

Резюме


Уроки, которые мы получили из этих трех аргументов:

  • Мы никогда не сможем добиться глобального экстремума, заменим его локальным экстремумом. Тестирование минимальных изменений занимает несколько минут, но результат будет гораздо больше, чем стоимость этих минут.
  • Постоянно изучайте наилучшие пути увеличения посещаемости выполняя как тривиальные тесты, так и тестирования глобального редизайна.
  • A/B-тестирование не убивает вашего воображения (вам необходимо очень много воображения при разработке вариантов тестов).
  • И наконец, не чуствуйте себя виноватым, применяя A/B-тестирование.

Перевод In Defense Of A/B Testing (Paras Chopra) — Smashing Magazine

Новый HTC Sense для Windows Phone 7

17 Сен

В HTC, судя по всему, прониклись концепцией интерфейса Windows Phone 7. Во всяком случае, новый HTC Sense выглядит просто обалденно.

А вот так выглядит реальное устройство:

Конференция Юзабилити Украина 2010

16 Сен

Юзабилити Украины 2010

5 ноября в Киеве пройдет первая всеукраинская конференция Юзабилити Украина 2010(http://usability.ua/). Впервые IT-конференция в Украине будет полностью посвящена вопросам юзабилити. Иными словами — тому, почему так важно сделать сайт простым и понятным для пользователя.

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

Организаторы конференции — ведущие украинские юзабилити-компании: Турум-бурум (http://turumburum.com/), Usabilist.com.ua (http://usabilist.com.ua), Инвуду (http://invoodoo.com/)

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

«Главная ценность нашей конференции в том, что мы все будем говорить о юзабилити на конкретных примерах из своей практики, — рассказывает представитель оргкомитета «Юзабилити Украина 2010» Евгений Мусиенко. — Никакого «сферического проекта в вакууме»: мы хотим поделиться реальным опытом».

В программе конференции:
– доклады экспертов из ведущих IT-компаний Украины и России (Яндекс, Uidesign, UI Modeling Company, iContext, Турум-бурум, Invodoo, Usabilist.com.ua и др.);
– свободное общение и анализ практического опыта украинских веб-проектов с юзабилити-специалистами из Tochka.net, korrespondent.net, bigmir)net;
– круглые столы, посвященные проблемам юзабилити в Украине — с участием представителей коммерческих проектов и компаний-разработчиков (Rozetka.ua, Nezabarom, Drimtim.ru, Owox, yakaboo.ua);
– пресс-конференция о развитии украинских веб-проектов.

Место проведения конференции будет объявлено 21 сентября.
Полная информация об участниках – на сайте проекта: http://usability.ua

Более подробную информацию о проекте вы можете получить в оргкомитете конференции:
Александра Голубь, координатор проекта,
e-mail: alexandra@turumburum.com
тел.: +380 50 975 79 14

Иванна Скиба, PR-менеджер проекта,
e-mail: pr@turumburum.com

Обзор свежих материалов, август 2010

13 Сен

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрельмай-июньиюль.

Методы и практики

In Defense of A/B Testing
Paras Chopra написал отличную статью в защиту метода A/B-тестирования, в последнее время подвергшегося критике со стороны проектировщиков и дизайнеров. Он опровергает три основных претензии, которые касаются в первую очередь зацикливания на не самых эффективных изменениях.

Guidelines for Designing Data Tables
Connie Malamed, автор книги “Visual Language for Designers”, дает серию советов по оформлению таблиц. Она описывает ментальный процесс работы с таблицей и рассказывает о том, как упростить пользователю прохождение по нему.

Making User Interface Elements Difficult to Use By Intent
Статья Jacob Gube, в которой он рассказывает о намеренном усложнении интерфейса в тех случаях, где возможна потеря данных и другие неприятные последствия.

Making the Deal — Supporting Product Demos with User Assistance
Mike Hughes из IBM описывает процесс оптимизации интерфейса демо-версий продукта. Он описывает 4 характеристики, в которых демонстрация должна быть особенно хороша — ценность продукта и ее наглядный показ, внимание к существующим проблемам пользователя, конкурентные преимущества.

User Interface Stack Exchange
Новый сервис вопросов и ответов, посвященный практическим вопросам проектирования интерфейсов. Здесь собраны популярные вопросы и ответы практикующих специалистов на них.

Good Help is Hard to Find
Статья Lyle Mullican описывает несколько способов представления справочной информации в веб-сервисах. Он разделяет помощь на два типа — интегрированную в общий процесс и показываемую отдельно.

Guidelines for user friendly URI Design
Неплохая памятка о создании понятных и читабельных URL от Jacob Gillespie. Статья рассказывает об общих принципах и дает серию полезных советов.

Инструменты

Free Wireframing Kits, UI Design Kits, PDFs and Resources
Одна из наиболее масштабных подборок шаблонов и стенсилов для проектирования и дизайна веб-сервисов и мобильных приложений. Хотя таких коллекций в последнее время появляется все больше, эта статья от Smashing Magazine — одна из наиболее подробных и проработанных.

20 Free Web UI Element Kits and Stencils
Еще одна коллекция шаблонов и стенсилов для проектирования и дизайна. Не так много нового, но может быть полезна.

Паттерны

Liquid Information Navigation – A New Paradigm?
James Kalbach из LexisNexis описывает постепенно развивающийся тренд в веб-интерфейсах — аналог контекстного меню десктопных приложений. Хотя такие меню периодически встречаются вот уже несколько лет, в статье собрана вместе подборка таких примеров.

Dark Patterns — Black Hat, Anti-Usability Design Patterns
Коллекция анти-паттернов проектирования, в которой собраны примеры того как делать не нужно. Примеров пока не так много, но автор сайта Harry Brignull активно публикуется в профессиональном сообществе и вряд ли забросит интересное начинание.

Процесс

All Look Same? A Comparison of Experience Design and Service Design
Jodi Forlizzi сравнивает user experience design и service design с тем чтобы понять, насколько близки эти дисциплины. В статье делаются отсылки к их истории и общему процессу.

Learning from Our Challenge Piles
Отличнейшая статья Michelle Gilmore, в которой она делится своим опытом решения проблем, возникающих при работе с заказчиком работ по проектированию и дизайну. Она описывает 4 типовые ситуации из своей практики и рассказывает о том, как было найдено решение.

Кейсы

Case study — How we made an extra £14 million a year for a travel company
История о том, как был переделан сайт турагентства Sunshine Travel и как это помогло значительно повысить конверсию. Статья описывает основные изменения и процесс работы над проектом.

Designing a Persuasive Video Game
Здорово описанный кейс, рассказывающий о процессе создания обучающей игры. John Ferrara пишет об использовавшихся принципах игровой механики и том, чего они хотели достичь их использованием.

Migrating a Corporate Intranet to SharePoint — A Case Study
Jen Hocko описывает процесс переноса корпоративного интранет-сайта на платформу SharePoint и то, какие задачи решал проектировщик в этом процессе.

Теория

Emotional Design with A.C.T.
Интереснейшая серия публикаций Trevor van Gorp, в которой он описывает психологические основы вовлекающих интерфейсов. Он исследует вызывающий эмоции дизайн и то, как можно создавать его.

Updating Our Understanding of Perception and Cognition
Выдержка из книги Jeff Johnson “Designing with the Mind in Mind”, в которой он описывает процессы восприятия и познания. Крайне полезное чтение, которое позволяет понять как работает и что видит глаз, как происходит процесс чтения и распознавания объектов. Вторая часть статьи —www.uxmatters.com/mt/archives/2010/08/updating-our-understanding-of-perception-and-cognition-part-ii.php.

История

What is a Device?
Выдержка из будущей книги Dan Saffer “Designing Devices”, в которой он описывает краткую историю устройств. А это очень полезно для понимания того, как развивались интерфейсы.

Тренды

5 Creepy Ways Video Games Are Trying to Get You Addicted
Подробное описание 5 распространенных принципов игровой механики от David Wong, которые используются во многих хитовых играх. Статья особенно хороша тем, что в ней приводится масса примеров и отсылок к исследованиям.

Свежие ссылки можно также отслеживать во Friendfeed-ленте User Experience.

Как выглядит китайская клавиатура

13 Сен

Вы, вероятно, представляли ее себе как целый орган — грандиозное сооружение длиной в пару метров с сотнями и тысячами клавиш. На самом деле, большинство китайцев используют обычную клавиатуру с латинской раскладкой QWERTY. Но как с помощью нее можно набрать такое несметное количество различных иероглифов? Мы попросили рассказать об этом нашу сотрудницу Юлию Дрейзис. Ее с Китаем связывают и давняя любовь, и работа.

История вопроса: печатные машинки

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

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

image
Печатная машинка фирмы «Шуангэ», 1947 год (принцип действия придуман японцем Киота Сугимото в 1915 году).

Основной ее элемент — банк иероглифов, находящихся на чернильной подушке. Над иероглифами закреплена механическая система: рукоятка, «лапка» для захвата и бобина с листом бумаги. Весь механизм вместе с бобиной вслед за рукояткой способен перемещаться влево, вправо, вперёд и назад за счет усилия машиниста. Чтобы набрать текст, машинист долго ищет с лупой нужный иероглиф, помещает над ним систему и нажатием на ручку приводит в действие «лапку», которая хватает иероглиф и на ходу, разворачивая, отпечатывает его на листе бумаги. При этом бобина с листом немного проворачивается, предоставляя место для следующего символа. Разумеется, процесс печати на таком агрегате выходит крайне медленным — опытный оператор мог набирать не более 11 иероглифов в минуту. Читать далее

Почему папки желтые

6 Сен


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

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

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


Своим появлением она обязана идее оснастить графический интерфейс легендарной рабочей станции Xerox Star (Xerox 8010) метафорами, понятными рядовому офисному клерку. Идеи черпались из стандартного канцелярского оснащения тогдашних офисов. Первым же коммерческим воплощением на массовом рынке стал интерфейс Apple Lisa.

Basic folder appearanceA folder is drawn as a white rectangle (filled in by the application) with a thin (one pixel) black border. Every folder has a tab, which looks like a tab on a standard manilla folder. The tab is always above the upper left corner of the folder. It is called the title tab. The rectangular portion of the folder that holds the folder’s contents is called the body of the folder

“Lisa user interface standards” (1980)

Бумажная папка
Прототипом для метафоры послужила так называемая «манильская папка» (manila folder). Насколько я знаю в русском языке подобный термин отсутсвует (хотя иногда и мелькает в  художественной литературе, что, впрочем, может являться лишь ляпом). Правильно будет говорить просто «бумажная папка» или «папка».
Конструктивно она представляет собой согнутый лист бумаги, внутрь которого можно вкладывать или подшивать документы..


Folder=fold (сгибать, собирать)+er (суффикс для образования существительного)

Данный тип папок не был известен на территории бывшего СССР, поэтому иконка папки отчасти являлась симулякром, т.е. не имела под собой предметной части, а только свойство. В системах Win 9x объект казался просто желтым прямогольничком с выступом, т.е. вещью абстрактной.

Бумага. Почему папки желтые.

Американский тип папок изготовляют из прочной бумаги, называемой «манильской». В ее состав входит «манильская пенька», волокна, добываемые из листьев текстильного банана или абаки (растение, родом с Филиппин). Волокна очень жесткие и обладают равномерной толщиной, легко окрашиваются. Хотя, как правило, манильскую бумагу не подвергают обработке красителями. Она сохраняет естественный цвет волокон: желтовато-бежевый. Вот почему иконки папок Windows и некоторых других систем — желтые или бежевые.

Помимо бумаги манильскую пеньку, используют для производства морских канатов. По этой причине второе название манильской бумаги — «канатная».

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

Материал для изготовления папок достаточно гладкий, в составе бумаги нет грубых частиц, чтобы не поцарапать документы. Отсуствуют и химические активные компоненты, способные, вступить в реакцию с фотобумагой и повредить снимки, хранящиеся в папках. Существует стандарт, который требует, чтобы папки, попав в воду, не окрашивали содержимое в какой-либо посторонний оттенок.
«Леопардовая» иконка папки из MacOs, хорошо видна неоднородная бумажная фактура.

В Microsoft Windows Vista/7 папки развернуты на 90 градусов. Это сделано для придания определенной свежести иконкам. А также символизирует более широкую трактовку понятия «папка» в этой системе. В частности, она больше не ассоциируется лишь с физической директорией на диске. У развернутой папки есть свое преимущество: в ней легче компоновать изображение документов.

Продолжение следует…

Спасибо большое пользователю rogix