С чего начать
Многие приходят к UX из смежных областей. Эти «перебежчики» – люди, которые продвигают UX, выводя его на новые уровни и внедряя в новые организации.
Изучение UX часто кажется чем-то принципиально новым. Для многих это открытие становится почти откровением, будто они долго искали и нашли наконец свое призвание. А поскольку такие моменты вызывают сильное воодушевление, «перебежчики» часто становятся самыми большими энтузиастами UX. Они могут приходить из сферы инженерии, визуального дизайна, технической литературы и управления проектами. Другие области тоже встречаются, это сообщество отличается разнообразием. Для многих «перебежчиков» реальность такова, что UX или удобство использования являются и будут оставаться лишь частью того, чем они занимаются. Но даже это не отпугивает человека от перехода в UX. Многие опытные профессионалы в области UX начинали с того, что увидели возможность что-то улучшить и воспользовались ею. В этой главе вы найдете основную структуру для погружения в тему. На самом деле, слово «структура» может оказаться слишком громким. Это всего лишь четыре простых шага.
1. Ознакомьтесь с инструментарием UX.
2. Сформируйте свою точку зрения на то, что можно улучшить.
3. Ближе познакомьтесь с пользователями.
4. Приступайте к разработке.
Ознакомьтесь с инструментарием UX
Для того чтобы проиллюстрировать набор предложений UX, создается множество моделей и диаграмм, помогающих понять процессы UX и то, как оно сочетается с другими бизнес-процессами в каждом конкретном случае (рис. 2.1–2.5)[6].
На рис. 2.1 приведена модель, созданная Тоддом Заки Варфелем во время его работы в компании Message First. Эта модель представляет собой последовательный обзор действий, которые выполняются в ходе типичного процесса разработки дизайна, ориентированного на пользователя. В ней можно увидеть полезные различия между функциональным дизайном, контент-анализом, дизайном взаимодействия и информационной архитектурой, а также инженерией.
С другой стороны, в модели, приведенной на рис. 2.2, разработанной Дэвидом Армано из компании Edelman Digital, сделан больший акцент на основных концептуальных этапах работы, которые вы проходите в процессе разработки дизайна, ориентированного на пользователя. Использованная в этой модели структура «Раскрой > Определи > Представь себе > Собери > Спроектируй» (Uncover > Define > Ideate > Build > Design) хороша тем, что помогает вам на каждом этапе планировать цели более высокого уровня.
Рис. 2.1. Модель UX Тодда Заки Варфеля
Рис. 2.2. Модель UX Дэвида Армано
Рис. 2.3. Модель UX от компании Namahn Design
Рис. 2.4. Модель UX Стивена П. Андерсона
Рис. 2.5. Модель UX Джеймса Келвея
На рис. 2.3 показана модель, созданная в брюссельской компании Namahn Design. Выполненная в стиле карты лондонского метрополитена, она демонстрирует взаимосвязь между конкретными методами и действиями.
Модель на рис. 2.4, предложенная независимым консультантом Стивеном П. Андерсоном, представляет собой другой способ визуализации процесса UX и сфокусирована не столько на этапах или результатах, сколько на основных соображениях, которые следует учитывать при проектировании UX.
Как и многие предыдущие модели, приведенная на рис. 2.5 модель Джеймса Келвея из датской дизайнерской фирмы Hello Group демонстрирует ключевые этапы и действия или результаты в рамках каждого такого этапа или действия, однако они показаны схематично и не слишком точно.
Как я стала «перебежчиком»
Вот как я открыла для себя UX. В детстве я всегда хотела стать писателем. Окончив колледж, устроилась на работу в, казалось бы, самой логичной для меня сфере – начала работать в журнале. Проблема в том, что редактировать тексты оказалось невыносимо скучно. Но нашлось в моей работе и то, что мне нравилось, – обновление веб-сайта, благо в колледже я приобрела базовые навыки работы с HTML. Вскоре я обнаружила, что мое любимое время на работе – то, которое я провожу на сайте. И тогда я решилась сменить курс и стать полноценным веб-специалистом.
Я разместила в интернете свое резюме, и со мной быстро связался рекрутер из одной фирмы. Это было во время пузыря доткомов 1990-х годов, и навыки в области HTML – даже элементарные – пользовались большим спросом. Несколько лет я работала программистом интерфейсов, но никак не могла избавиться от мысли, что на самом деле предпочла бы то, чем занимаются люди с забавной должностью «специалист по информационной архитектуре». Не писать программный код, а думать о различных штуках с общечеловеческой точки зрения и проектировать интуитивно понятные системы. Поэтому я вновь села за парту, чтобы изучить информационную архитектуру. Продвигаясь к степени магистра, я получила, как теперь понимаю, свой первый опыт работы в монокоманде. Моя должность теперь называлась «разработчик инструментов», и работала я в небольшой узкоспециализированной конторе, помогавшей юридическим компаниям управлять базой данных, необходимых для анализа заявлений о банкротстве, подаваемых разными фирмами. Потрясающая штука. Меня наняли, по-видимому, благодаря моим техническим навыкам, но им понравилось и то, что я интересовалась также дизайном и удобством использования.
Это была хорошая площадка для тренировки, потому что массе интереснейших приложений, разработанных самой компанией, требовалась серьезная помощь в области UX. Это было прекрасное место, чтобы проверить принципы, которые я только что изучала. Я разработала множество программных интерфейсов. Я размышляла о решениях проблем навигации по большим хранилищам информации. Я проводила тестирование удобства использования. Кроме того, это была прекрасная возможность узнать, как посредственно другие люди понимают концепцию дизайна, ориентированного на пользователя, и как мало они ее ценят. Или, точнее говоря, я поняла, что необходимо делать, чтобы люди расставляли приоритеты в потребностях пользователей и дизайне при решении множества различных фундаментальных и неотложных бизнес-проблем. Наконец, именно там я получила серьезный урок: оказалось, что не все компании нуждаются в монокоманде или готовы с ней работать. Это нормально. В конце концов я поняла, что пришло время двигаться дальше. Полученный опыт я с успехом применила в своей следующей работе – это была также монокоманда, однако я добилась гораздо лучших результатов.
Итак, какие навыки помогли мне в этом? Их, в общем, немного.
• Знакомство с концепцией UX
• Интерес к тому, как люди думают, понимают и видят
• Некоторые технические ноу-хау
• Благоприятная среда для работы и практики
• Уровень образования, достаточный для подпитки стремления экспериментировать
Из приведенных примеров видно, что, хотя не существует сертифицированного процесса, который соблюдают все специалисты по UX, существует относительно стандартный набор действий и результатов. Большая UX‑команда может позволить себе роскошь выполнять большинство этих действий в рамках конкретного задания. Монокоманды тоже используют многие из описываемых методов, но не столь глубоко, или ограничивают их количество в полноценном рабочем плане. Однако для начала вам будет полезно понять весь набор опций, а затем уже решать, какие из них кажутся наиболее полезными в вашей работе.
⚓ ЕСЛИ ВАМ НУЖНА ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ ОБ ЭТИХ МЕТОДАХ
Большинство приведенных здесь методов более подробно описаны во второй части этой книги – «Практика».
Далее приводится почти исчерпывающий список действий, которые могут выполняться в типичном процессе UX.
• С чего начать. Узнайте, на каком этапе работа и что вам нужно делать, чтобы разработать продукты, отвечающие потребностям бизнеса.
• Беседы с заинтересованными сторонами. Поговорите с теми, кто принимает решения, чтобы понять, чего они ждут от продукта, а также получить любые другие важные сведения, которые вам следует иметь в виду при работе. (См. «Сбор мнений» в главе 5 «Методы планирования и исследования возможностей», там описан упрощенный способ проведения беседы с заинтересованными сторонами.)
• Анализ сильных и слабых сторон, возможностей и угроз (SWOT). Различные методы оценки сильных и слабых сторон, возможностей и угроз, влияющих на UX продукта. В эту категорию попадают некоторые UX‑методы, первоначально разработанные как инструмент стратегического планирования, такие как обзор конкурентов, контент-аудит, а также эвристический или экспертный анализ. (См. «Изучение возможностей» в главе 5, где описан инклюзивный метод сбора SWOT-информации с помощью команды.)
• Сбор требований. Работа с теми, кто принимает бизнес-решения, и другими членами команды для определения того, что должен содержать продукт и, в некоторых случаях, как это реализовать. (См. «Семинар по стратегии» в главе 5, где описан метод выявления явных и неявных требований.)
• Стратегия. Определение целевой направленности UX. Это позволит вам разрабатывать связные и унифицированные продукты.
– Принципы дизайна. Несколько характеристик, которые в совокупности воплощают то, как дизайн продукта должен восприниматься пользователями. (Для получения дополнительной информации см. «Принципы дизайна» в главе 7 «Методы разработки дизайна».)
– Визуальное представление. Диаграммы, схемы, раскадровки или видеоролики, которые передают суть UX и дают представление, как человек может воспринимать продукт, созданный в соответствии с этой стратегией, в контексте своей обычной жизни. (См. «Семинар по стратегии» в главе 5, а именно советы по планированию, чтобы узнать, как с помощью вашей команды создавать визуальное представление с низкой точностью.)
– Дорожные карты. Анализ того, что необходимо сделать сначала, в середине и в конце, чтобы создать требуемое восприятие.
• Исследование пользовательской аудитории. Узнавайте как можно больше о ваших пользователях и об их мотивациях, чтобы разрабатывать продукты, отвечающие потребностям целевой аудитории.
– Первичное исследование пользовательской аудитории. Различные методы изучения пользователей на основе информации из первых рук. Могут включать полевые исследования[7], изучение дневников, опросы и другие формы партизанских исследований. (См. «Партизанское исследование пользователей» в главе 6 «Методы исследования», где можно найти быстрые и полезные советы по проведению первичного исследования пользовательской аудитории.)
– Вторичное исследование пользовательской аудитории. Анализ совокупности сторонних исследований, проведенных среди группы ваших предполагаемых пользователей. Может включать в себя общедоступные исследования или исследования, проведенные другими подразделениями организации. (Маркетинговая сегментация – одна из наиболее полезных форм вторичного исследования пользовательской аудитории для специалистов по UX, поэтому, если ваша организация занимается сегментацией, обязательно начните именно с нее.)
– Персоны, ментальные модели и истории пользователей. Документы, обобщающие все, что вы узнали о пользователях в ходе первичных и вторичных исследований, и объединяющие ключевые моменты в несколько запоминающихся профилей со вспомогательными диаграммами и историями о том, как продукт должен войти в их жизнь. (Подробнее о персонах см. раздел «Протоперсоны» в главе 6. Книга Инди Янга Mental Models («Ментальные модели») может служить другим прекрасным источником информации по ментальным моделям.)
• Дизайн. Предвидение и спецификация того, как создать наиболее гибкое, интуитивно понятное и приятное общение пользователя с продуктом или услугой в любое время.
– Информационная архитектура / карта сайта. Документы по организации системы, включающей основные группы, категории или разделы, а также прочие подобные информационные структуры: возможности поиска, таксономия, теги или иные формы метаданных. (Всеобъемлющий текст Луиса Розенфельда и Питера Морвиля «Информационная архитектура в Интернете»[8] (Information Architecture for the World Wide Web) позволит вам узнать много нового об информационной архитектуре.)
– Диаграммы процессов и задач. Пошаговые модели того, как пользователи будут взаимодействовать с системой и как система будет адаптироваться или реагировать в зависимости от действий пользователя. (Дополнительную информацию см. в разделе «Потоки задач» в главе 7.)
– Вайрфреймы[9]. Схематические изображения каждой страницы или состояния системы. Как правило, в вайрфрейме указывается каждый экран пользовательского интерфейса. (Дополнительную информацию см. в разделе «Вайрфреймы» в главе 7.)
– Макеты страниц. Детальное визуальное оформление каждой страницы или состояния системы. Если в вайрфреймах экраны показаны на схематическом уровне, то на макетах страницы показаны именно такими, какими они должны выглядеть при реализации, включая визуальные эффекты вроде цветовых палитр, фотографий, типографики и других графических элементов.
– Подробная спецификация. Максимально детальная документация с описанием того, как должна функционировать система. Подробная спецификация описывает, например, то, как продукт адаптируется в ответ на действия пользователя, такие как щелчки мышью, пролистывание, печатание. Она включает и реализацию обработки ошибок, и то, как система адаптируется и развивается в зависимости от различных состояний системы и действий пользователя (например, вход или выход из аккаунта, первое посещение, повторные посещения и т. д.).
– Руководство по стилям и шаблонам. Документация с описанием стандартных соглашений, принятых для повторяющихся шаблонов. Руководства по стилю: стандартные соглашения, касающиеся визуального дизайна или контента, и т. п. Руководства по шаблонам: стандартные соглашения о взаимодействии и т. п.
– Прототипы. Полностью или частично функционирующие макеты того, как дизайн должен работать после реализации. (Дополнительную информацию см. в разделе «Бумажные и интерактивные прототипы» в главе 8 «Методы тестирования и проверки».)
• Реализация. Обеспечение того, чтобы дизайн в руках пользователей работал и чтобы его реализация шла в соответствии с планом.
– Тестирование удобства использования. Различные методы оценки того, смогут ли люди использовать дизайн для выполнения предполагаемых задач, и если да, то насколько легко. (В главе 8 приведены некоторые методы тестирования и проверки.)
– Контроль реализации. Постоянное взаимодействие между дизайнерами UX и командой инженеров для решения дополнительных вопросов UX по мере их возникновения, а также обеспечение реализации дизайна в соответствии с планом.
– Отслеживание показателей / аналитика. Постоянный мониторинг ключевых данных об использовании, который позволяет определить, как люди используют продукт или услугу, и выявить возможности для будущего преобразования или улучшения.
Один из способов четко определить границы вашей работы – создать краткое одностраничное описание того, какие услуги вы предоставляете, а какие – нет. Такое описание можно сравнить с прайс-листом: четким коротким документом, описывающим все действия, за которые вы несете ответственность. На рис. 2.6 показана карточка с предложением, которую я создала, когда работала в команде UX в Barclays Global Investors. (Такая карточка может быть чрезвычайно полезной для фрилансеров, занимающихся UX.) На рис. 2.7 показано, как можно использовать карточку с предложением, чтобы показать, какие именно обновления данного конкретного проекта вы станете проводить.
Рис. 2.6. Как видите, эта карточка с предложением не идеально соответствует описанному ранее общему процессу. Этот прилагаемый список был адаптирован к конкретным действиям, которые я выполняла в данной конкретной компании и именно на этой должности
Рис. 2.7. Работая над конкретными проектами, я выделяла используемые методы, чтобы помочь людям понять, как этот проект расширяет рамки подхода к дизайну, ориентированному на пользователя
⚓ БИБЛИОТЕКА ДЛЯ НАЧИНАЮЩЕГО СПЕЦИАЛИСТА В ОБЛАСТИ UX
Если вам интересно больше узнать об основах UX и о том, какова структура типичного дизайна UX, начните с книг, находящихся на этой полке (рис. 2.8). В этих книгах подробно рассказывается, что такое UX, почему оно важно и как разрабатывать дизайн, ориентированный на пользователя.
Рис. 2.8. Библиотека начинающего UX‑специалиста
Сформируйте точку зрения на предстоящую работу
Прежде чем приступить к работе, неплохо бы ясно представлять, какую работу вам нужно выполнить и как сделать свой вклад в нее действительно ценным. Хорошая новость: для того чтобы быть монокомандой UX, вам не нужно чье-то разрешение. Вы можете внедрить в свою текущую работу философию UX. Вы также можете искать разные мелкие удобные случаи для старта. Вы думаете, что начать переход в UX нужно с изменения должности и роли? Это не так. Если вы попросите о полной смене ролей до того, как заставите людей увидеть и понять ценность UX, вам вряд ли пойдут навстречу. Лучше начать заниматься UX с небольших, почти незаметных улучшений, а затем уже набирать обороты благодаря положительному впечатлению от вашей работы.
Ниже приведено несколько рекомендаций, которые может взять за основу любой «перебежчик». Это еще не UX‑деятельность как таковая, но, следуя этим рекомендациям, вы проложите себе путь.
Найдите низко висящий плод. Соблазните своих коллег картинами возможного лучшего будущего. Найдите те части продукта, о проблемах которых всем известно, и с них начните свою атаку. Однако важно делать это уважительно и в позитивном ключе. Используйте сеанс «черной шляпы»[10] (глава 8), чтобы заставить окружающих задуматься о том, чем и как можно улучшить ваш продукт, или быструю «эвристическую разметку» (глава 6), чтобы выполнить всю работу самостоятельно.
Составьте план. Если вы хотите, чтобы люди купились на концепцию UX, предложите им что-нибудь ценное. Как это сделать? Сядьте и составьте схематический план того, как вы хотели бы подойти к UX‑проекту. Подумайте, что, когда и почему вы предложили бы сделать. Подумайте, на какие важные, по вашему мнению, вопросы необходимо ответить и как бы вы сами на них ответили. Составьте план UX‑проекта (глава 5), чтобы четко его себе представлять. А затем спросите себя: «Требуется ли мне разрешение или поддержка, или, возможно, я смогу сделать это прямо сейчас?» Не исключено, что вы поймете: да, можно просто взять и начать.
⚓ МЕТОДИЧЕСКИЕ КАРТОЧКИ
Методические карточки – превосходный инструмент для определения быстрых действий, которые можно совершать в течение обычного рабочего дня для настроя на UX‑подход. Компания IDEO создала методические карточки, которые можно купить (см. коробочку на рис. 2.9). Справа изображены карточки от компании nForm, также занимавшейся разработкой UX, их до сих пор можно найти в интернете (https://www.ideo.com/journal/method-cards). С другой стороны, вы можете нарисовать и собрать собственную коллекцию, как показано в нижней части рисунка.
Рис. 2.9. Различные методические карточки
✒ СОВЕТ. КАК БЫТЬ С ВОЗРАЖЕНИЯМИ
Если вы столкнулись с возражениями и вам нужно добиться разрешения, дам полезный совет. У профессионалов в области продаж есть хитрый прием, называемый «альтернативным закрытием». Вместо того чтобы просить разрешения на закрытие сделки (или в данном случае на выполнение работы), они предлагают два варианта того, как это сделать. Не «Могу я вам позвонить?», а, например, так: «Вы будете платить наличными или по безналу?» В соответствующем примере для UX вместо «Можно нам провести небольшое исследование?» стоит сказать: «Мы можем провести полномасштабное исследование или сделаем краткую неформальную оценку, чтобы получить быструю обратную связь». Тогда споры пойдут не о «если», а о том, «как».
Узнайте своих пользователей
После того как вы разобрались с возможностями и набросали план, вам нужно получить непосредственный опыт работы с пользователями, пообщаться с ними и изучить их потребности. Пользователи – стержень понятия UX, ведь это люди, которые используют вашу продукцию. О них нужно помнить все время разработки, потому что именно им в первую очередь доведется испробовать последствия мириада дизайнерских решений.
Хорошие продукты в конечном итоге становятся в определенной степени невидимыми, вливаясь в поток обыденных естественных действий, в котором пользователи без особых напряжений используют все функции продукта. Пользователь не «публикует сообщение на стене», а отвечает другу. Не «форматирует документ Word», а пишет текст. Для производителя продукта это своего рода нирвана. Но также это чертовски сложно реализовать. В некоторых вопросах вы гарантированно будете ошибаться, особенно поначалу, поэтому в области UX важное значение уделяется именно пониманию потребностей и тестированию дизайна продуктов с участием пользователей. Такой акцент на связи с конечным потребителем настолько важен, что представляет собой один из основных принципов проектирования UX: вы разрабатываете продукты для пользователей и вместе с ними.
Мне слово «пользователь» не нравится. Я предпочитаю называть пользователей просто людьми. Это помогает помнить о том, что мы создаем дизайн для находящихся вокруг нас людей. Но чтобы создавать дизайн для людей, нужно о них что-то знать. Это означает, что вы должны бороться с тенденцией относиться к человеку как к статистической единице рыночного сегмента и стремиться понять его как сложное, непостоянное животное, которыми мы все являемся. Эрик Райс, представитель движения Lean Startup[11], однажды сказал замечательную фразу, которая прекрасно резюмирует такой подход: «Данные – тоже люди». Вам потребуется временно отбросить свои взгляды и надолго принять точку зрения другого человека, чтобы почувствовать его боль и представления о лучших альтернативах (рис. 2.10). Это сложнее, чем кажется, потому очень важно тратить время на знакомство с реальными пользователями.
Рис. 2.10. Хорошо спроектированный продукт позволяет пользователю достигать своих целей эффективно, без путаницы и сбоев. Когда пользователь сталкивается со сбоем в системе, это сразу заметно
Поразительно, как много людей утверждают, что практикуют UX‑дизайн, но при этом редко общаются с реальными пользователями. Не делайте так. Настоящие монокоманды UX стремятся узнать не абстрактных пользователей, но людей, которые действительно пользуются их продуктами. И это дает результат. Джаред Спул из отдела разработки пользовательских интерфейсов провел исследование, которое доказало, что личное общение сотрудников с конечными потребителями напрямую влияет на качество продукта (подробнее можно почитать на https://centercentre.com/). Поэтому начать общаться с реальными пользователями очень важно. Вот как это сделать.
Определите, что вы знаете (и чего не знаете). Научитесь собирать доступные данные о пользователях и применять их в качестве инструмента для управления своей работой (см. главу 6). В частности, чтобы пользователи для вас стали людьми, попробуйте метод «Протоперсоны».
Проведите партизанское исследование. Даже если вы не можете сделать это явно, существует множество простых способов связаться с реальными пользователями и представить им свои проекты (см. главу 6).
Как начать разрабатывать дизайн
Забавно, что от UX люди ожидают дизайна, который будет неизмеримо круче. Прекраснее. Проще. Интуитивно понятнее. Ну, просто лучше, понимаете? И вы, разумеется, не хотите их разочаровать. Проблема в том, что многие из нас приходят к UX окольными путями и не имеют формального опыта разработки дизайна. В результате монокоманда нередко начинает отстаивать проект дизайна, не имея стопроцентной уверенности, что это действительно лучший вариант. Специалистам по UX необходимо понять нужды пользователей настолько хорошо, чтобы отбрасывать примитивные решения и находить элегантные (рис. 2.11).
Рис. 2.11. Иногда правильное решение по формированию UX может быть обманчивым. Например, этот гигантский ТВ-пульт решает одну проблему (надписи хорошо видны и по кнопкам не промахнешься), но может создать другие (например, пульт размером с поднос попросту неудобно держать)
Многие из нас начинают знакомство с дизайном с программы, которая упрощает верстку страницы, но не обязательно учит тому, как люди обращаются с функциями и информацией в интерактивной среде. Конечно, очень хочется погрузиться в программу с головой и полностью раствориться в процессе верстки страниц, но не факт, что это лучший способ разработать дизайн, создающий нужный баланс между ожиданиями пользователей, маркетинга и вашей команды. Именно здесь UX‑специалистам могут пригодиться различные инструменты дизайнеров с классическим образованием – в частности, создание эскизов, критический анализ, итерационное улучшение и поиск вдохновения в окружающем мире. Вот методы, которые можно применять в работе монокоманды.
• Делайте эскизы своих идей. Самые простые и красивые проекты рождаются именно так (рис. 2.12). Чтобы сделать что-то простое, нужно приложить немало усилий. Этот процесс часто начинается с весьма хаотичных набросков на салфетке в поисках вдохновения и развивается по мере того, как вы повторяете, совершенствуете, преобразуете свои идеи в поисках идеала. В главе 7 описан ряд методов, которые помогут вам и вашей команде в процессе создания набросков.
Рис. 2.12. Как это ни парадоксально, красивый дизайн часто начинается с весьма непривлекательных набросков на бумаге или почеркушек на доске
• Привлекайте коллег к участию в наработке дизайнерских идей. Организуйте мероприятия, которые позволят другим принять участие в создании дизайна (рис. 2.13). В главе 7 описаны различные методы планирования и проведения таких совещаний, особенно выделены скетчборды[12], идеально подходящие для нашей цели. На рис. 2.13 показан более-менее упорядоченный результат успешного межфункционального сотрудничества между монокомандой UX и коллегами: множество набросков и визуальных артефактов, а также куча заметок, родившихся во время разговоров.
Рис. 2.13. Пример готового скетчборда, подробно описанного в главе 7
• Учитесь на примере успешных продуктов. Создавайте «библиотеки вдохновения», чтобы быть в курсе современных стандартов и иметь большой запас идей при работе над новой задачей (рис. 2.14).
Рис. 2.14. Библиотека источников вдохновения может быть такой же простой, как папка со скриншотами известных вам дизайнов, хороших и плохих
Но и не бойтесь сомневаться. Потратьте время на раздумья: что заставляет тот или иной дизайн работать? Не менее важное правило: если что-то не работает, попробуйте определить, в чем причина. Можно пойти еще дальше и попрактиковаться в вербализации этих мыслей (расскажите о проблеме другу или, если вам так комфортнее, своему отражению в зеркале). Понимание языка критики – отличительная черта хорошего дизайнера, которая во многом помогает ему объяснить не-дизайнерам, что в субъективной среде работает, а что – нет.
В этой главе рассматриваются «кирпичики», из которых состоит любая работа над UX. Для начала определите, с чего начать. Затем продумайте весь процесс, соблюдая баланс между исследованием пользователей и дизайном. Но самая важная идея главы – и, по сути, самая важная штука во всей области UX – это реальное общение с пользователями.
Так что, если у вас есть время сделать только одно из всего предложенного в этой главе, фокусируйтесь на исследовании пользователей. Как правило, даже малое время, затраченное на изучение потребностей и реалий пользователей, позволит вам понять важные и очевидные вещи, что станет мощным толчком для начала работы.
Описание работы типичной монокоманды UX
Если вы оказались на рынке труда, вам будет полезно научиться подбирать ситуацию, подходящую для труда монокоманды UX. Лишь немногие работы в области UX работодатель описывает как доступные монокоманде, но, как правило, есть явные признаки такой вакансии. На рис. 2.15 приведено объявление о работе, адаптированное на основе нескольких реальных вакансий, размещенных на популярной доске объявлений UX.
Из текста этой вакансии видно, что работодатель ищет человека, который сможет радикально улучшить качество UX. Продукт должен быть «элегантным», упрощенным до «самого необходимого» и «красивым». Об этом не всегда говорят прямо, но, как правило, ждут, что появление сотрудника, который разбирается в UX, немедленно приведет к таким изменениям продукта, что прямо вау! Эта задача может оказаться непростой, поскольку улучшения дизайна происходят обычно поэтапно, с течением времени. Методы создания дизайна, описанные в главе 7, позволят вам понять, как можно улучшить качество продукта и привлечь к этому процессу людей.
Рис. 2.15. На рисунке приведено типичное описание работы монокоманды UX. Из текста этой вакансии видно, что работодатель четко понимает, что UX имеет важное значение для создания конкурентоспособного продукта, но не знает толком, как UX будет встраиваться в уже сложившийся порядок работы компании
В этом описании вакансии также можно увидеть общую проблему, с которой сталкиваются UX‑команды: работодатели часто неправильно понимают связь между визуальным дизайном и дизайном UX. Это может свидетельствовать о недостаточной осведомленности о процессах и людях, участвующих в работе над восприятием пользователя. Некоторые UX‑специалисты включают графический дизайн в свой арсенал инструментов, однако многие так не делают. Если даже вы занимаетесь только вайрфреймами, вы уже можете называть себя дизайнером UX, но универсалам (которыми являются большинство монокоманд) иногда приходится браться и за визуальный дизайн. Чтобы получить представление о том, что знают и не знают о UX ваши коллеги, пригласите их на обед и поговорите с ними в непринужденной обстановке. Подумайте о разъяснительной работе в «курилке» (этот подход описан в главе 9 «Методы информационно-разъяснительной работы»), чтобы расширить понимание ролей и функций UX.
Работодатели ожидают, что специалисты по UX смогут подтвердить свои навыки и продемонстрировать результаты своей деятельности. Работодатели также могут ожидать от UX‑специалиста настойчивости и умения убедить своих коллег принять новые подходы. Монокомандам UX иногда приходится быть дипломатами, информаторами и медиаторами.