Разорвать замкнутый круг - Несгибаемое намерение юзабилиста
guiXote
ОС Windows, http://news.bbc.co.uk/2/hi/technology/8388253.stm - не
всегда у фирм хватает смелости признать ошибку и найти решение
Как-то в UX Rus уже обсуждалась тема, посвященная внутренним качествам
юзабилити-специалиста.
В российской действительности юзабилисту, помимо "гибкости" и
"эмпатийности" и многих других качеств, необходимо обладать
несгибаемым намерением.
Опыт работы с фирмами, у которых цикл разработки программных продуктов
устоялся за много лет, показывает, что мудрости, почерпнутые из книг
гуру-юзабилистов, редко можно осуществить на практике.
Сфера создания программных продуктов - это, как в клипе, строительство
самолета на лету http://www.youtube.com/watch?v=L2zqTYgcpfg
На моем опыте попытки внедрить в нескольких фирмах (например, до 100
человек) целый этап проектирования с нуля очень сложно, приходится
придумывать для каждого случая свои приемы и методики
Часто бывает так, что цикл разработки фирмы не просто устоялся, а
закостенел (словно танк, прущий напролом...) и для того, чтобы
изменить что-либо в будущем продукте (на любой стадии) необходимо быть
очень настойчивым, и не привязываться к этапам разработки, а внедрять
элементы "философии юзабилити" во весь цикл, во всю фирму...
Tolik
произойдет сам собой когда в отрасль придут молодые специалисты
воспитанные на книжка гуру.
И если никак не получается внедрить в процесс юзабилити-
проектирование, то наверно это и не нужно этой группе разработчиков
(вечный позор им!)
On 1 дек, 20:53, guiXote <bifurcation.po...@gmail.com> wrote:
> Интересная новость о попытках исправить всем знакомый "синий экран" в
> ОС Windows,http://news.bbc.co.uk/2/hi/technology/8388253.stm- не
> всегда у фирм хватает смелости признать ошибку и найти решение
>
> Как-то в UX Rus уже обсуждалась тема, посвященная внутренним качествам
> юзабилити-специалиста.
> В российской действительности юзабилисту, помимо "гибкости" и
> "эмпатийности" и многих других качеств, необходимо обладать
> несгибаемым намерением.
> Опыт работы с фирмами, у которых цикл разработки программных продуктов
> устоялся за много лет, показывает, что мудрости, почерпнутые из книг
> гуру-юзабилистов, редко можно осуществить на практике.
>
> Сфера создания программных продуктов - это, как в клипе, строительство
> самолета на летуhttp://www.youtube.com/watch?v=L2zqTYgcpfg
guiXote
On 2 дек, 15:17, Tolik <danilov.icer...@gmail.com> wrote:
> произойдет сам собой когда в отрасль придут молодые специалисты
> воспитанные на книжка гуру.
фирмы =)
> И если никак не получается внедрить в процесс юзабилити-
> проектирование, то наверно это и не нужно этой группе разработчиков
> (вечный позор им!)
В этом и парадокс,
какой-то человек приближенный к начальству или начальство
в теории понимают, что проектирование, тестирование и прочее нужно,
но на практике опасаются реализовывать
Victor Glushenkov
<bifurcat...@gmail.com> написал:
> В этом и парадокс,
> какой-то человек приближенный к начальству или начальство
> в теории понимают, что проектирование, тестирование и прочее нужно,
> но на практике опасаются реализовывать
прагматизм, ибо ни фирме дополнительных денег это не принесёт (по
сравнению с финансовыми затратами на проектирование и переделку), ни
пользователям от этого сильно лучше не станет. Вот 10 минут назад
прочитал рецензию на очередной интерфейс одного знакомого
проектировщика-идеалиста. По сути замечания и предложения верные, но
нужны ли они разработчикам софта? Боюсь, нет. Мы живём в несовершенном
мире, и усилия проектировщиков интерфейсов следует направлять в первую
очередь в ту сторону, где они что-то принципиально изменят. При этом
вокруг будет продолжать существовать много несовершенных вещей. :) А
делать правильный и хороший интерфейс для 10 пользователей (если это
не оператор атомной станции или ЦУПа) это как-то, знаете ли…
Заур Гиясов
Проектирование - важный и нужный этап разработки. Без него никуда. Но отписываемые заказчиками бюджеты не позволяют в посвятить время на изучение и описание предметной области через use cases и user stories в полном объеме, сбора и классификации информации о пользователях и т.п.
По большей части это может быть реализовано небольшими усилиями в сторону изучения аудитории и особенностей предметной области и создания прототипов (статичных или динамических). Ну и описание взаимодействия пользователей с системой также может быть реализованы менее детально, чем того требуют "...книжки гуру..."
Детальное проектирование требует значительных затрат, которые попросту не покроються выделяемыми бюджетами. Увы но факт. Поэтому командам, понимающим важность этапа проектирования, приходится по разному искать выходы из сложившейся ситуации...
guiXote
On 2 дек, 19:33, Заур Гиясов <zaur.giya...@gmail.com> wrote:
> Невозможно внедрить процесс проектирования интерфейсов в том академическом
> виде, который обсуждается в данном сообществе для большинства студий.
> Особенно региональных. (говорю про веб)
По вашему получается, что то, что здесь обсуждается не применимо на
практике?
я как раз думал, что как раз наоборот - сообщество для того, чтобы
делится реальным опытом =)
Есть ли вас опыт внедрения неакадемического "регионального"
проектирования? и реально ли это влияет на успешность бизнеса и фирмы
в целом?
>усилия проектировщиков интерфейсов следует направлять в первую
очередь в ту сторону, где они что-то принципиально изменят.
Согласен =) только кто определяет эту грань "принципиального
изменения", которое
"нужно разработчикам софта"?
Часто "нужность", бюджет, сроки определяют всего не сами
разработчики.
Видимо, пока конкуренция не прижмет и не заставит начальство фирмы
понять, что нужно искать новые пути решения проблем - на сцену выйдет
"юзабилити" - только надо еще юзабилисту доказать, что это
действительно решение каких-то проблем, а не создание новых.
На конференции WUD09 Артем Горбунов привел массу примеров, когда
успешность проекта определяет не юзабилити - а бизнес-модель.
А в свою очередь UsabilityLab рассказывали, что они могут определить в
чем проблема клиента - в юзабилити продукта или в бизнес-модели.
Соответственно, пока в регионах не появятся такие осознающие клиенты,
которые смогут поменять бизнес-модель, если что... проку от
"юзабилити" не будет...
Pavel A.
клиенты знают о том что есть такой этап. Хотя понятно, что результат
этого этапа разработки, будет понятен клиенту, больше чем написание ТЗ
и даже реализация проекта (программирование).
Что будет делать компания-разработчик, если раз за разом у него помимо
кучи бумаги будут просить спроектированный прототип, и подтверждение
его адекватности?
Мне кажется философию надо обращать не сколько на разработчиков,
сколько на клиента, и тогда будет всем счастье. Рынок специалистов
конечно может и поднапряжется и возникнет дефицит, но рано или поздно
все устаканиться.
А сейчас на мой взгляд идет клиент может смотреть на проектирование
как на "искусственно сформированную потребность". Да и не каждая
компания может признаться себе в том что она ставит пользователя
далеко не на первое место, делая продукт для него.
Ещё важным моментом можно назвать то что рынки разработки
формировались по разному ( у нас и в США допустим) и сейчас они
разные. У нас все под заказ, в США-коробки. И вопрос: где важнее
юзабилити и где оно играет большую роль с точки зрения moneymaker-
ов?
Заур Гиясов
По вашему получается, что то, что здесь обсуждается не применимо на
On 2 дек, 19:33, Заур Гиясов <zaur.giya...@gmail.com> wrote:
> Невозможно внедрить процесс проектирования интерфейсов в том академическом
> виде, который обсуждается в данном сообществе для большинства студий.
> Особенно региональных. (говорю про веб)
практике?
я как раз думал, что как раз наоборот - сообщество для того, чтобы
делится реальным опытом =)
Нет :) Вы неверно истолковали. Все, что обсуждается в сообществе - очень правильные мысли. Но они годятся либо для очень крупных команд для для команд, которые специализируются только на проектировании. А дальше уже, немного упростив механику, они очень хорошо кладутся на реальность небольших команд по разработке.
Андрей Сикорский
механику, чтобы проектирование легло в разработку - м? Поделитесь
своим опытом (или опытом знакомых - их тоже можно подключить)?
вопросов несколько: что упростить, что подкрутить и как вместе жить
(список можно расширить)
Alexandr Kramer
> А сейчас на мой взгляд идет клиент может смотреть на проектирование
> как на "искусственно сформированную потребность". Да и не каждая
> компания может признаться себе в том что она ставит пользователя
> далеко не на первое место, делая продукт для него.
--------------------------
По идее, степень заинтересованности клиента (любого, имхо) зависит от
тех последствий внедрения продукта, на которые он рассчитывает. Здесь,
как мне кажется, уже и по российским случаям должно быть достстаточно
примеров для обобщений; при этом в принципе можно ведь для каждой
группы обобщений показать, какая доля последствий ляжет на юзабилити.
Деньги ведь платятся за результат - то есть за последствия ("вы
говорили, что разработка нового интерфейса даст именно это - ну и где
именно это?") - разве нет?
И насчет "искусственности" потребности: тут, что называется, вопрос
этики и эстетики. Видит, к примеру, разработчик, что интерфейсом тут
ничего не исправить, толку при данном менеджменте будет ноль, но
заказчик хочет, ему уже плешь протерли коллеги, у других-то хоть по
разу, а юзабилити уже разрабатывалось. Разработчик видит, что толку
никакого, отказывается, например, ну так заказчик другого найдет, не
такого щепетильного (деньги они вещь нужная) - а потом будет по углам
говорить о том, что "ну никакого толку нету, создали потребность на
пустом месте, деньги только вот потратил"...
--
С уважением,
Alexandr mailto:aykr...@gmail.com
Заур Гиясов
--
С уважением, Заур Гиясов
Креативный директор STUDIA7
8 (8442) 98-01-43, 98-01-78
he...@studia7.com
www.studia7.com