Comments 20
Спасибо за хорошую статью!
Вашу статью сложно отнести к интерфейсам, или юзабилити, ведь вы описываете процесс функционирования не столько сайта, не столько интернет-платформы, сколько недостатки функционирования большого количества компаний.
А ведь часто даже даже не интернет-бизнес развивается по данной схеме. Взять, например, моего провайдера: бывает, что приходится рассказывать одну историю 2-4 людям в техподдержке
Вашу статью сложно отнести к интерфейсам, или юзабилити, ведь вы описываете процесс функционирования не столько сайта, не столько интернет-платформы, сколько недостатки функционирования большого количества компаний.
А ведь часто даже даже не интернет-бизнес развивается по данной схеме. Взять, например, моего провайдера: бывает, что приходится рассказывать одну историю 2-4 людям в техподдержке
Ваш пост любопытен как взгляд аналитика на некую комплексную организацию всех процессов и развития бизнеса, но к юзабилити имеет косвенное отношение. Вы затрагивает вопросы организации процессов, доходите чуть ли не до логистики, но процесс проектирования взаимодействия не подразумевает проектирование всего остального. Наоборот, в процессе проектирования интерфейса происходит аналитика уже построенных процессов, инфраструктуры, некомпетентного персонала, негативных отзывов, и с помощью интерфейсных решений влияние этих факторов на достижение целей пытаются сгладить (а может и вообще их искоренить).
Мне кажется, ваш пост относится к другому блогу, связанному скорее с построением бизнеса.
Мне кажется, ваш пост относится к другому блогу, связанному скорее с построением бизнеса.
>в процессе проектирования интерфейса происходит аналитика уже построенных процессов, инфраструктуры, некомпетентного персонала, негативных отзывов, и с помощью интерфейсных решений влияние этих факторов на достижение целей пытаются сгладить
Вот иллюстрация этому подходу.
1. Сделали машину. Ага, нужны педали (почему? Ну все вроде ставят, значит нужны). Педали сделали но не приделали к тормозам. Негативные отзывы пользователей. Ну что ж, значит их к тормозам нужно все же приделать!
2. Сделали машину. Чтобы добраться из точку А в точку Б ей нужно ускоряться и тормозить. Как управлять ускорением? Ну… можно педалью. Как управлять тормозом? Другой педалью, чтобы запрограммировать исключение или/или.
Какой подход более правильный?
Вот иллюстрация этому подходу.
1. Сделали машину. Ага, нужны педали (почему? Ну все вроде ставят, значит нужны). Педали сделали но не приделали к тормозам. Негативные отзывы пользователей. Ну что ж, значит их к тормозам нужно все же приделать!
2. Сделали машину. Чтобы добраться из точку А в точку Б ей нужно ускоряться и тормозить. Как управлять ускорением? Ну… можно педалью. Как управлять тормозом? Другой педалью, чтобы запрограммировать исключение или/или.
Какой подход более правильный?
В последнее время все чаще вижу юзабилистов, жаждущих позаниматься проектированием вместо того, что от них ждут — увеличения одних кнопочек, уменьшения других и сокращения количества кликов. Некоторые на этом не останавливаются и стремятся еще и реорганизовывать процессы разработки программ.
Мне кажется, это от отсутствия внимания и интоксикации Аланом Купером. Понятное дело, художников в эти области пускать опасно, если они не обладаю солидным техническим запасом.
Но рациональное зерно в статье вижу такое: с юзабилистом надо советоваться чуть чаще, чем обычно принято. А то будет трудно.
Мне кажется, это от отсутствия внимания и интоксикации Аланом Купером. Понятное дело, художников в эти области пускать опасно, если они не обладаю солидным техническим запасом.
Но рациональное зерно в статье вижу такое: с юзабилистом надо советоваться чуть чаще, чем обычно принято. А то будет трудно.
Правильно конечно когда проектирует аналитик. Тем не менее проектирование очень часто отдается на самотек программистам, а отсюда получаются кадавры, которые вроде и сделаны неплохо, только вот пользоваться невозможно.
И за неимением аналитика юзабилист лучше видит функционал со стороны пользователя, чем кодер.
Нужно только чтобы он не витал в облаках и использовал требуемое количество ресурсов. Если ему нужно сделать черенок для лопаты, а он предлагает построить экскаватор — нужно ему намекать, что это не то что сейчас нужно ;)
И за неимением аналитика юзабилист лучше видит функционал со стороны пользователя, чем кодер.
Нужно только чтобы он не витал в облаках и использовал требуемое количество ресурсов. Если ему нужно сделать черенок для лопаты, а он предлагает построить экскаватор — нужно ему намекать, что это не то что сейчас нужно ;)
А это не доклад для РИФА часом? :)
В тему: «Тут все понятно — люди открывают сетевой магазин и ждут, что сейчас им сорвут е-двери с е-петель. Но по этим магазинам никто особенно не ходит, потому что недостаточно вывалить товар на е-прилавок» (с) tema
Я бы на месте автора перенес бы в блог «Анализ и проектирование систем» (http://habrahabr.ru/blogs/sysan4dummies/).
Я тоже по роду деятельности близок к бизнес-аналитике, и тематика того блога мне кажется более подходящей для этой статьи.
P. S. Спасибо за содержательную статью!
Я тоже по роду деятельности близок к бизнес-аналитике, и тематика того блога мне кажется более подходящей для этой статьи.
P. S. Спасибо за содержательную статью!
А почему вы при проектировании не пользуетесь такими методологиями, как, например, IDEF'ы? или use-case диагараммы, которые позволяют наглядно отразить те же самые цели пользователей
Поздравляю, Вы в статье описали основы user experience design (проектирование опыта взаимодействия), который является смежным термином с юзабилити. Фокус юзабилити — это удобство пользования продуктом/услугой, а UX — как, кто и зачем ими будет пользоваться.
Мне кажется, в какой-то момент стоит посмотреть на все эти деления и спросить себя «Стоп, а нафига нам столько делений и что реально нам это дает?». Если компания может себе позволить держать двух отдельных людей — юзабилиста и юзер экспириенсера (как по-русски-то? :) ), то разделение имеет смысл. Иначе — нет.
Я к тому, что это немного разные виды деятельности имеющие свои разные задачи и подходы к их решению. И в абсолютном большинстве случаев в жизни эти две роли совмещаются (также и со смежными ролями — от бизнес-аналитика до проектировщика интерфейсов). Тут всё зависит от уровня специалистов и масштабов проекта.
«Процессный подход к проектированию интерфейсов»?
Я бы сказал так: «Поверхностный обзор бизнес-процессов интернет-магазина и нытьё на около-дизайнерскую тему».
О чём статья, что хотел донести автор, ничего не понял.
Я бы сказал так: «Поверхностный обзор бизнес-процессов интернет-магазина и нытьё на около-дизайнерскую тему».
О чём статья, что хотел донести автор, ничего не понял.
Некоторым статья будет полезна, например, юному брату жены моего брата (: который рвет и мечет от желания открыть интернет-магазин и заниматься «легкой» торговлей. Я понимаю, что это не так просто и подводных камней много, но доступно объяснить ему не могу. Дам почитать.
Очень хорошо. :) Очень нужный и важный текст. Может быть он действительно поможет кому-то пересмотреть свой взгляд на ведение дел.
Юзабилити — это не только экранные формы, но оптимизация любого взаимодействия. Чего угодно с чем угодно. К сожалению современные проектировщики об этом забывают.
Юзабилити — это не только экранные формы, но оптимизация любого взаимодействия. Чего угодно с чем угодно. К сожалению современные проектировщики об этом забывают.
Может быть статья для обычных людей, а не для дизайнеров интерфейсов, но кнопочками занимаются UI дизайнеры, а как раз процессом занимаются UX проектировщики. И если UX дизайнер начинает заниматься только кнопочками, то есть смысл ставить под сомнение его профпригодность.
Sign up to leave a comment.
Процессный подход к проектированию интерфейсов