Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
«The design addresses the whole user experience»
Проектирование направлено на создание целостного пользовательского опыта.
Проектирование направлено на создание целостного пользовательского опыта.
Как вы себе понимаете сочетание рекомендаций:
Почему задачи пользователей сначала: 1) определяются, а потом 2) проектируются?
Что это значит?
Этап 2. Спецификация контекста использования
… Определить цели и задачи вышеуказанных пользователей …
…
Этап 4. Проектирование
… Спроектировать задачи пользователя…
Почему задачи пользователей сначала: 1) определяются, а потом 2) проектируются?
Что это значит?
Спасибо за интересные вопросы.
На этапе спецификации контекста, мы получаем перечень целей и задач на основе исследований (интервью, опросы, наблюдение и т.д.) После этого, мы используем эти данные для описания требований к продукту.
Например, если пользователь выполняет некую задачу в условиях плохой освещенности, мы можем включить требование комфортной работы в условиях плохой освещенности в список требований к продукту.
На этапе проектирования мы проектируем задачи в рамках нашего продукта исходя из списка требований. При этом мы хотим помочь пользователю достигать его цели, но не обязаны следовать описанным на этапе спецификации контекста задачам.
Например, у пользователя есть задача попасть из Петербурга в Москву. И он описывает ее так: сначала запрячь лошадей, взять ружье, еды на неделю и т.д., мы учтем цель, но предложим совсем другие задачи: купить билет на самолет, запаковать багаж и т.д.
На этапе спецификации контекста, мы получаем перечень целей и задач на основе исследований (интервью, опросы, наблюдение и т.д.) После этого, мы используем эти данные для описания требований к продукту.
Например, если пользователь выполняет некую задачу в условиях плохой освещенности, мы можем включить требование комфортной работы в условиях плохой освещенности в список требований к продукту.
На этапе проектирования мы проектируем задачи в рамках нашего продукта исходя из списка требований. При этом мы хотим помочь пользователю достигать его цели, но не обязаны следовать описанным на этапе спецификации контекста задачам.
Например, у пользователя есть задача попасть из Петербурга в Москву. И он описывает ее так: сначала запрячь лошадей, взять ружье, еды на неделю и т.д., мы учтем цель, но предложим совсем другие задачи: купить билет на самолет, запаковать багаж и т.д.
«есть задача попасть из Петербурга в Москву» — в терминологии стандарта это больше похоже на цель, а не задачу.
«сначала запрячь лошадей, взять ружье, еды на неделю и т.д.» — если «попасть из СПб в Москву» задачу, то эта цепочка уже больше похожа на ТЕХНОЛОГИЮ решения задачи (текущую).
но если представить, что «попасть» — это цель, то да, способы её достижения через задачи (запрячь, купить) сейчас и в будущем будут давать разные наборы задач.
тогда было бы более правильным считать, что на Этапе 4 происходит не проектирование задач, а ПЕРЕ-проектирование.
«сначала запрячь лошадей, взять ружье, еды на неделю и т.д.» — если «попасть из СПб в Москву» задачу, то эта цепочка уже больше похожа на ТЕХНОЛОГИЮ решения задачи (текущую).
но если представить, что «попасть» — это цель, то да, способы её достижения через задачи (запрячь, купить) сейчас и в будущем будут давать разные наборы задач.
тогда было бы более правильным считать, что на Этапе 4 происходит не проектирование задач, а ПЕРЕ-проектирование.
Да перевод стандарта кривой (об этом тот же Сатин говорил).
Взять фразу «Designing user tasks, user–system interaction and user interface to meet user requirements, taking into consideration the whole user experience». Как её разобрать по частям? Главная часть — «designing… to meet», т.е. именно «подгон» или «ре-дизайн», о котором сказали чуть выше. А перевели: «проектирование… с учётом того-то».
Поэтому лучше читать всё в оригинале (хотя в данном случае это несколько затратно).
Взять фразу «Designing user tasks, user–system interaction and user interface to meet user requirements, taking into consideration the whole user experience». Как её разобрать по частям? Главная часть — «designing… to meet», т.е. именно «подгон» или «ре-дизайн», о котором сказали чуть выше. А перевели: «проектирование… с учётом того-то».
Поэтому лучше читать всё в оригинале (хотя в данном случае это несколько затратно).
Теперь про
Я правильно понимаю, что стандарт 9241 считает, что разработка ВСЕХ требований к продукту является этапом HCD-процесса?
Т.е. исполнители HCD-процесса должны уметь разрабатывать все возможные виды требований, согласно, например, ISO/IEC 29148:2011. Systems and software engineering — Life cycle processes — Requirements engineering?
Этап 3. Спецификация требований
В рамках процесса спецификации требований, стандарт рекомендует выполнять следующие действия:
Описать требования к продукту. …
Я правильно понимаю, что стандарт 9241 считает, что разработка ВСЕХ требований к продукту является этапом HCD-процесса?
Т.е. исполнители HCD-процесса должны уметь разрабатывать все возможные виды требований, согласно, например, ISO/IEC 29148:2011. Systems and software engineering — Life cycle processes — Requirements engineering?
В идеале, перечень требований должен быть полным на столько, чтобы давать возможность создать жизнеспособный продукт.
Для этого стандарт рекомендует создавать мультидисциплинарные команды. При этом стандарт не решает за нас, как именно мы достигнем этой самой мултидисциплинарности.
Если у нас команда из 5-10 человек, то все просто — все решили работать в рамках HCD-подхода и вместе формулируют требования.
Если у нас корпорация, в которой работают 20.000-30.000 сотрудников, скорее всего, HCD будет поддерживать какой-то отдел. И этот отдел будет консультироваться с другими отделами для написания требований. Кроме того, отдел будет приглашать специалистов со стороны. Например, Siemens, который разрабатывает решения для медицинской отрасли, нанимает на полную ставку врачей, для того, чтобы они участвовали в процессе HCD.
Для этого стандарт рекомендует создавать мультидисциплинарные команды. При этом стандарт не решает за нас, как именно мы достигнем этой самой мултидисциплинарности.
Если у нас команда из 5-10 человек, то все просто — все решили работать в рамках HCD-подхода и вместе формулируют требования.
Если у нас корпорация, в которой работают 20.000-30.000 сотрудников, скорее всего, HCD будет поддерживать какой-то отдел. И этот отдел будет консультироваться с другими отделами для написания требований. Кроме того, отдел будет приглашать специалистов со стороны. Например, Siemens, который разрабатывает решения для медицинской отрасли, нанимает на полную ставку врачей, для того, чтобы они участвовали в процессе HCD.
И ещё про проектирование:
Судя по всему, в состав проектных решений на этом этапе не попадают, как минимум:
1. Ключевые свойства системы/продукта
2. Устройство бизнес-процессов
3. Архитектура системы/продукта
4. Устройство подсистем продукта/системы
Т.е. тут речь идёт только о некотором подмножестве проектных решений про продукт/систему. Что же является предметом проектирования? Вот этот неоднородный безымянный набор «задачи + взаимодействие + интерфейс»?
Проектирование
Стандарт ISO 9241-210 рекомендует включать следующие действия в рамках этого этапа:
…
Спроектировать задачи пользователя, взаимодействие пользователя и системы, а также интерфейс, так, чтобы они соответствовали требованиям, сформулированным в рамках предыдущей фазы.
…
Судя по всему, в состав проектных решений на этом этапе не попадают, как минимум:
1. Ключевые свойства системы/продукта
2. Устройство бизнес-процессов
3. Архитектура системы/продукта
4. Устройство подсистем продукта/системы
Т.е. тут речь идёт только о некотором подмножестве проектных решений про продукт/систему. Что же является предметом проектирования? Вот этот неоднородный безымянный набор «задачи + взаимодействие + интерфейс»?
Совершенно верно, здесь упор делается именно на то, какие задачи пользователи будут выполнять в рамках нашего продукта, как они будут взаимодействовать с системой и как интерфейс будет поддерживать это взаимодействие.
Возможно, слово «проектирование», взятое из ГОСТа, вводит в заблуждение. Заменил там, где это необходимо на «дизайн/проектирование взаимодействия».
Возможно, слово «проектирование», взятое из ГОСТа, вводит в заблуждение. Заменил там, где это необходимо на «дизайн/проектирование взаимодействия».
Спасибо за статью. В идеале хочется увидеть советы по практическому внедрению HUD-подхода, например в JIRA.
Особенно порадовало "Если все хорошо, или у вас кончаются деньги, вы выпускаете продукт" :)
Особенно порадовало "Если все хорошо, или у вас кончаются деньги, вы выпускаете продукт" :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ISO 9241-210. Планирование и внедрение Human-Centered Design