История развития интерфейса Microsoft Office

На сайте MIX: The Next Web Now появился видео ролик (презентация) рассказывающий о истории эволюции интерфейса Microsoft Office, а так же о том, как создавался интерфейс для Office 2007. Рассказывает обо всем Дженсен Харрис – один из дизайнеров пакета Office 2007.

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

Посмотреть ролик можно на сайте MIX: The Story of the Ribbon там же можно и скачать его в разных форматах (WMV, iPod). В любом случае потребуется установить SilverLight. Можно так же скачать его и из блога Харриса, но на сам сайт MIX лучше зайти, там есть еще много интересных видео.

Тестирование шаблонов web-страниц

В блоге QA Focus, поддерживаемой организацией UKOLN, опубликован документ “Layout Testing with Greeked Pages”. В нём описываются основные принципы тестирования дизайна web страниц в условиях, когда еще неизвестен ни контент, ни конкретное количество элементов навигации, управления, но нужно протестировать сам дизайн. Сам принцип использования «греческого» текста для юзабилити тестирования был изложен еще в 1998 году Якобом Нильсеном (Jakob Nielsen). Сам по себе способ очень прост и состоит из трёх этапов. Перед которыми следует разработка самого прототипа и определение количества и вида элементов, которые должны присутствовать на странице.

1. Наполнение контентом готового дизайна. Для этого не обязательно делать верстку страницы, достаточно графического прототипа. Для наполнения контентом, в том числе определения заголовков элементов навигации, используется кусок текста из трактата Цицерона «О пределах добра и зла»:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

Хотя, как пишет Артемий Лебедев, этот текст очень сильно отличается от оригинала текста, и стоит быть осторожным при использовании онлайн генераторов “Lorem Ipsum”, поскольку неизвестно кем и почему изменялся этот текст и что действительно означают эти изменения и почему dolorem ipsum стал lorem ipsum.

2. Тестирование. Подготовленный дизайн проект, вариантов должно быть не менее двух, раздается группе людей, которые будут проводить юзабилити тестирование. При этом порядок следования прототипов рекомендуется изменять, чтобы исключить психологические аспекты. Количество людей должно быть не менее шести, по рекомендации Нильсена, но, на мой взгляд, стоит взять, по меньшей мере, дюжину. Будет очень хорошо, если тестовая группа будет содержать людей разного возраста и пола. Каждый человек, из тестирующей группы, работая с прототипом должен распознать заложенные дизайнером элементы на странице. После этого он выставляет оценку каждому прототипу. Шкала оценок может быть как от 0 до 5, так и от -3 до 3 и так далее – все зависит от фантазии и интерпретации данных. Соответственно эта оценка объективной, скорее всего, не будет, но она поможет определить общее настроение пользователей.

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

Прототип Определено элементов Субъективная оценка
1 N % (например 65%) # (например 5 из 10)
2 M % (например 70%) # (например 6 из 10)

На основе полученных результатов можно получить действительно интересные вещи.

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

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

Видимая простота вредит продажам

Сегодня наткнулся на очень интересную статью Дона Нормана “Простота слишком перехвалена” (Don Norman, “Simplicity Is Highly Overrated“) и следующий за ней очерк Джоэля Сполски (Joel Spolsky, “Simplicity“). Норман рассказывает о своих наблюдениях по поводу того, как люди покупают высоко-технологичные вещи. Как оказалось покупателю куда интереснее взять что-либо (от тостера до автомобиля) напичканное электроникой и элементами управления, чем то же самое, и выполняющее те же функции, но одной кнопкой. Например, что вы выберете – кофеварку с ЖК экранчиком или без? А если экранчик будет цветной? В результате и появляется вывод, что “Простота слишком перехвалена”. Покупателю нужно то что выглядит сложным и многофункциональным, в случае выбора между одинаковым товаром . Сполски переносит это в область разработки программного обеспечения.

Мне не понятно, откуда взят принцип “80/20” – 80% пользователей используют, только 20% функций программы. Но вместе с тем правильна, на мой взгляд, мысль о том, что чем больше функций в программе, тем более она привлекательна для покупателя, даже если ему не нужна и половина возможностей. Хотя даже, если в программе реализовано огромное количество функций, доступных пользователю, это не является залогом привлекательности – принципа «всё одной кнопкой» никто не отменял. В результате для любой программы, если есть желание сделать её успешной, нужно проводить исследования по тему – кто и как использует предложенную функциональность.

То есть, для shareware проектов подойдёт такой сценарий:

1. Задумка

2. Реализация первой версии (с минимально необходимым набором функций)

3. Подготовка web-сайта с разделами after install, feedback, after uninstall. Последние два для сбора отзывов от пользователей.

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

5. Наращивание функциональности.

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

When a new version comes out with new features, we see a sudden, undeniable, substantial, and permanent increase in revenue.

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