Совершенно верно, здесь упор делается именно на то, какие задачи пользователи будут выполнять в рамках нашего продукта, как они будут взаимодействовать с системой и как интерфейс будет поддерживать это взаимодействие.
Возможно, слово «проектирование», взятое из ГОСТа, вводит в заблуждение. Заменил там, где это необходимо на «дизайн/проектирование взаимодействия».
В идеале, перечень требований должен быть полным на столько, чтобы давать возможность создать жизнеспособный продукт.
Для этого стандарт рекомендует создавать мультидисциплинарные команды. При этом стандарт не решает за нас, как именно мы достигнем этой самой мултидисциплинарности.
Если у нас команда из 5-10 человек, то все просто — все решили работать в рамках HCD-подхода и вместе формулируют требования.
Если у нас корпорация, в которой работают 20.000-30.000 сотрудников, скорее всего, HCD будет поддерживать какой-то отдел. И этот отдел будет консультироваться с другими отделами для написания требований. Кроме того, отдел будет приглашать специалистов со стороны. Например, Siemens, который разрабатывает решения для медицинской отрасли, нанимает на полную ставку врачей, для того, чтобы они участвовали в процессе HCD.
На этапе спецификации контекста, мы получаем перечень целей и задач на основе исследований (интервью, опросы, наблюдение и т.д.) После этого, мы используем эти данные для описания требований к продукту.
Например, если пользователь выполняет некую задачу в условиях плохой освещенности, мы можем включить требование комфортной работы в условиях плохой освещенности в список требований к продукту.
На этапе проектирования мы проектируем задачи в рамках нашего продукта исходя из списка требований. При этом мы хотим помочь пользователю достигать его цели, но не обязаны следовать описанным на этапе спецификации контекста задачам.
Например, у пользователя есть задача попасть из Петербурга в Москву. И он описывает ее так: сначала запрячь лошадей, взять ружье, еды на неделю и т.д., мы учтем цель, но предложим совсем другие задачи: купить билет на самолет, запаковать багаж и т.д.
На мой взгляд, слово «опыт» описывает навыки и знания, полученные пользователем ранее. Возможно подошел бы «переживаемый опыт», но это словосочетание звучит слегка шероховато.
Одним из стандартов, который дает рекомендации по управлению юзабилити является стандарт ISO 9241-210. Ниже привожу выдержку:
ISO 9241-210
4.7 Включение в группу специалистов с навыками и знаниями в различных областях
Группы человеко-ориентированного проектирования не должны быть большими, но они должны быть способны вырабатывать совместные проектные решения. В состав группы проектирования могут входить специалисты с различными точками зрения на проект и обладающие знаниями в разных научных областях:
a) специалисты в области антропометрии и эргономики, пригодности использования, взаимодействия человек — компьютер, анализа предполагаемой совокупности пользователей;
b) пользователи и другие причастные стороны (или люди, способные представить свою точку зрения);
c) эксперты в определенной области (прим. автора если делаете ПО для врачей, позовите врачей. Такие компании, как Siemens, нанимают врачей на полную ставку);
d) специалисты по маркетингу, брендингу, продажам, технической поддержке и обслуживанию,
здоровью и безопасности;
e) разработчики пользовательского интерфейса, визуального проектирования и проектирования продукции;
f) специалисты по составлению технического описания, обучению, поддержке пользователей;
g) специалисты по управлению, организации обслуживания и корпоративному управлению;
h) специалисты по анализу экономической деятельности, системному анализу;
i) специалисты по системному проектированию, проектированию программного и аппаратного обеспечения, программированию, изготовлению и обслуживанию;
j) специалисты в области человеческих ресурсов, устойчивого развития и др.
Креативность и идеи участников группы, их взаимодействие и сотрудничество благотворно сказывается на разработке проекта. Дополнительным преимуществом междисциплинарного подхода и учета разных точек зрения является повышение осведомленности участников группы об ограничениях и положении дел в других дисциплинах; например, технические эксперты могут стать более чувствительны к проблемам пользователей, а пользователи будут более осведомлены о технических ограничениях.
Естественно, стандарт описывает некий идеальный вариант.
Что касается вопроса о вреде опыта UI-дизайна для UX-дизайнера. Мне трудно предположить (не зная контекста выступления), что именно имели в виду спикеры. Возможно они подразумевали, что наличие опыта в различных областях определенно идет на пользу, однако, есть некоторые подводные камни.
Из моего опыта общения с условно «технорями» и «креативщиками» в рамках юзабилити могу отметить, что и у тех и у тех есть сложности смены парадигмы:
«Технорям» периодически сложно отказаться от фиксации на крутых технологиях и фичах продукта. Для них фичи и есть конечная цель;
«Креативщикам» бывает сложно абстрагироваться от эстетической составляющей. Для них конечной целью является красивая/интересная картинка.
При этом не важно, получили они опыт в Москве, Лондоне, Дели или Тегеране.
На мой взгляд, главное требование для успеха в рамках UX-процесса — заниматься именно UX, то есть ориентироваться на тот самый experience пользователей.
Если про первую картинку, то там не таблица, а два множества, не соотносящихся между собой. Слева — условные обозначения «сущностей», справа — «локаций» не более того. Надеюсь, никого не обидел.
Возможно, слово «проектирование», взятое из ГОСТа, вводит в заблуждение. Заменил там, где это необходимо на «дизайн/проектирование взаимодействия».
Для этого стандарт рекомендует создавать мультидисциплинарные команды. При этом стандарт не решает за нас, как именно мы достигнем этой самой мултидисциплинарности.
Если у нас команда из 5-10 человек, то все просто — все решили работать в рамках HCD-подхода и вместе формулируют требования.
Если у нас корпорация, в которой работают 20.000-30.000 сотрудников, скорее всего, HCD будет поддерживать какой-то отдел. И этот отдел будет консультироваться с другими отделами для написания требований. Кроме того, отдел будет приглашать специалистов со стороны. Например, Siemens, который разрабатывает решения для медицинской отрасли, нанимает на полную ставку врачей, для того, чтобы они участвовали в процессе HCD.
На этапе спецификации контекста, мы получаем перечень целей и задач на основе исследований (интервью, опросы, наблюдение и т.д.) После этого, мы используем эти данные для описания требований к продукту.
Например, если пользователь выполняет некую задачу в условиях плохой освещенности, мы можем включить требование комфортной работы в условиях плохой освещенности в список требований к продукту.
На этапе проектирования мы проектируем задачи в рамках нашего продукта исходя из списка требований. При этом мы хотим помочь пользователю достигать его цели, но не обязаны следовать описанным на этапе спецификации контекста задачам.
Например, у пользователя есть задача попасть из Петербурга в Москву. И он описывает ее так: сначала запрячь лошадей, взять ружье, еды на неделю и т.д., мы учтем цель, но предложим совсем другие задачи: купить билет на самолет, запаковать багаж и т.д.
На мой взгляд, слово «опыт» описывает навыки и знания, полученные пользователем ранее. Возможно подошел бы «переживаемый опыт», но это словосочетание звучит слегка шероховато.
Группы человеко-ориентированного проектирования не должны быть большими, но они должны быть способны вырабатывать совместные проектные решения. В состав группы проектирования могут входить специалисты с различными точками зрения на проект и обладающие знаниями в разных научных областях:
a) специалисты в области антропометрии и эргономики, пригодности использования, взаимодействия человек — компьютер, анализа предполагаемой совокупности пользователей;
b) пользователи и другие причастные стороны (или люди, способные представить свою точку зрения);
c) эксперты в определенной области (прим. автора если делаете ПО для врачей, позовите врачей. Такие компании, как Siemens, нанимают врачей на полную ставку);
d) специалисты по маркетингу, брендингу, продажам, технической поддержке и обслуживанию,
здоровью и безопасности;
e) разработчики пользовательского интерфейса, визуального проектирования и проектирования продукции;
f) специалисты по составлению технического описания, обучению, поддержке пользователей;
g) специалисты по управлению, организации обслуживания и корпоративному управлению;
h) специалисты по анализу экономической деятельности, системному анализу;
i) специалисты по системному проектированию, проектированию программного и аппаратного обеспечения, программированию, изготовлению и обслуживанию;
j) специалисты в области человеческих ресурсов, устойчивого развития и др.
Креативность и идеи участников группы, их взаимодействие и сотрудничество благотворно сказывается на разработке проекта. Дополнительным преимуществом междисциплинарного подхода и учета разных точек зрения является повышение осведомленности участников группы об ограничениях и положении дел в других дисциплинах; например, технические эксперты могут стать более чувствительны к проблемам пользователей, а пользователи будут более осведомлены о технических ограничениях.
Естественно, стандарт описывает некий идеальный вариант.
Что касается вопроса о вреде опыта UI-дизайна для UX-дизайнера. Мне трудно предположить (не зная контекста выступления), что именно имели в виду спикеры. Возможно они подразумевали, что наличие опыта в различных областях определенно идет на пользу, однако, есть некоторые подводные камни.
Из моего опыта общения с условно «технорями» и «креативщиками» в рамках юзабилити могу отметить, что и у тех и у тех есть сложности смены парадигмы:
При этом не важно, получили они опыт в Москве, Лондоне, Дели или Тегеране.
На мой взгляд, главное требование для успеха в рамках UX-процесса — заниматься именно UX, то есть ориентироваться на тот самый experience пользователей.