Комментарии 38
Зачем менеджерам, аналитикам и, прости господи, клиентам интерфейсы прототипировать? Вряд ли у них без специфических знаний что-то хорошее получится, даже если их научат использовать конкретный инструмент. Ведь если у человека есть зеркалка и он умеет на ней кнопочки нажимать, то это совсем не значит, что он — фотограф.
Юля, вопрос правильный и мы его себе, конечно же, не один раз задавали. Ответ нашли, как всегда на рынке, анализируя опыт зарубежных конкурентов, которые и начали раньше и клиенты у которых более продвинуты. Вот видео доклада Синтия Бакани — менеджера по дизайну и юзабилити, Citi Cards (Сити Груп) www.youtube.com/watch?v=5A3wtNxbw2Y Она рассказывает с какими трудностями они как заказчики сталкивались в процессе разработки своих продуктов силами внешних разработчиков, в том числе и удаленных.
Есть еще один факт, добытый в общении с крупными российскими аутсорсерами, у них в обойме инструментов не один, а несколько разных сред протитипирования: и iRise, и Axure и GUI Design Studio, т.к. каждый крупный заказчик приходит со своими требованиями к инструментарию и если ты хочешь на него работать, то придется прикупить соответствующую лицензию.
С менеджерами и аналитиками вопрос отдельный. Сравним два форума аналитиков: российский www.uml2.ru/forum/ и беларусский analyst.by/forum/ В обоих присутствуют разделы по проектированию интерфейсов, правда белорусские коллеги продвинулись дальше, видать экспорториентированность (ИТ, а не энергоресурсы) их экономики, заставляет их шевелиться активнее.
Есть еще один факт, добытый в общении с крупными российскими аутсорсерами, у них в обойме инструментов не один, а несколько разных сред протитипирования: и iRise, и Axure и GUI Design Studio, т.к. каждый крупный заказчик приходит со своими требованиями к инструментарию и если ты хочешь на него работать, то придется прикупить соответствующую лицензию.
С менеджерами и аналитиками вопрос отдельный. Сравним два форума аналитиков: российский www.uml2.ru/forum/ и беларусский analyst.by/forum/ В обоих присутствуют разделы по проектированию интерфейсов, правда белорусские коллеги продвинулись дальше, видать экспорториентированность (ИТ, а не энергоресурсы) их экономики, заставляет их шевелиться активнее.
Вы так и не ответили: зачем поручать дизайн (в оригинальном смысле этого слова) людям, которые на нём не специализируются?
Если давать клиенту свободу, то получится классическое: «А наш бухгалтер сказал, что это кнопочка должна быть снизу, а фон зеленым».
Если давать клиенту свободу, то получится классическое: «А наш бухгалтер сказал, что это кнопочка должна быть снизу, а фон зеленым».
Считаю, что понятия «дизайн» и «прототип» не являются неразрывно связанными: зачастую даже детализированный прототип не обладает конечным дизайном. Первоочередная задача интерактивного прототипа: в достаточной степени точно определиться с расположением функциональных блоков, элементов интерфейса, контролов и описать функциональность, поведение, логику интерфейсной части приложения.
В этом свете, люди-специалисты своих предметных областей, которые впоследствии будут пользоваться разрабатываемой программой, намного лучше дизайнеров знают, как должен быть сформирован интерфейс, чтобы их работа была максимально удобной и продуктивной.
p.s. а в чём проблема сделать «эту кнопочку снизу, а фон зелёным», если бухгалтеру так удобнее? Прототип как раз призван выявить эти нюансы ещё до начала разработки, на стадии проектирования, чтобы не пришлось переделывать программу уже после реализации
В этом свете, люди-специалисты своих предметных областей, которые впоследствии будут пользоваться разрабатываемой программой, намного лучше дизайнеров знают, как должен быть сформирован интерфейс, чтобы их работа была максимально удобной и продуктивной.
p.s. а в чём проблема сделать «эту кнопочку снизу, а фон зелёным», если бухгалтеру так удобнее? Прототип как раз призван выявить эти нюансы ещё до начала разработки, на стадии проектирования, чтобы не пришлось переделывать программу уже после реализации
А вот вопрос: какие «специфические знания» с вашей точки зрения необходимы? Насколько я помню, был у нас как-бы веб-дизайнер. С кнопочками как раз у нее все было хорошо, и с CSS тоже неплохо, а вот с дизайном интерфейса никак. А именно был проект, по которому надо было старую CRM систему перевести на новые технологии и с расширением функционала, интерфейс планировался — веб вместо java-приложения (десктоп). Максимум, что сделал веб-дизайнер, так это задал цветовую гамму и стиль шрифта. Вся компоновка (по-моему, порядка 29 составных экранов, каждый из которых делится еще на несколько более простых, и таким образом более сотни кранов) была произведена менеджером, а не веб-дизайнером, который показал полную несостоятельность в данном вопросе. Оно и понятно, если мы говорим об интерфейсах сложных приложений (простенькие или представительские веб-сайты я не беру в рассмотрение и надеюсь автор комментария не их имел в виду), так как дело не в эстетике, не в цветовой палитре, а в компоновке элементов интерфейса, в удобстве расположения функциональных элементов, которые пляшут от требуемой функциональности, от специфики и стиля работы пользователя, от его требований и т.д. А с этим как раз работает менеджер (или аналитик, или… не важно как этот человек в каждой компании называется), тот, кто бок о бок работает с клиентом, практически живет в его компании, ощущает эту компанию. Передать это невозможно, а таскать дизайнера — глупо, так так тогда надо таскать пол команды.
Поэтому на практике мы выработали следующий подход: структуру интерфейса, элементы, отклики и пр. создает менеджер плотно работающий с клиентом на проекте. Эти интерфейсы отдаются дизайнеру (в компании есть дизайнер и есть верстальщик, это разные люди), который достаточно быстро стилизует интерфейсы, можно в той же программе. Если интерфейсы приняты и уже не требуют изменений, переходим к реализации — подключению к системе, здесь работает верстальщик и отчасти программист. Что мы выигрываем: время и терпение клиента (а это не мало, особенно на больших проектах), качество интерфейса, собственно время менеджера (как ни странно — объяснять по несколько раз дизайнеру, потом показывать клиенту, потом опят объяснять дизайнеру, потом опять клиент, снова дизайнер, клиент… и т.д. — это значительно больше, чем по указанной выше схеме), общее время, скорость разработки. Кстати про CRM: клиент был очень доволен интерфейсами, и все они были приняты с минимальными корректировками.
Поэтому на практике мы выработали следующий подход: структуру интерфейса, элементы, отклики и пр. создает менеджер плотно работающий с клиентом на проекте. Эти интерфейсы отдаются дизайнеру (в компании есть дизайнер и есть верстальщик, это разные люди), который достаточно быстро стилизует интерфейсы, можно в той же программе. Если интерфейсы приняты и уже не требуют изменений, переходим к реализации — подключению к системе, здесь работает верстальщик и отчасти программист. Что мы выигрываем: время и терпение клиента (а это не мало, особенно на больших проектах), качество интерфейса, собственно время менеджера (как ни странно — объяснять по несколько раз дизайнеру, потом показывать клиенту, потом опят объяснять дизайнеру, потом опять клиент, снова дизайнер, клиент… и т.д. — это значительно больше, чем по указанной выше схеме), общее время, скорость разработки. Кстати про CRM: клиент был очень доволен интерфейсами, и все они были приняты с минимальными корректировками.
Такой человек обычно называется UI/UX designer он и занимается проектированием интерфейса, часто в паре с аналитиком.
По идее это так, но что на практике?
В моей практике обычно так и происходит. Разве что аналитика часто нет — выполняю и его функции. Если совсем всё плохо/небольшой проект/бюджет/самому интересно, то и дизайном элементов сам занимаюсь (стили, оформление).
Думаю, аналогично тому как Вы занимаетесь работой дизайнера/аналитика на некоторых проектах — в небольших фирмах достаточно квалифицированные и неглупые менеджеры/аналитики могут заниматься созданием прототипов. Тем более, что в фирме может быть дизайнер/менеджер, но не быть UI/UX специалиста.
Ну это лично мое имхо
Ну это лично мое имхо
В компаниях (даже довольно крупных, ~200 сотрудников) которые ещё не осознали необходимость специалистов-проектировщиков, разработкой прототипов занимаются аналитики. Крайне редко менеджеры (судя по моему опыту).
Проблема в том, что аналитики затачивают прототипы хорошо если под решение конкретных задач, при этом слабо учитываются конечные ЦЕЛИ пользователей и, соответственно, всё очень тяжко с написанием хороших сценариев использования продукта. Из-за этого уже на этапе предпродакшена могут обнаруживаться довольно серьёзные ошибки проектирования, исправлять которые чаще всего уже очень дорого и на это просто забивают — мол так и надо.
В итоге часто получается, например, так, что важные и часто используемые пользователем функции прячутся в глубине меню и диалогов, а пользователь… Пользователь привыкает, считает, что так и надо. А продуктивность и комфорт использования продукта сильно снижается: клики, клики, клики…
Проблема в том, что аналитики затачивают прототипы хорошо если под решение конкретных задач, при этом слабо учитываются конечные ЦЕЛИ пользователей и, соответственно, всё очень тяжко с написанием хороших сценариев использования продукта. Из-за этого уже на этапе предпродакшена могут обнаруживаться довольно серьёзные ошибки проектирования, исправлять которые чаще всего уже очень дорого и на это просто забивают — мол так и надо.
В итоге часто получается, например, так, что важные и часто используемые пользователем функции прячутся в глубине меню и диалогов, а пользователь… Пользователь привыкает, считает, что так и надо. А продуктивность и комфорт использования продукта сильно снижается: клики, клики, клики…
Я бы такие прототипы заказчику не показывал. Прототип должен быть схемотичным с заметками поясняющими принцип действия, а не работающим функционалом.
Зачем реально ресайзить колонку, если без комментария заказчик даже не подумает её таскать.
то же с сортировкой, зачем реальная сортировка без описания по какому принципу она строится и без явного обозначения что такой функционал есть.
опять же сворачивание-разворачивание блоков, действия абсолютно неявные, особенно для неопытных пользователей.
Я бы добрую часть функционала не заметил и засыпал бы вас вопсросами, а в ответ вы бы писали — а кликни правой кнопкой мыши туда (+скриншот).
Обязательно добавьте комментирование всех возможных действий и их описание. А вообще, конечно здорово смотрится, хоть используй для сайтов визиток как CMS.
Зачем реально ресайзить колонку, если без комментария заказчик даже не подумает её таскать.
то же с сортировкой, зачем реальная сортировка без описания по какому принципу она строится и без явного обозначения что такой функционал есть.
опять же сворачивание-разворачивание блоков, действия абсолютно неявные, особенно для неопытных пользователей.
Я бы добрую часть функционала не заметил и засыпал бы вас вопсросами, а в ответ вы бы писали — а кликни правой кнопкой мыши туда (+скриншот).
Обязательно добавьте комментирование всех возможных действий и их описание. А вообще, конечно здорово смотрится, хоть используй для сайтов визиток как CMS.
Я не спорю, что некоторого функционала на данный момент еще недостает (как впринципе и в любом развивающемся продукте). Как Вы и сказали — необходима возможность размещать встроенные комментарии и подсказки по всему прототипу, чтобы было ясно что для чего предназначено в прототипе.
Но насчет того, что такие прототипы не стоит показывать заказчику — я не согласен. Много уже всего писали по данной теме, к примеру, что подробные прототипы отвлекают внимание заказчика от общих целей проекта. Но в то же время скетчи могут вызвать в итоге множество неточностей в реализации, которые очень прилично съедают времени при переписывании.
Это лишь один частный пример — у обоих вариантов есть и плюсы и минусы, о которых неоднократно писалось в различных источниках, поэтому, мне кажется, здесь все совсем неоднозначно.
Но насчет того, что такие прототипы не стоит показывать заказчику — я не согласен. Много уже всего писали по данной теме, к примеру, что подробные прототипы отвлекают внимание заказчика от общих целей проекта. Но в то же время скетчи могут вызвать в итоге множество неточностей в реализации, которые очень прилично съедают времени при переписывании.
Это лишь один частный пример — у обоих вариантов есть и плюсы и минусы, о которых неоднократно писалось в различных источниках, поэтому, мне кажется, здесь все совсем неоднозначно.
согласен на 100%, возможны разные взгляды и подходы, они как правило зависят от способа взаимодействия с заказчиком и процесса разработки.
А способ взаимодействия с заказчиком и процесса разработки может быть абсолютно разным у разных фирм. Так как мы исходно ориентировались на свою и знакомые нам фирмы — возможно их специфика сыграла свою роль и видоизменила некоторый функционал и исходную идею.
Впрочем, раз мы рассчитываем продвигать продукт в «широкие массы» — непременно исправимся и подкорректируем все возникшие несоответствия.
Впрочем, раз мы рассчитываем продвигать продукт в «широкие массы» — непременно исправимся и подкорректируем все возникшие несоответствия.
Не согласен с тем, что прототип должен быть схематичным всегда. На мой взгляд, требуемая степень детализации (достоверности, точности) прототипа всегда зависит от конкретного проекта, конкретного заказчика, его пожеланий и требований.
В первом примере мы имели дело с заказчиком, очень требовательным к интерфейсу. Схематичное расположение элементов и функциональных блоков мы зарисовывали на бумаги, после чего на их основе делали точный детализированный прототип именно по требованию заказчика. Что и как должно работать детально обсуждалось (совместно с заказчиком) и опять же записывалось на бумаге. Так что ситуаций, в которых заказчик не знает, куда нажать, у нас не было. Да и прототип мы показывали ему своими руками.
Хотя, конечно, в большинстве случаев работа с заказчиком идёт удалённо, поэтому полностью согласен с Вашим замечанием относительно необходимости заметок. Вообще говоря, эта функциональность уже есть в планах развития инструмента
В первом примере мы имели дело с заказчиком, очень требовательным к интерфейсу. Схематичное расположение элементов и функциональных блоков мы зарисовывали на бумаги, после чего на их основе делали точный детализированный прототип именно по требованию заказчика. Что и как должно работать детально обсуждалось (совместно с заказчиком) и опять же записывалось на бумаге. Так что ситуаций, в которых заказчик не знает, куда нажать, у нас не было. Да и прототип мы показывали ему своими руками.
Хотя, конечно, в большинстве случаев работа с заказчиком идёт удалённо, поэтому полностью согласен с Вашим замечанием относительно необходимости заметок. Вообще говоря, эта функциональность уже есть в планах развития инструмента
Вы не первый, кто нам об этом говорит :)
Однако, наш дизайнер, создавший логотип, не знал про эту игру и никогда её ранее не видел.
У дизайнеров мысли сходятся
Однако, наш дизайнер, создавший логотип, не знал про эту игру и никогда её ранее не видел.
У дизайнеров мысли сходятся
НЛО прилетело и опубликовало эту надпись здесь
Предлагаете прилюдно казнить нашего дизайнера?)
Мы уже пытали её на тему заигрывалась ли она в WorldOfGoo, но расколоть так и не удалось.
На самом деле, похожа только идея головы, как мне кажется…
Впрочем это всё слишком высокие материи, так что я не буду спорить на эту тему.
Мы уже пытали её на тему заигрывалась ли она в WorldOfGoo, но расколоть так и не удалось.
На самом деле, похожа только идея головы, как мне кажется…
Впрочем это всё слишком высокие материи, так что я не буду спорить на эту тему.
«Кругляшки туловища и хвостика абсолютно идентичны» — это потому что я наложил мордашку из ВорлдОфГуу на логотип Гуи Машин.
Совершенно невозможно, чтобы моя коллега, глядя мне в глаза, врала о том, что не видела ранее эту игру…
я верю в людей и их честность :)
я верю в людей и их честность :)
Игрулину мы, конечно, заметили, но уже после того, как порешили с лого… В любом случае, связи тут особо никакой нет. Может в будущем найдем что поуникальнее ;)
Однозначно прослеживается характерный глазной гипертелоризм, округлость и идентичная радиальная градиента брюшного и хвостового отделов. С моей точки зрения обе особи — ближайшие родственники, но Гуй Машин выглядит умнее, причем значительно.
А рассказать про то как проектировали интерфейс своего инструмента прототипирования можете?
Учитывали ли вы опыт конкурентов? Какие вы выделяете в интерфейсе своей программы преимущества, какие недостатки?
Учитывали ли вы опыт конкурентов? Какие вы выделяете в интерфейсе своей программы преимущества, какие недостатки?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Основным ограничением демо-версии является отсутствие возможности сохранения проектов.
В скором времени с обзором продукта мы выложим здесь уникальные двухмесячные тестовые тестовые лицензии, дающие доступ ко всей функциональности продукта.
В скором времени с обзором продукта мы выложим здесь уникальные двухмесячные тестовые тестовые лицензии, дающие доступ ко всей функциональности продукта.
P.S. Я, конечно, не Станислав но лучше осведомлен в данном вопросе ;)
НЛО прилетело и опубликовало эту надпись здесь
Именно поэтому сы сейчас немного изменяем и вскоре представим на всеобщий суд демо-лицензии.
Вариантов много, например, не закрывать приложение. Если серьезно, мы предоставляем несколько способов вполне легального использования полноценных лицензий, с ними можно ознакомиться на сайте, кроме того, готовы совешенно бесплатно оживить присланный вами интерфейс в целях демонстрации возможностей продукта.
Ценовая же политика — это вообще предмет отдельного разговора. На предложения о высокой стомости, я спрашиваю, а за сколько бы вы купили этот продукт прямо сейчас?
Ценовая же политика — это вообще предмет отдельного разговора. На предложения о высокой стомости, я спрашиваю, а за сколько бы вы купили этот продукт прямо сейчас?
Поясню, что под «готовы совешенно бесплатно оживить присланный вами интерфейс» имеется в виду то, что мы можем отрисовать Ваш проект по предоставленным Вами данным в GUI Machine и предоставить готовый проект Вам :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История создания инструмента прототипирования. Часть II