January 30, 2008

Простой и понятный дизайн приложений с помощью вариантов использования (use cases) по Роберту Хукману

useCase.gif
Возвращаемся к теме вариантов использования (use cases). В классическом понимании, варианты использования не должны описывать пользовательский интерфейс. Но как же тогда передать идею дизайна разработчику, и можно ли это формализовать? Роберт Хукман (Robert Hoekman), известный разработчик и дизайнер веб-приложений, предлагает собственный подход, который решает эту задачу.

Читаем дальше

Опубликовано kirsa в 4:49 PM | Комментарии (0)

January 14, 2008

Дональд Норман. Почему неправильно заниматься исследованием пользователей в начале проекта

Сколько раз вам приходилось бороться за возможность заняться полевыми исседованиями и прочими наблюдениями в самом начале проекта? Сколько раз вы терпеливо объясняли, что время, потраченное сейчас, окупится за счет быстрого распространения продукта на рынке? И сколько же раз ваши усилия увенчались успехом? В среде специалистов по человеко-машинному взаимодействию (HCI) уже давно слышны жалобы по поводу процессов разработки, которые не отводят в начале проекта время на тщательное исследование пользователей.

Чем больше я смотрю на это, тем больше мне кажется, что в данном случае не правы мы, специалисты по HCI. И я - не исключение, потому что и сам довольно долго пропагандировал подход "сначала изучить, а уже потом делать дизайн". Что ж, теперь я полагаю, что для многих проектов порядок действий должен быть обратным: сначала дизайн, а потом исследования.

Читаем дальше

Опубликовано kirsa в 6:25 PM | Комментарии (3)

May 10, 2004

"Программист или интерэкшн-дизайнер?", Ким Гудвин

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

В результате руководители уверены, что интерэкшн-дизайн им бесплатно сделают программисты. Им кажется, что интерэкшн-дизайнеры вообще не нужны: если программное приложение получится слишком сложным, они решат, что программистам нужен соответствующий психологический тренинг. Однако дизайн поведения программы, разработанный программистами, далеко не бесплатное приобретение. Такой дизайн не качественен, не эффективен и, к тому же, связан с серьезным риском.

Читаем дальше

Опубликовано kirsa в 6:52 PM | Комментарии (4)