Добрый вечер. Вебинар начнется примерно через 12 минут.
Кто только что присоединился к Марафону, меня зовут Ирина, UIDesign Group, организатор данного события
Если у вас проблемы со звуком, подождите а потом попробуйте заново войти
Пишите свои вопросы в чате в правой панели
Если вы хотите задать вопрос голосом, воспользуйтесь функцией "Поднять руку"
Просьба заполнить небольшую анкету, которая откроется после вебинара
Сегодня я попробую сделать так, что все смогут видеть список вопросов к докладчику
Ким: Всем привет!
Ирина: Спасибо за участие!
Ким: Отлично, когда технология работает!
У меня утро. Я приветствую вас всех.
Сегодня я поговорю о проектировании единого опыта
с точки зрения разных дисциплин
Как развивалась наша индустрия?
Изначально интерфейсы были текстовыми
А потом появилась мышь, но все было унылым
А потом интерфейсы стали более яркими
Многие согласятся, что нужны два набора скиллов для проектирования
проектирование взаимодействия и визуальный дизайн
Некоторые из вас делают и то, и то
всегда будет место для генералистов
особенно в маленьких командах
но у меня есть пара аргументов за разделение
так у нас в Купере
каждое из этих дел требует определенных знаний и умений
когда вы пытаетесь разбираться во всем, это замедляет обучение и развитие
Обе дисциплины очень важны для юзабилити
традиционные подходы граф. дизайна, которые занимаются статичными экранами, часто подходят для статичных систем
сорри, проектирования взаимодействия
Граф. дизайн отлично работает с нашими эмоциями
они тоже важны для опыта
Часто рабочие продукты скучны, они разработаны с расчетом на эффективность
Но у людей сейчас больше ожидания с точки зрения эмоционального компонента
Новые дивайсы очень красивые
и люди ожидают приятного дизайна везде
Мы видим это в наших бытовых устройствах
Даже душ теперь — продвинутое цифровое устройство
Но я по утрам обычно не смогла бы с таким разобраться )
В Купер мы часто сталкиваемся с проектами, где требуется также пром. дизайн
Он занимается и технической реализацией, и брэндом, и эмоциями
Люди не разделяют опыт от программного и аппаратного обеспечения
Они просто говорят "Мой телефон - отстой!"
Мы подходим к дизайну продукта как к целостной задаче
Некоторые команды строго разделяют пром. дизайнеров и проектировщиков ПИ
Измеритель глюкозы всего с одной кнопкой - как проектировщик сделает его удобным
Мы пошли к разработчикам харда и сделали три кнопки
Мы должны быть хоть чуть-чуть грамотными в областях своих коллег
но мы должны разбираться лучше всего в своей области
На сложный рабочий продукт нам требуется пара проектировщиков и один дизайнер
Редко у нас меньше двух человек работает над проектом
Коллективная работа делает разработку более эффективной
Нам был нужен объединенный процесс, словарь
у нас должны быть модели для параллельной и для коллаборативной работы
Вот знакомая схема процесса
Сначала планирование (понимание целей и планов)
Исследование пользователей и контекста
Иногда мы делаем 60 интервью, а иногда краткое исследование
Делаем модели, чтобы создать общее понимание
Затем создаем концепцию, постепенно сужая набор альтернатив
Узнаем у инженеров, что можно реализовать
Показываем это заинтересованным лицам, иногда пользователями
А затем идет итеративный процесс детального проектирования и тестирования
После объединения с визуальным и промышленным дизайном этот процесс особо не изменился
Лишь несколько маленьких изменений
Немного поговорим об этапах
Что делает проектировщик взаимодействия?
Вы в целом знаете, поговорим больше об эмоциональных этапах
Мы начинаем фазу исследования с интервью с заинт. лицами
потом с пользователями
до 60 интервью
мы делаем интервью в реальной рабочей обстановке + наблюдение
60-90 минут
обычно участвуют 2-3 человека с нашей стороны
визуальные и промышленные дизайнеры не должны видеть все интервью
где-то половину
но они должны погрузиться в контекст
у них свой интерес к интервью
Мы делали проект для хирургов
Проектировщики взаимодействия воодушевились, когда увидели, что хирурги показывают друг другу бумажки
Какой инфы не хватает в системе
Виз. дизайнеры сказали: они далеко от экрана, нужны большие кнопки и яркие цвета
Пром. дизайнеры: под каким углом они смотрят на экран?
Может, сделать им педали?
С эмоциональной точки зрения:
когда мы приходим к пользователям домой, мы видим, какой стиль им нравится
например, видим, что они читают журналы про современную архитектуру
и любят минималистичный дизайн
а другие люди привержены к английскому стилю в интерьере
Если кто-то идентифицирует себя с Nike или носит джинсы, это немного уже говорит о личности
Мы заканчиваем исследование, когда угадываем большинство фраз пользователей
Затем мыс троим модели, чтобы получить общее понимание внутри команды и с заинт. лицами
Мы стараемся включать заинт. лиц (ЗЛ) в процесс
Они не могут посмотреть все интервью, тут помогают модели
Этот этап занимает от дня до недели
Проектировщики думают об основном процессе работы
не обо всех ответвлениях, а о типичном процессе
Они рассматривают ментальные модели и таксономию
Они всегда (даже если нет документации) разрабатывают персонажей
Они базируются на паттернах поведения
мы видим, как варьирует поведение людей, и видим повторяющиеся вещи
и разные группы похожих пользователей
мы видим, что за их поведением лежит несколько видов паттернов
Когда мы начинали работать с персонажами
они работали на проектирование взаимодействия
они были центрированы на сценариях
Но дизайнерам нужна эмоциональная сторона
Вот пример персонажей с использованием техники коллажа
Мы стараемся передать эстетику, любимые бренды, что они ищут в окружении
Чтобы получить более целостную картину личности
их физическое окружение
Другая вещь, как изменились персонажи
в проектировании взаимодействия важны конечные цели (что они хотят сделать)
например, избежание неприятных сюрпризов или уходить с работы в 6
Но для дизайна нам также важны цели с точки зрения впечатлений
какие впечатления люди стремятся испытывать
Например, безопасность и спокойствие
Поэтому банки обычно не используют оранжевые и красные цвета
Построив модели, мы работаем над определением требований
Вы скорее всего знакомы со сценариями
Представим, каким будет идеальное взаимодействие, если не заморачиваться над ограничениями
Исходя из сценариев, мы получаем множество требований
Конечно, есть требования, которые исходят из законодательства, конкурентного анализа и т.д.
Сценарии должны быть отвлечены от деталей реализации
Это как разговор пользователя с системой
Если вы работаете в Agile-методологии
то вы скорее используете пользовательские истории
они менее детальны
Сценарии - это инструмент для обсуждения
Также важны такие вещи, как атрибуты опыта
Мы узнаем у ЗЛ, какие чувства и впечатления должны быть у пользователя продукта
Все это мы собираем на вайтборде, собираем в группы
Смотрим, какие группы могут быть выражены визуально
Хорошие слова - те, которыми можно описать человека
Например, о человеке сложно сказать "simple@
Мы скорее скажем "approachable"
Мы ищем набор слов, который хорошо опишет целевой опыт
Обычно бывает около 4 ключевых атрибута
между которыми мы стараемся балансировать
Это выглядит довольно гуманитарным занятием для высокотехнологичной компании
но так мы определяем, какую идею мы хотим передать с нашим продуктом
Так мы стараемся рационально охватить наиболее субъективные аспекты проектирования и дизайна
Обычно ведут такую работу дизайнеры
Проектировщики выступают консультантами, но больше сконцентрированы на процессе работы
Некоторым все равно сложно понять, как эти слова выражаются в реальном результате
часто мы стараемся использовать визуальные якоря вроде коллажей
Вот коллаж "Безопасность"
Видите, какие толстые солидные зарубки на этой крутилке для сейфа?
Иногда нужно передать границы: мы хотим быть ясными и понятными, но не стерильными и предельно минималистичными
Итак, мы поняли, куда мы хотим идти
и пора уже создавать основу нашего дизайна
Мы потратим день-два, думая о максимально широком наборе перспектив
Тут работают сразу все специалисты
за вайтбордом
Заказчикам мы показываем набор скетчей
в них мы показываем общий процесс взаимодействия,
базовые принципы визуального и промышленного дизайна
Первый вопрос - какая платформа и архитектура
Платформа - фундаментальная форма продукта
Например, для мобильного устройства: можно использовать сенсорный дисплей, использовать кнопки рядом с экраном, а можем джойстик
Такие есть подходы к навигации: пром. дизайнер это зарисует, а проектировщик будет смотреть, что больше подходит к задачам пользователя
Кто должен принимать решение?
Ни один из них!
При хорошем взаимодействии они придут к общему решению
Проектировщики часто хотели быть лидерами
это было неправильно
они ведь не эксперты в граф. и пром. дизайне
и у них есть свои "причуды"
иногда им удавалось договориться
но на всякий случай у нас обычно есть дизайн-директор
он имеет бэкграунд в одной из областей, но также должен быть продвинутым и в остальных
он не погружается в проект по максимуму, так что может задавать хитрые вопросы,
есть также ограничения: может, сенсорный дисплей слишком дорог
Нужно учитывать взаимодействие физических контролов и GUI
проектируя телефон, мы обсуждаем все вместе, базируясь на сценариях использования телефона
Данные, которые на дисплее, часто становятся основной для форм-фактора
В конце каждый специалист начинает работать более глубоко над своим аспектом
не вдаваясь, в детали
просто обдумывает, что надо учесть на данном этапе
например, какой размер экрана нам нужен
пром. дизайнеры любят использовать пластилин или 3D-модели
но с 3D на данном этапе не стоит заморачиваться
Мы стараемся, чтобы ЗЛ обращали внимание на общую структуру и основной функционал, а не на детали
поэтому на данном этапе у нас очень грубые наброски
Вот набросок интерфейса телефона
Для аппаратного обеспечения то же самое
Вот грубый набросок: большой экран, такая-то группа кнопок тут, такая-то здесь
Параллельно мы стараемся определять язык дизайна
цвета, типографику, материалы
этот процесс в большой степени оторван от разработки функций
мы просто изучаем варианты, пока не вдаваясь в детали реализации
Мы создаем стиль для каждого из основных аргументов
слева - дружелюбный, в середине - исключительный, справа - надежный
Этот - весь такой светленький с волной на фоне
Этот весь блестящий
а этот спокойный
Мы не обсуждаем с ЗЛ конкретные цвета, а общее впечатление и соответствие целям
отделить язык дизайна от физической формы сложно
При ограниченном бюджете мы ограничиваемся набросками
Когда есть время, мы делаем компьютерное моделирование
Вот дружелюбный: кругленький, выглядит как довольно типичный телефон
Исключительный: хром, угловатый, модерновый
Надежный: ничего не спрятано, простой
Мы показываем эти модели всем ЗЛ
и обсуждаем то, как здесь передаются эмоции
мы не диктуем наши решения, а стараемся обсуждать и решать все на равных
Пром. дизайнеры смотрят на прототипы GUI
и обращают внимание на то, что интересно для них
Но пока разные аспекты рассматриваются отдельно
Дальше мы делаем детальную спецификацию
здесь уже ограничения реализации влияют на решения
Все это не обязательно водопадный процесс
мы не очень любим водопадный процесс, многие такие проекты проваливаются
но и полностью agile процесс не работает в таких комплексных проектах
Поэтому перед тем, как начать быстрые итерации, мы определяем основные решения
Для простых продуктов и команд, которые рядом, особенно не нужны подробные спецификации
но мы всегда стараемся делать их достаточно полными
Вот тут, показано, как работают физические контролы, разные состояния
На этом этапе пром. дизайнеры работают независимо
в основном, взаимодействуя с инженерами
но периодически они встречаются с командой
у нас в Cooper мы всегда собираемся каждый день минут на 15, чтобы знать, кто что делает
а то могут вскрыться конфликтные решения
Иногда по ходу приходится делать немного дополнительного исследования
Когда мы работает в Agile-режиме, мы делим проект на 10 разных тем, например
Чтобы делать эти части, и чтоб разработчики могли по ходу проверять все на реализуемость
Тема 3 может повлиять на тему 1
но в итоге такой процесс все-таки оправдывает себя
Мы обсуждаем наброски совместно с инженерами и ЗЛ
иногда делаем тестирование бумажных прототипов
Обычно мы делаем наброски в Fireworks
это быстро, там реальные размеры в пикселах
В то же время, визуальные дизайнеры, оборачивают это в последовательный графический стиль
Они берут файл от проектировщиков, прямо в нем повышают детальность, и отдают обратно проектировщикам
так они параллельно работают с одним файлом
проектировщики не диктуют граф. дизайнерам, работаю вместе
Когда мы делаем линейку продуктов, важно придерживаться общего макета
Например, везде используется деление экрана на 4 части
Граф. дизайнеры часто хорошо упрощают, то что сделали проектировщики
Также важна система иконок
Пиктограммы делаются практически в самом конце
Визуальные дизайнеры делают детальные визуальные спецификации для каждого экрана
Мы не делаем реализацию, так как у разных клиентов очень разные технологии
Если вы работает in house, то разработчик интерфейсов может сразу делать это в конечной технологии
Конечно, мы тестируем наши прототипы
Когда у нас появляется первая версия детального дизайна
после этого мы делаем вторую версию
Обычно мы не находим серьезных проблем, если проведено хорошее тестирование
некоторые клиенты отказываются от него
но если система очень ответственная, постарайтесь убедить клиента в том, что без тестирования не обойтись
например, в медицине
Иногда чтобы убедить клиента хорошо делать динамические прототипы, например, во Flash
это помогает также выловить проблемы, которые не заметны в статике
Потом инженеры начинают реализацию, чтобы найти сложности с реализуемостью дизайна
в то же время пром. дизайнеры работаю с механическими инженерами
вдруг мы не предусмотрели место для вентиляции
или такая форма невозможна с используемыми материалами
Обычно механический инженер уже готовит конечный CAD-файл.
Наш пром. дизайнер делает конечную проверку этого файла
Они работают с этим CAD_файлом, как мы с Fireworks
Они обсуждают, какой пластик использовать и какие марки краски
Мы можем делать модели, которые не работаю, но сделаны из реальных материалов
В конце вся команда работает, поддерживая разработку
всегда какие-то маленькие вопросы и проблемы всплывают
для этого мы проводим регулярные встречи раз в 1-2 недели
инженеры работаю вместе с проектировщиками и дизайнерами
мы проверяем, что разработчики все соблюдают
Все это требует участия опытных менеджеров
потому что нужно качественно координировать работу
Но если делать все правильно, то получаются отличные продукты
Пожалуйста, Ваши вопросы!
Работает ли процесс Coopeк с постоянно развивающимися сервисами?
Ответ: Да, многие нанимают нас для существенных редизайнов.
Однако мы не осуществляем постоянную поддержку сервиса.
Мы делаем исследования и разрабатываем модели
это не нужно делать для каждого релиза
достаточно сделать это один раз, и этого хватит на некоторое время
Компания хотела внести выписку рецептов в свою систему электронной больницы
которую мы до этого разрабатывали
мы провели дополнительные исследования
за 8 лет почти ничего не изменилось
иногда мы разрабатываем модели будущего: что будет через 3-5 лет
в сфере потребительских продуктов все развивается довольно быстро
Иногда для того, чтобы понять текущие проблемы, можно провести доп. исследования, а можно посмотреть персонажей
Вопрос: Как вы выделяете персонажей?
Ответ: Это основано на паттернах поведения
сложный проект: линейка офисных телефонов
как они используются?
несколько ролей:
секретарь, типичный работник,
мобильные сотрудники
(продажники, сотрудники на выезде и т.д.)
сотрудники колл-центра
мы опросили 8-1 0 представителей каждой группы
мы поняли, что у нас по крайней мере 4 персонажа
но среди секретарей было несколько типов поведения
например, в маленьких и больших компаниях
или они по-разному смотрят на вещи
вещи
например, хирурги подходят к одной задаче по-разному
даже в такой области нужно было 2 разных персонажа
каждая роль дает 1 или больше персонажей
для потребительского продукта 2-3 персоны, для сайта 5-8, для большой корпоративной системы может быть 25
от одного до трех на роль
Посмотрите мою книгу и книги Купера
Вопрос: Как вы объединяете требования ЗЛ со выявленными Вами требованиями?
Ответ: Обычно уже есть какой-то документ с требованиями
иногда это одна страничка с общим описанием
они очень хороши для старта проекта
Все сложнее, когда уже есть 100-страничный документ, в котором уже все задано
Мы обычно относимся к требованиям клиента как к гипотезе
мы их обязательно проверяем
с какими-то мы спорим
и приоритезируем их
Мы работаем с бизнес-аналитиками в паре случаев
иногда заказчик использует их вместо проектировщиков
с переменным успехом
но они хорошо помогают всем понять, какие последствия у определенного дизайна
например, такое-то решение затронет 3 древние системы, которые взаимодействуют с нашей
Хорошо объединять хороших дизайнеров с людьми с хорошими аналитическими навыками
Вопрос: Если вы работаете в компании, неопытной в софте, а скорее работают с хардом
Ответ: Мы часто работаем с такими
Что хорошо: они обычно понимают важность проектировании, в отличие от многих софтовых компаний, которые предпочитают сразу начать программировать
один клиент делал сложные медицинские приборы
чем сложнее оборудование, тем сложнее им понять, как управлять им
для них это были огромные перемены в оргкультуре
нужно найти небольшие нерискованные проекты, на которых попробовать новый процесс
найдите заинтересованного инженера
А историю успеха можно потом предъявить руководству
переманивайте на свою сторону евангелистов процесса
Важно привлечь менеджеров высоких звеньев
Это может сначала казаться им дорогим, но истории успеха помогут убедить их
Рекомендую книгу Leading Chante by Kottar
Он много написал про управление переменами
Очень много полезных советов он дает
На сайте Cooper есть пара моих статей на эту тему
Вопрос: Как превратить требования в решения?
Как понять, что дизайн оптимально им удовлетворяет?
Ответ: мы фокусируемся на нуждах и на диапазоне возможных решений
Важно не забывать об основополагающих принципах проектирования
Иногда бывают проблемы, которые более комплексные, чем только проектирование
мы делали проект для компании, которая позволяет расшаривать видео
Мы предложили два подхода: дать возможность постить на публичный сайт,
дать связь с сервисом для отправки на e-mail
или более интегрированный сервис
Это не только вопрос проектирования, но вопрос бизнеса: какие затраты, какие прибыли
мы привлекли всех ЗЛ
Если мы решаем, какой контрол применить, то тут мы смотрим, что будет удобнее для пользователей
Чаще всего опираемся в этом на общие принципы
Вопрос: Как вы меняете дизайн по ходу проекта?
если заказчик не готов что-то реализовать
Ответ: всегда есть такой риск
Мы стараемся быть оптимистичными
предлагаем вещи, которые не очень простые, но хорошие
но не предлагаем чего-то совсем нереального
потом мы все это обсуждаем с заказчиком
Мы делаем первую версию дизайна
и показываем каждые 2 недели наброски ЗЛ
Мы стараемся показать, что хорошего в наших решениях и почему стоит постараться
Мы не хотим, чтобы инженеры говорили нам, что нельзя сделать
Нужно сбираться вместе с ними и с остальными ЗЛ
Это бизнес-решение
Надо показывать руководству, что это даст пользователям
Вопрос: Использовать ли роли или полноценные персонажи?
Ответ: Многие используют роли.
Роли и персонажи -- разные вещи
Роли -- это только задачи.
Может быть несколько персонажей внутри роли.
Но персонализация персонажей помогает породить эмпатию
Мы не сходим с ума, но нужно просто, чтоб они выглядели реалистично
Есть исследование, которое показывает, что при
размышлении с точки зрения системы, и с точки зрения людей,
мы за действием разные зоны мозга
Персонажи устраняют эффект гуттаперчевого пользователя
когда мы каждый раз видим пользователя так, как нам удобно в данном случае.
Вопрос: Что вы используете кроме Fireworks?
Мы используем Фотошоп для очень детальных графических вещей
ИнДизайн -- для верстки спецификаций
Todd Warfel скоро выпустит хорошую книгу о средствах прототипирования
Вопрос: Что мы делаем в agile-режиме, когда торопимся?
Ответ: Когда все уже в процессе, мы стараемся поддерживать хороший agile-процесс
мы не стараемся сделать идеальный продукт, но стараемся сделать его по максимуму без проблем
Мы спрашиваем, что важно сделать в самую первую очередь
более рутинные вещи оставляем на конец
Делим продукт на тематики
И выдаем новые спецификации каждые 2-3 недели
Мы стараемся быть чуть впереди разработки
Если мы отрываемся, то можем немного больше рассматривать диапазон решений
Вопрос: Что мы делаем, когда что-то меняется. Сложно потерять концентрацию на главном
Ответ: Иногда провал проекта не связан с проектированием
Если ЗЛ не знают куда движутся, ориентируются лишь на запросы пользователей, а не на стратегию
важно сразу достигать консенсус.
Если что-то меняется по ходу, видимо, мы кого-то не услышали или не послушали в начале проекта
Мы стараемся в самом начале привлечь всех полезных ЗЛ
Например, если компания интернациональная, важно учитывать руководителей иностранных отделений
Желательно проводить исследования в разных странах
Даже если нет разницы, мы создадим доверие
Иначе они будут думать, что все сделано для американцев
Постарайтесь договориться о персонажах
трудно собрать всех ЗЛ в одном месте
но важно, чтоб они смогли обсудить все между собой
Когда вы покупаете машину, продавец старается задержать вас подольше
так и мы продаем свою работу так, чтобы ЗЛ поняли процесс и пользу от него
Ирина: Спасибо за отличную презентацию
Спасибо всем за внимание
Мы открыты для отзывов и вопросов после марафона
Следите за анонсами
У нас будут еще мероприятия
Всем пока!