Автор статьи: Hana Schank
Оригинал статьи опубликован в UX Magazine (10.11.2011)

Об авторе:

Hana Schank – директор и основатель Collective User Experience, UX-консультант, работает с клиентами из списка Fortuna 1000, помогая делать их сайты и приложения более удобными. Она имеет более 14ти лет опыта работы с информационной архитектурой и UX-дизайном. Хана вела блог про IA в реальном мире: beautifulbutdumb.blogspot.com, сейчас твитит @hanaschank. Она живёт в Бруклине, Нью-Йорк

Автор статьи: Jim Ross
Оригинал статьи опубликован в UXmatters (7.02.2011)

Сколько раз это случалось с вами? Вы заканчиваете презентацию результатов юзабилити-тестирования, эвристического анализа или других исследований пользовательского поведения, чувствуя себя отлично, предвкушая положительное воздействие ваших рекомендаций на user experience. Аудитория улыбается и дружно кивает на протяжении всей презентации. Большинство из них согласны с вашими выводами и кажутся искренне впечатлёнными от работы, которую вы проделали. Но впоследствии вы сталкиваетесь с тем, что только некоторые рекомендации реализованы полностью, а все остальные – нет.
Почему юзабилити-проблемы не исправляются? Если мы указываем на очевидные проблемы с юзабилити и предлагаем их разумные решения, почему иx так никто и не исправляет? В данной статье я рассмотрю эти вопросы и дам некоторые советы, которые могут обеспечить внедрение ваших рекомендаций.

Причины, по которым проблемы юзабилити не исправляются

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

Нехватка ресурсов

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

Ни у кого нет навыков, чтобы исправить их

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

Нехватка времени, денег или ресурсов

Зачастую, существует больше проблем с юзабилити, чем команда может исправить за доступное время, деньги и другие ресурсы. Гораздо проще внедрить решения простых проблем, которые называются быстрыми победами (quick wins), чем решать сложные вопросы, которые требуют значительных переработок. Хотя решение этих маленьких проблем могут дать команде чувство выполненного долга, более серьёзные проблемы, к сожалению, могут так никогда и не быть решены.

Технические ограничения

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

Технические ограничения создают трудности при внесении изменений

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

Вендорное программное обеспечение тяжело изменить

Одна из самых неприятных ситуаций, которая может возникнуть, – это попытка повысить юзабилити корпоративного ПО, которое ваша компания приобрела у поставщика. Такие приложения в большинстве случаев плохо спроектированы и имеют логику работы, которая “подходит всем” (one-size-fits-all mentality). Они часто имеют закрытый код, который тяжело изменить, что затрудняет повышение юзабилити, если это вообще возможно. Неудивительно, что компании предпочитают полагаться на обучение и большое количество обходных путей, чем на решение этих проблем.

Культура организации

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

Убогое юзабилити принимается как норма

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

Политические вопросы служат препятствием внедрения улучшений

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

Юзабилити-проблемы отбрасываются, полагая, что это просто вопрос обучения

Удобный способ для предприятия избежать исправления проблем – это отнести их к вопросам обучения. Веря в то, что юзабилити-проблемы – это всего лишь вопрос обучения, предполагается, что проблема не с программным обеспечением, а с пользователями. Людям просто необходимо выучить, как пользоваться ПО, и это решит все проблемы. Ещё одно ленивое и менее дорогое решение – заявить, что это вопрос коммуникации. Пользователям просто нужно было объяснить, как правильно делать что-либо.

Вопросы и правила безопасности конфликтуют с юзабилити

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

Вопросы коммуникации

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

Юзабилити-рекомендации не всегда хорошо объясняются

Юзабилити-специалисты обычно представляют свои рекомендации в качестве текста – это формальный отчёт или презентация. Если текст является эффективным для описания общих рекомендаций или простых изменений, то он плохо объясняет комплексные дизайнерские решения и оставляет много пространства для неправильных интерпретаций.

Недопонимания между дизайном и разработкой

Обычно, разные люди проводят исследования пользователей, проектируют и разрабатывают на различных стадиях проекта. Нередко люди покидают проект, как только они завершают свою часть. Это оставляет пользовательские исследования открытыми для свободного толкования проектировщиками, а дизайн открытым для толкования разработчиками. Неудивительно, что мы иногда чешем головы, когда видим финальный продукт, гадая “Откуда это взялось?”

Отсутствие плана по внедрению рекомендаций

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

Не существует простых решений

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

Как сделать так, чтобы ваши рекомендации были реализованы?

Не отчаивайтесь! Не смотря на то что мы имеем внушительный список причин, по которым юзабилити-проблемы не исправляются, ситуация не безнадёжна. Есть способы удостовериться в том, что ваши рекомендации будут внедрены.

Привлекайте правильных людей

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

Задействуйте проектную команду на ранних стадиях

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

Консультируйтесь с вашими собственными техническими ресурсами

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

Представляйте рекомендации правильным людям

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

Во время выбора корпоративного ПО оценивайте его юзабилити

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

Предоставьте наглядные примеры

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

Отображайте визуально ваши результаты

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

Предоставьте визуальные рекомендации

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

Признайте то, что это непростое решение

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

Помогайте с последующими шагами

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

Приоритезируйте ваши заключения и рекомендации

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

Опишите преимущества исправления ошибки и последствия её игнорирования. Это поможет команде, которая имеет ограниченное количество времени, денег и ресурсов, приоритезировать свою работу. Если необходимо, они могут распланировать внедрение ваших рекомендаций поэтапно. Вместо того чтобы предоставить вашим клиентам исчерпывающий список проблем, глядя на который они подумают “И с чего нам начать?”, убедитесь в том, что клиенты получат ваши выводы и рекомендации в форме, которая позволяет сделать решение проблем более выполнимой задачей.

Рекомендуйте план выполнения

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

• обзор ваших заключений
• приоритезацию рекомендаций
• определение того, какие вопросы будут решаться на определённых этапах
• назначение определённых людей для исправления определённых проблем

Продолжайте участвовать в процессе разработки

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

Проведите оценку юзабилити, как только процесс разработки будет завершён

Хороший способ для исследователей и проектировщиков оставаться вовлечёнными в дальнейший процесс разработки продукта – это участие в QA-тестировании. Пока QA-аналитик проверяет ПО на предмет функциональных дефектов, юзабилити-специалист и проектировщик могут сделать обзор пользовательского интерфейса, чтобы выявить юзабилити-ошибки и проблемы с дизайном. Фиксируйте ошибки пользовательского интерфейса в вашем инструменте багтрекинга, подразумевая то, что они являются официальными дефектами. Если исправление ошибок – это задача, которая находится в пределах масштаба проекта, разработчик получает назначение их исправить, а UX-специалисты могут отслеживать вопросы юзабилити и дизайна, чтобы убедится в их исправлении. Это отличный способ официально обеспечить то, чтобы все оставшиеся проблемы воспринимались всерьез и на самом деле были исправлены.

Обучайте своих клиентов

Вы можете помочь своим клиентам решить текущие юзабилити-проблемы, но это не предотвратит появление ещё больших проблем в будущем. Сосредоточьтесь на общей картине и покажите им, что не так с их текущим процессом. Расскажите им о значимости проектирования, ориентированного на пользователя, помогите построить “user-centered design”-процесс и нанять правильных людей.

Выводы

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

• Вовлекайте вашу проектную команду в планирование, наблюдение и обсуждение пользовательских исследований
• Перед тем как выбрать корпоративное ПО, оцените его юзабилити
• Консультируйтесь с собственными техническими ресурсами – убедитесь, что ваши рекомендации осуществимы
• Представляйте рекомендации тем, кто имеет право утвердить их реализацию
• Представляйте ваши заключения визуально: с помощью скриншотов, изображений и видеоклипов
• Иллюстрируйте рекомендации эскизами
• Если нет простого решения, и необходимы дальнейшие исследования, признайте это
•  Приоритезируйте ваши заключения и рекомендации по уровню критичности, чтобы проектная команда смогла определить, на чём сфокусироваться в первую очередь
• Предоставьте план внедрения рекомендаций
• Оставайтесь задействованными во время проектирования и разработки, чтобы убедиться, что ваши рекомендации выполнены корректно

Применение пользовательских исследований, проектирования и юзабилити-тестирования до начала процесса разработки имеет практический и экономический смысл. Лучше предотвращать проблемы, которые могут возникнуть, чем исправлять уже созданные проектной командой – из-за множества причин юзабилити-проблемы часто не исправляются и могут усугубиться при попытке внедрения рекомендаций. Таким образом, при работе с клиентами вам необходимо выходить за рамки решения текущих проблем и обучать ваши проектные команды важности “user-centered design”-процесса.

Автор статьи: Lyndon Cerejo
Оригинал статьи опубликован в Design Better And Faster With Rapid Prototyping (16.08.2010)

Старая поговорка гласит: “одно изображение способно заменить тысячу слов”. Её можно также применить и к прототипированию: лучше визуализировать тысячи слов о дизайне и разработке системы – то, как она должна работать и выглядеть. В итеративном подходе к созданию пользовательского интерфейса словосочетанием “rapid prototyping” называют быстрое макетирование будущего состояния системы, будь то вэб-сайт или приложение, и его проверка пользователями, заказчиками, разработчиками и дизайнерами. Если делать это быстро и итеративно, то можно по ходу процесса создания получать отдачу на ранних этапах и регулярно, повышая уровень финального дизайна и снижая необходимость внесения изменений в процессе разработки.

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

Процесс быстрого прототипирования

Быстрое прототипирование включает в себя несколько итераций трёхэтапного процесса:

• Прототип
  Преобразование описания решений в макеты, используя стандарты UX и лучшие практики.
• Обзор
  Поделитесь своим прототипом с пользователями и оцените, насколько он соответствует их ожиданиям и потребностям.
• Совершенствование
  Основываясь на отзывах, определите области, которые должны быть усовершенствованы или дополнительно описаны и уточнены.

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

Определение возможностей прототипа

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

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

Как много должно быть спрототипировано ?
Хорошим правилом является то, что нам необходимо сфокусироваться на тех 20% функционала, который будет использоваться 80% времени, т.е. ключевые функции, которые будут использоваться наиболее часто. Помните, что цель быстрого прототипирования – это демонстрация того, что и как будет работать или, на более поздних стадиях, как система будет выглядеть, без прототипирования всего продукта.

Определите сценарии
После определения областей, которые будут спрототипированы, соедините их вместе с одним или несколькими сценариями: определите понятные пути получения пользовательского опыта, который будет симулировать прототип. Для вэб-сайта продающего обувь одним сценарием может быть “Скучный Джо”, который покупает точно такие же беговые кроссовки Nike, какие он купил 6 месяцев назад, а другим сценарием может быть “Изучающий Сэм”, просматривающий всю обувь 10го размера, чтобы найти пару “оксфорд-шуз” и пару тапок, которые его интересуют.

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

Выберите подходящий уровень соответствия

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

• Визуальное соответствие (наброски .. стилизация)
  Внешний вид и осязание являются наиболее заметными аспектами соответсвия прототипа и, если они подобраны неверно, могут уводить в сторону отзывы о прототипе. Если перейти к точному соответствию слишком рано, то пользователи будут обращать внимание на визуальный дизайн, который не имеет значения на ранних стадиях. С визуальной точки зрения, прототипы не должны быть совершенными до пикселя, необходимо просто соблюдать пропорции. К примеру, если левая навигационная область должна занимать пятую часть экрана шириной в 1024 пикселя, она не должна иметь ширину точно 204 пикселя до тех пор, пока пропорции этой области сохранены в прототипе. Пока прототип проходит через цикл проектирования, повышайте по мере необходимости визуальное соответствие путём введения элементов стиля, графики, брендирования и цветов.
• Функциональное соответствие (статичность .. интерактивность)
  Прототип будет просто отображать работу системы (статический) или он будет выглядеть полностью функционирующим, реагируя на действия пользователя (интерактивный). Это соответствие в меньшей степени отвлекает пользователей, но добавление интерактивности в последующих итерациях повышает функциональньность и позволяет использовать прототип для юзабилити-тестирования, обучения и комуникации.
• Соответствие контента (Lorem ipsum .. реальный контент)

Ещё один аспект, который отвлекает пользователей, – это контент, который отображается в прототипе. Волнистые линии и фиктивный текст наподобие “lorem ipsum” полезны на ранних стадиях прототипирования. Но с уточнением прототипа нужно оценивать необходимость замены “lorem ipsum” на реальный контент, чтобы оценить, как он влияет на общий дизайн.

Диапазон прототипирования

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

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

Средний уровень соответствия
Как только мы начинаем применять компьютерные инструменты наподобие Visio или OmniGraffle, уровень соответствия возрастает для большинства аспектов, выводя прототип на средний уровень. Каркасы (wireframes), задачи и сценарии, которые созданы этими инструментами, требуют больше времени и усилий, но выглядят более формальными и качественными. Хотя визуальные элементы брендинга, цвета и стили могут быть введены, прототипировщики часто держатся от них подальше, вместо этого сосредотачиваясь на демонстрации поведения приложения. Интерактивность может быть симулирована, путём связки страниц или экранов, но функциональное соответствие тут подойдёт лучше всего.

Есть две причины, по которым можно намеренно делать так, чтобы прототипы со средним уровнем соответствия не выглядели таковыми:

1. Во-первых, используя Balsamiq или схематичные трафареты Visio, вы заставляете пользователей воспринимать работу как незавершённую или как черновик, а не завершённый отточенный продукт.
2. Во-вторых, предоставляя прототип с высоким уровнем визуального соответствия (например, детальный макет, сделанный в Photoshop), вы даёте пользователям возможность сфокусироваться на визуальном дизайне и внешнем виде, включая цвета, шрифты, изображения и логотип.

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

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

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

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

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

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

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

Выбор инструментов

В зависимости от ваших подходов, у вас есть широкий выбор инструментов. Дэн Харрельсон (Dan Harrelson) составил список популярных инструментов прототипирования в блоге Adaptive Path.

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

• Насколько легко изучить и использовать инструмент?
• Насколько гибко он поддерживает прототипы для вэб, пакетных и пользовательских приложений, а также десктоп- и мобильных приложений?
• Даёт ли инструмент доступ к библиотекам многократно используемых трафаретов, шаблонов и виджетов?
• На сколько легко поделиться прототипом с остальными для оценки? Можно ли с помощью этого инструмента собрать их отзывы?
• На сколько легко вносить изменения “на лету”? Можно ли включить инструмент обратной связи?
• Есть ли у него функции совместной работы, такие, как возможность нескольким людям работать с ним в одно и то же время?
• Каковы условия лицензии и стоимость?

Что делать нужно, а чего не стоит?

Делать:

• Работайте совместно с пользователями и заинтересованными со стороны бизнеса и ИТ во время быстрого прототипирования. Помимо ценной обратной связи, они также дают чувство ответственности за конечный продукт.
• Избегайте “затянутых прототипов”, устанавливая сроки для процесса, учитывая цели, уровень соответствия, масштабность и продолжительность. Напоминайте всем, в том числе и себе, что быстрое прототипирование является средством для достижения цели, а не самоцель.
• При построении высокоточных прототипов и симуляторов настраивайте реалистичные задержки (например, для обновления экрана или перемещения между шагами транзакции), тогда пользователи не будут ожидать мгновенного ответа в конечном продукте.
• Используйте элементы повторно (Reuse, reuse, reuse). Для компьютерных прототипов это означает сохранение многократно используемых шаблонов, трафаретов, паттернов и виджетов для их использования в последующих проектах.
• И самое главное, начинайте каждый прототип с обзорной сессии с оговариванием того, что это всего лишь прототип, макет, а не само решение. Это напоминает пользователям, что работа ещё в процессе, что увеличивает обратную связь, и в случае высококачественного прототипа не позволяет пользователям ошибочно принять его за работающее решение.

Не делать:

• Не протипируйте решения и функции, которые не могут быть реализованы. Если есть сомнения, проконсультируйтесь у разработчиков до начала.
• Не воспринимайте каждое изменение или запрос, которые следуют из отзывов о прототипе, как новое требование. Быстрое прототипирование помогает собрать упущенные требования, но эти новые требование должны быть тщательно исследованы. Некоторые из них могут быть реализованы, а некоторые стоит отложить до следующей версии.
• Не начинайте обзорную сессию прототипа без выработанных принципов получения обратной связи. Чётко определите тип обратной связи, которую вы хотите получить. (Логично ли организованны шаги? Интуитивна ли навигация?). Если этого не сделаете, то будьте готовы к “Мне не нравится синий цвет в шапке”, “Мы можем использовать вот этот шрифт вместо этого?” или “Можете ли вы сделать это больше, толще, в красном цвете и мигающим?”.
• Не будьте перфекционистами. В большинстве случаев быстрое прототипирование не является совершенным на 100%, оно должно быть достаточно хорошим, чтобы дать общее понимание каждому.
• Не прототипируйте всё. Вы не должны этого делать в большинстве случаев.

Автор статьи: Lyndon Cerejo
Оригинал статьи опубликован в Design Better And Faster With Rapid Prototyping (16.08.2010)

Автор статьи: Susan Weinschenk
Оригинал статьи опубликован в What Makes Them Click (25.10.2009)
Перевод статьи: Виктор Малый (UX-UA)

7 + – 2???
3 или 4???

Те из вас, кто работает в области юзабилити или проектирования взаимодействия на протяжении нескольких лет, возможно слышали фразу “Магическое число 7 плюс или минус 2”. Это понятие произошло из одной легенды, часть из которой приведена ниже.

“Однажды парень по имени Миллер провел исследование и написал научную статью о том, что люди могут запоминать и обрабатывать от 5 до 9 вещей (7 плюс/минус 2) одновременно. Поэтому, вы должны создавать меню, которые содержат 5-9 пунктов, или иметь то же количество закладок в горизонтальном меню на экране одновременно.

Слышали ли вы об этом? Уверена, если вы достаточно давно читаете о юзабилити – то да. Скажем так, данное утверждение не совсем кореектно. Другой парень – Бэдли – подверг сомнению научную работу Миллера. Более того, Бэдли выяснил что это была совсем не научная работа, а просто доклад, сделанный на профессиональном сообществе, на основе размышлений Миллера о том, существует ли какой-то то четкий предел количества информации, которую может обработать человек в один момент времени.

После этого, Бэдли провел целую серию исследований человеческой памяти в процессе обработки информации, и пришел к тому, что число должно быть не 5-9, а 3-4.

Вы можете запомнить 3-4 вещи на 20 секунд. Если вы не будете вспоминать о них дальше, они удалятся из вашей памяти. Для примера, представьте, что вы ведете автомобиль, и разговариваете по телефону (да, так делать нельзя, но все же). Ваш собеседник в это время пытается продиктовать вам номер телефона, по которому необходимо перезвонить позже – и у вас нет возможности записать его ручкой, потому что вы за рулем. Вы пытаетесь запомнить этот длинный номер телефона, чтобы перезвонить потом. Что вы делаете? Повторяете его снова и снова, подгружая этот номер в кратковременную память, что дает вам дополнительные 20 секунд. Интересная особенность телефонных номеров состоит в том, что большинство из них имеет длину больше, чем 3-4 символа, поэтому их тяжело запомнить на большее время, чем 20 секунд.

712-569-4532

Мы также пытаемся составлять информацию в группы, каждая из которых содержит 3-4 единицы информации. Поэтому в США номера телефонов такие: 712-569-453. Он состоит из кусочков, по 3-4 единицы каждый. Если вы знаете наизусть код города (т.е. он надежно засел в вашей долговременной памяти), то эту группу чисел запоминать уже не нужно. Телефонные номера запоминать легко потому, что вы преимущественно звоните людям из своего города, и вам не нужно держать его в кратковременной памяти (более того, нет необходимости набирать его, звоня в пределах города). А если вы живете в маленьком городке, и совершаете звонки внутри него, то вторую группу цифр – “569” – можно также выбросить потому, что у всех абонентов она будет одинакова. Все, что вам остается запомнить, это четыре последних цифры (кстати, я живу в маленьком городе в штате Висконсин, и когда у нас кто-то диктует номер своего телефона, он говорит только 4 последние цифры).

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

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

Вот пример: на сайте Upton tea присутствует огромное количество закладок в навигационном меню, но они не разбиты на логические подргуппы по 3-4 элемента в каждой.

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

Для тех, кто заинтересовался исследованиями на эту темы, предлагаю ознакомиться с некоторыми из них:

• Baddeley, A. D. (1986). Working memory. New York: Oxford University Press.
• Baddeley, A. D. (1994). The magical number seven: Still magic after all these years? Psychological Review, 101, 353-356.
• Miller, G. A. (1956). The magical number seven plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 81-97

Article by: Susan Weinschenk
Originally published on What Makes Them Click on 25.10.2009
Translated by Victor Malyi (UX-UA)

Автор статьи: Linda Bustos
Оригинал статьи опубликован в Get Elastic (25.06.2010)

В оптимизации «посадочных» страниц «трение» (фрикции, разногласия. Англ.- friction) подразумевает «психологическое сопротивление к элементу, поданному в процессе продаж, которое вызывает усталость и запутывает мышление», в соответствии с Marketing Experiments доктора Флинта МакГлафлина (Dr. Flint McGlaughlin). Целью «e-commerce-оптимизатора» является уменьшение этого сопротивления на столько, на сколько это возможно.

Где опыт клиентов сопротивляется вашему процессу продаж? Давайте проверим некоторые общие части сайта.

Главная страница

1. Страницы, которые медленно загружаются

Как было показано недавно на Forrester Research, 2 секунды – это новый приемлемый порог скорости загрузки страницы. Медленная загрузка вэб-сайтов приводит к потерям в онайлн-продажах. 40% пользователей заявили, что они покинут сайт, загрузка которого заняла более 3х секунд.  79% недовольных  пользователей утверждают, что вряд ли будут совершать покупки на сайте снова. 75% сказали, что их возвращение на сайт маловероятно. Таким образом, вы должны приложить все усилия, чтобы ускорить ваш сайт. Такие услуги как Akami, Strangeloop и Gomez могут помочь вам уменьшить время загрузки вашего сайта. Воспользуйтесь Website Performance Tester от Strangeloop, чтобы увидеть, насколько быстрее сможет стать ваш сайт после оптимизации.

Если хотите больше советов по ускорению вашего сайта, тогда смотрите запись нашего вэб-семинара Every Second Counts: How Website Performance Impacts Shopper Behavior (Каждая секунда на счету:  как эффективность сайта воздействует на поведение покупателей) и 25 Ways to Speed Up Your Website (25 способов ускорить ваш сайт) от Джастина Палмера.

2. Где здесь панель поиска?

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

3. Слишком большой выбор

У вам МОЖЕТ быть слишком много хороших вещей, просто спросите у Барри Шварца (а ещё лучше, посмотрите TED, в котором он говорит о парадоксе выбора.

Навигационное меню

4. Боковые панели

Мы приучены искать навигационные элементы в горизонтальном меню в верхней части страницы или же в вертикальном меню вдоль её левого края. Избегайте размещения важной информации и призывов к действию в правой части страницы. Доктор Флинт МакГлафлин, который провёл тысячи экспериментов, связанных с конверсией и юзабилити, утверждает: “не размещайте в правой боковой панели ничего, если только вы не хотите, чтобы оно осталось незамеченным” (“don’t put anything in right hand sidebars unless you don’t want [people] to see it.”)

Очень досадно, когда на ecommerce-сайтах важная информация и призывы к действию выглядят как Google AdSense.

5.  Навигация по “надгробным плитам” (Tombstone navigation)

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

После большого количества пользовательских тестов Amazon поменял “надгробия” на мегаменю в 2007м году.

Поиск по сайту

6. Проверка на опечатки и поиск синонимов

Нет ничего более ужасного, чем сообщение “поиск дал 0 результатов”

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

Страницы каталога

7. Отсутствие навигационных фильтров

Чем больше ваш каталог, тем важнее фильтры для юзабилити вашего сайта. Помните, что некоторые люди являются так называемыми “howsers” (сокращённо от “hunter-browsers” – нечто среднее между категорией пользователей, которые точно знают, что ищут (охотники), и теми, кто зашёл на сайт поразглядывать товар. Прим. переводчика). Они ищут что-то конкретное, но предпочитают использовать навигационные меню, а не возиться с панелью поиска. Навигационные фильтры помогают как “howsers”, так и обычным посетителям, которые изучают каталог, найти товар, соответствующий ихним запросам.

8. Крошечные изображения товаров

Когда уменьшенные изображения товаров слишком малы для того чтобы показать детали, пользователь должен переходить на страницу товара, чтобы рассмотреть его получше. Используя AJAX эффект наведения, вы можете решить данную проблему – инструменты “быстрого просмотра” (Quick Look) дают возможность пользователям  увидеть более подробную информацию о товаре и добавить его в корзину, не покидая страницы каталога.
Quick Look:

Карточка товара

9. Незаметная кнопка “Добавить в корзину” (или текст на ней слишком сложно прочесть)

A/B-тестирование дизайнов кнопки “В корзину” является хорошим решением, поскольку оно дало положительные результаты для очень многих ecommerce-сайтов. Как правило, большие кнопки смелых цветов, которые контрастируют с фоном сайта, будут работать эффективнее маленьких кнопок с простым дизайном. Легенда оптимизации конверсий Браян  Эйзенберг (Bryan Eisenberg) также говорит о том, что кнопки необычной формы работали лучше на тех сайтах, которые ему довелось тестировать.

10. Добавил ли я товар в корзину?

Иногда изменения в корзине происходят настолько незаметно, что пользователь не может понять, действительно ли они произошли. Я представил множество примеров в своей статье Что означает “Продолжить покупки”?. Если вместо того чтобы отправиться на страницу корзины, ваш клиент остаётся на странице с описанием товара, вы должны убедить его в том, что вещь была успешно добавлена. Nine West является хорошим примером:

11. Неуместные кросс-продажи

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

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

Страница корзины

12. Куда я попаду по нажатию кнопки “Продолжить покупки”?

Я упоминала статью Что означает “Продолжить покупки”?, в которой предлагаются различные способы использования ссылки “Продолжить покупки”. В зависимости от ассортимента вашей продукции, перебрасывание посетителей на главную страницу сайта может быть не самым лучшим решением (к примеру, если вы продаёте мобильные телефоны и аксессуары, то вы можете вернуть посетителя на страницу, которая содержит аксессуары к телефонам).

Формы регистрации и авторизации

13. Запрашивается слишком много информации

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

14. Дизайн форм

Как и в случае с кнопкой “В корзину”, доказано, что дизайн форм также влияет на уровень конверсии. Вот пример того, как редизайн увеличил показатель заполнений формы на 200%.

Изображение взято с Web Design 4 ROI

Скачайте пример главы про дизайн и оптимизацию форм из книги Web Design 4 ROI

Процесс оформления заказа

15. Избегайте ценового шока

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

Загляните в статьи Джастина Палмера (Justin Palmer) Потеря клиентов при регистрации: 12 ошибок процесса оформления заказа и Как уменьшить показатель отказов корзины: 10 размышлений, чтобы найти больше советов.

Посадочные страницы

16. Сохраняйте аромат

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

17. Улучшайте “Страницу 404”

Отправка пользователей на “страницу 404”, которая не содержит никаких ссылок для возврата на сайт, схожа с катапультированием их в открытый космос.

Вот лучший способ справиться со сложившейся ситуацией:

Несколько советов по созданию “404й страницы”

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

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

Author: Linda Bustos
Originaly published in Get Elastic (25.06.2010)

Автор статьи: Steve Psomas
Оригинал статьи опубликован в UXMatters (05.11.2007)
Перевод статьи: Виктор Малый (UX-UA)

На протяжении моей карьеры UX-дизайнера, я постоянно задавал себе три вопроса:

• Что является результатом моей работы?
• Будут ли эти результаты легкими для восприятия мною и теми людьми, для которых они предназначены?
• К какой из областей UX можно отнести мои результаты работы?

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

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

Информационная архитектура

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

• Каковы приоритетные цели пользователей, и как они могут достичь их, используя приложение?
• Как пользователи переходят от одного модуля приложения к другому?
• Какие правила работы с приложением есть у пользователя?
• Как и насколько модули приложения узнаваемы пользователем?
• Как UI-роадмэп и роадмэп продукта позиционирует продукт на рынке?
• Как сделать так, чтобы пользователи работали с несколькими объектами одновременно в пределах одного приложения?
• Какой механизм поиска используется в приложении?

Главным образом, информационная архитектура представляет собой базис для всех остальных компетенций UX – посмотрите на основные аспекты работы в пределах ИА и на необходимые результаты работы на рис 1.

рис. 1

Проектирование взаимодействия

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

Вопросы, которые касаются работы проектировщика взаимодействия следующие:

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

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

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

рис. 2

Юзабилити

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

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

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

рис. 3

Графический дизайн

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

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

рис. 4

Разработка прототипов

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

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

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

рис. 5

Почему эти пять компетенций UX важны?

Для команды UX-специалистов, это деление на компетенции вносит ясность в должностные обязанности каждого. Ну, а если вы единственный подобный специалист в своей компании (как я), использование этого фреймворка еще более важно – вы сможете держать у себя в голове все необходимые практики, независимо от того, к какой компетенции они принадлежат.

Выделение своих сильных и слабых мест

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

Для примера, если взять оценочную шкалу от 1 до 7, я неплохо разбираюсь в информационной архитектуре и юзабилити, поэтому я поставил бы себе оценку 6 для этих компетенций. Чувствую, что по проектированию взаимодействия, я близок к оценке 5. То, что я неплохо разбираюсь в графическом дизайне, но, при этом, не имею никакой профессиональной подготовке в этой сфере, дает мне возможность поставить оценку 4 для этой дисциплины. Когда-то я очень хорошо разбирался в JavaScript и также считаю себя экспертом в HTML/CSS, но так как в данный момент мне немного не хватает опыта в разработке высокоинтерактивных прототипов, я поставлю себе, как разработчику прототипов, оценку 4. Исходя из всего этого, мои сильные места это информационная архитектура, тестирование юзабилити и проектирование взаимодействия.

А что у тебя?

Определение и проретизация своей рабочей нагрузки

Что конкретно остальные члены команды хотят получить от тебя в качестве результатов работы? Наброски страницы? Прототип? Может быть, картинку или таблицу? Каждый из этих результатов работы требует использования одной из 5 компетенций UX. Когда я заранее знаю о том, сколько времени у меня уйдет на получение результата и, сопоставляя это с моими аналитическими и творческими способностями, я могу полностью посвятить себя этому заданию, или, наоборот изменить его приоритет.

Определение затрат времени на результат

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

Понимание зависимостей

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

Набор персонала

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

Всегда иметь свежий взгляд

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

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

Article by: Steve Psomas
Originally published on UXMatters on 05.11.2007
Translated by: Victor Malyy (UX-UA)

Автор статьи: Whitney Hess
Оригинал статьи опубликован в UXMag (21.08.2010)
Перевод статьи: Виктор Малый (UX-UA)

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

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

Пол Грехем (Paul Graham) – инвестор и соучредитель фонда поддержки стартапов Y Combinator.
Нэйт Вестхаймер (Nate Westheimer) – соучредитель и исполнительный вице-президент AnyClip и Гэби Мур (Gabi Moore) – старший дизайнер из AnyClip.
Эндрю Кортина (Andrew Kortina) – соучредитель Venmo.
Майк Синглтон (Mike Singleton) – разработчик Foursquare.

Вопрос №1: что User Experience означает для вас?

Пол Грехем

Это то, что связано с использованием чего-то. UX – это в общем более глубокое понятие, чем графический дизайн.

Нэйт Вестхаймер

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

Гэби Мур

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

Эндрю Кортина

UX – это все! User Experience – это каждая часть Venmo. Каждый раз, когда вы занимаете или отдаете деньги, этот процесс может быть слегка неловким – особенно, когда речь идет о друзьях. Это может быть трудным – думать о деньгах, когда вы вместе со своими друзьями. Мы хотим сделать взаимодействие с Venmo лучше, и, более того, процесс общения с друзьями легче, потому что в это время у вас нет необходимости думать о деньгах.

Майк Синглтон

User Experience – это способ, благодаря которому пользователи взаимодействуют с продуктом. Foursquare – социальный проект. Его особенность заключается в том, чтобы не отрывать пользователя от привычных дел и быть как можно более незаметным. Да, некоторые другие продукты пытаются сделать процесс взаимодействия с ними заметным. Но для нас, если пользователи замечают этот процесс – это ошибка. Мы хотим, чтобы все они взаимодействовали с приложением миллионы раз в день, и никто этого не замечал.

Вопрос №2: когда вы впервые столкнулись с термином «UX»?

Пол Грехем

Прямо сейчас, когда я понял что это аббревиатура для «User experience».

Нэйт Вестхаймер

Похоже, я впервые узнала об этом из блогов, подобных блогу 37signals, который я активно читала, когда только-только начинала свою деятельность в интернет-индустрии. Я стала думать больше об этом после встречи с тобой и чтения твоего блога, а также от знакомых типа тебя, которые кричат налево и направо о User Experience.

Гэби Мур

Наверное, это было два года назад, когда я только приехала в Нью-Йорк. В Бразилии же, я никогда не слышала об этом. Когда я оказалась здесь, то сразу обратилась к книгам, чтобы понять ситуацию с UX в США. По-моему, это была книга Designing with web standards от Jeffrey Zeldman’a, или Transcending CSS от Andy Clark’a.

Эндрю Кортина

Я уже когда-то слышал о пользовательском взаимодействии, но по-настоящему задумался об этом после выступления Kathy Sierra на SXSW два года назад: она говорила о том, как сделать так, чтобы пользователи чувствовали себя здорово с приложением. Делать такие вещи, которые можно легко использовать – вот еще одно объяснение UX.

Майк Синглтон

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

Вопрос №3: какую роль играет UX в вашей компании?

Пол Грехем

UX играет важную роль в процессе в процессе поддержки Y Combinator’ом стартапов. Мы подталкиваем их на то, чтобы разработать хотя бы самую маленькую часть функционала и дать ее пользователям на растерзание как можно быстрее.

Нэйт Вестхаймер

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

Гэби Мур

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

Эндрю Кортина

Мы постоянно отслеживаем поведение пользователей: как они используют продукт и как реагируют на те или иные факторы. Я всегда просматриваю log-файлы для того, чтобы знать что происходило на сайте. Мы обращаем очень много внимания на то, как люди отзываются о продукте по e-mail и стараемся отреагировать на их нужды как можно быстрее. Если никто не приемлет какого-то конкретного нашего решения – мы не будем его использовать.

Майк Синглтон

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

Вопрос №4: каким было самое большое изменение в вашей практике, на которое вас натолкнуло UX?

Пол Грехем

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

Нэйт Вестхаймер

Самым большим изменением было разделение задач для персон. Для того большинства пользователей, которые не собираются вводить большой поисковый запрос, мы логично дополним его своими данными, даже если мы не на 100% правы. В то же время для тех, кто предпочитает вводить более точные данные, это будет также реализовано. Через пользовательское тестирование и даже анекдоты мы поняли, что поисковая часть нашего сайта очень расстраивала наших пользователей. Мы понимаем что не можем угодить всем и сразу, и поэтому подстраиваемся под пользователей с разными потребностями.

Гэби Мур

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

Эндрю Кортина

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

Майк Синглтон

Для большинства стартапов UX – это роскошь. В самом начале нашего пути Dennis [Crowley, соучредитель Foursquare's] делал все самостоятельно. В какой-то мере, мы должны бы стукнуть его за это: в предверии SXSW мы сделали большое количество изменений в продукте, таких как расположение кнопок, надписей… Мы знали, что на этом мероприятии сможем привлечь много новых пользователей, и необходимо было сделать это правильно. Однако наняв менеджера продукта и UX-специалиста Alex’a Rainert’a, теперь нам придется все это переделать согласно его рекомендациям.

Вопрос №5: какой совет вы дадите компаниям, которые интегрируют UX в процесс своей работы?

Пол Грехем

Всегда увлекайте пользователей.

Нэйт Вестхаймер

Найдите вашего UX-чемпиона. Нашим подходом, который ориентирован для пользователей, а также становлением пользовательских нужд на первое место мы обязаны Гэби. Она как полицейский на той, пользовательской стороне. Это очень здорово для нас! Изначально мы «выживали» на опыте и публикациях в блогах, благородно предоставленных экспертами в области UX. Скажу, что User Experience может быть использован разными способами, но на ранней стадии жизни продукта, он должен быть применен людьми, которые просто захвачены им – теми самыми UX-чемпионами.

Гэби Мур

У стартапов нет возможности быть идеальными в плане UX – вы просто не можете пользоваться услугами большого количества специалистов, которые необходимы для создания действительно классного продукта. Но что-то – это всегда лучше чем ничего. Если у вас нет возможности иметь User Experience-специалиста на полной ставке, есть отличный выход иметь консультанта на регулярной основе – человека, который будет приходить к вам раз в месяц на пару часов, смотреть на ваши прототипы и обсуждать решения, которые вы принимаете – то есть, получить сторонний профессиональный взгляд на то, что происходит с вашим продуктом. Это то, что мы сделали с Lis Hubert. Она помогла привнести пользователей в процесс проектирования. Да, это так очевидно, но у нас небыло этого до ее прихода.

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

Эндрю Кортина

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

Майк Синглтон

UX помогает тебе осознать то, что твой разум далеко не всегда корректен, и ты не можешь знать все про всех – он показывает на то, что нужно изменить себя.
Это сложно. Если вы – действительно маленький стартап, то нет никаких свободных ресурсов на UX. Но как только они будут доступны, начинайте работать с UX сразу же.

Спасибо большое Полу, Нэйт, Гэби, Эндрю и Майку за то, что они поделились своими знаниями с нами. Будем надеяться, это поможет маленьким компаниям понять цели и ценности UX, и вдохновит на то, чтобы начать работать в этом направлении как можно скорее.

Article by: Whitney Hess
Originally published on UXMag on 21.07.2010
Translated by: Victor Malyy

Автор статьи: Susan Weinschenk
Оригинал статьи опубликован в What Makes Them Click (26.10.2009)

Приходилось ли вам когда-либо решать какой ширины текст отображать на экране? Сделать широкую колонку на 100 символов, или короткую на 50?

Оказывается, ответ зависит от того, хотите ли вы, чтобы люди прочитали текст быстрее или, чтобы страница им понравилась!

Исследование (посылание ниже) показало, что 100 символов в строке это оптимальная длина для быстрого чтения с экрана; но это не то, что предпочитают люди. Мы читаем быстрее длинные строки (около 100 символов) но предпочитаем более короткие (от 45 до 72 символов). Например, в the New York Times Reader длина строки составляет в среднем 39 символов.

Исследование также показало, что люди быстрее могут прочитать одну широкую колонку текста, чем несколько коротких, но они все равно предпочитают несколько коротких (как в примере с New York Times Reader).

Итак, если спросить у кого-то, что им нравится больше, то они ответят “несколько коротких колонок” и, что интересно, они будут настаивать, что быстрее читать выходит так же много коротких, хотя данные говорят об обратном.

Так как поступить? Дать людям то, что они хотят или пойти против их предпочтений и интуиции, зная, что с более длинными строками они будут читать тексты быстрее?

Что бы вы сделали?
__
Dyson, M.C. (2004). “How Physical Text Layout Affects Reading from Screen.” Behavior & Information Technology, 23(6), pp. 377-393.

Article by: Susan Weinschenk
Originally published in What Makes Them Click (26.10.2009)

Article by: Jared Lewandowski
Originally published in UXMag (25.10.2009)
Translated by: Victor Malyy (UX-UA)

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

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

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

Добейстесь доверия

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

Постройте отношения

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

Собирайте результаты

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

Делитесь своим процессом

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

Создание прототипов совместно с клиентом может существенно увеличить общую скорость работы над проектом

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

Конечная версия прототипа

Покажите клиенту как это будет работать

Следующим этапом идет создание интерактивных прототипов, которые представляют в себе взаимодействие пользователя с приложением и верстку. Очень важно дать клиенту взглянуть на подобный прототип как можно раньше и дать ему увидеть то, что, в последствии, увидят его пользователи. Немаловажным также будет представить функциональность отдельных элементов прототипа. Например, показать как будет вести себя кнопка при наведении на нее курсора мыши, как изменится график после того, как пользователь изменить входные параметры и как все это будет выглядеть в разных браузерах. Это очень важные вещи, которые, к сожалению, иногда тяжело передать через Photoshop, Word или OmniGraffle .

Окончание проекта

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

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

Автор статьи: Jared Lewandowski
Оригинал статьи опубликован в UXMag (25.10.2009)
Перевод статьи: Victor Malyy (UX-UA)

Article by: Luke Wroblewski
Originally published on UXmatters on 03.11.2008
Translated by: Victor Malyy (UX-UA)

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

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

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

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

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

Вероятно, это заблуждение произрастает из общих представлений людей о дизайне в индустриальном веке – стиль программных продуктов начал создаваться в до этого невозможных способах, и такие дизайнеры как Реймонд Лои (Raymond Lowey), получили признание за их эстетический подход к дизайну еще недавно «бледных» продуктов.

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

• Что это?
• Как это можно использовать?
• Почему меня это должно заботить?

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

На рисунках 1, 2 и 3 присутствует общий набор элементов, характерный для любого веб-приложения. Кроме того, все эти элементы содержат в себе одинаковый набор шрифтов, цветов, градиентов и изображений. Главным отличием этих трех вариантов дизайна является визуальная организация элементов. Это различие показывает три возможных приоритетных варианта использования приложения.

Рисунок 1: изначальный дизайн веб-приложения

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

Рисунок 2: то же веб-приложение с иной визуальной организацией элементов

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

Рисунок 3: другой подход к визуальной организации элементов все того же приложения

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

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

Можешь сделать это большего размера?
Как уже неоднократно доказано сайтами подобными make my logo bigger, заказчики часто просят визуальных дизайнеров придать выраженности каким-то элементам страниц. В то самое время, когда такие действия оправданы для определения самых важных элементов страницы, они также демонстрируют другое заблуждение о визуальном дизайне: чтобы улучшить графический дизайн веб-сайта, необходимо сделать некоторые его элементы больше, выразительнее, и, например, красными – или, в некоторых случаях, применить все эти способы одновременно.

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

Если вы учтете просьбы всех тех, кто хочет сделать что-то “больше и ярче”, у вас есть все шансы для того, чтобы сделать интерфейс с элементами, каждый из которых равнозначно перетягивает внимание пользователя на себя – и, как результат, ни один из этих элементов не будет работать вообще. Заметьте разницы в дизайне страниц загрузки для двух разных браузеров, показанных на рисунках 4 и 5. Firefox имеет явный вызов к действию загрузки браузера, а также остальные элементы страницы, связан

Рисунок 4: страница загрузки Firefox

Страница загрузки Flock’а, показанная на рисунке 5, имеет в себе так много выделяющихся элементов, что команда решила внести целых 4 вызова к действию загрузки браузера – в правом верхнем углу страницы, в нижней части меню, расположенного слева, в правой верхней части горизонтальной новостной панели и в футере. Если бы на этой странице не было так много выделяющихся элементов, Flock вполне мог бы обойтись одной кнопкой для загрузки браузера – как у Firefox.

Рисунок 5: страница загрузки Flock

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

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

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

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

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

Рисунок 6: главная страница eBay Italy

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

Если вы заметили какие-либо заблуждения о роли визуального дизайна в вашей профессиональной жизни, или готовы поделиться положительным опытом, который демонстрирует истины визуального дизайна, сделайте это в комментариях ниже!

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

Автор статьи: Luke Wroblewski
Оригинал статьи опубликован в Uxmatters (03.11.2008)
Перевод статьи: Виктор Малый (UX-UA)