Комментарии 43
Прототипы на ранних стадиях проекта очень важны. Они наглядны, в отличии от текстовых описаний, поэтому:
1. Лучше передают концепцию приложения.
2. Вовлекают в обсуждение — обсуждать картинки интереснее, чем текст.
3. Позволяют как можно раньше оценить интерфейсы и внести исправления в тот момент, когда изменения еще очень дешевые.
Т.о. прототипы позволяют контролировать серьезные риски.
1. Лучше передают концепцию приложения.
2. Вовлекают в обсуждение — обсуждать картинки интереснее, чем текст.
3. Позволяют как можно раньше оценить интерфейсы и внести исправления в тот момент, когда изменения еще очень дешевые.
Т.о. прототипы позволяют контролировать серьезные риски.
Спасибо, Дмитрий.
Мне кажется, что изготовление мокапа, работающего непосредственно на устройстве, вполне по силам дизайнерам UI. Современные инструменты позволяют создавать их, не прибегая к кодированию или ограничиваясь минимальным программированием. Это значит, что реализовать эту задачу можно за такой же срок и теми же усилиями, что и, к примеру, создав серию скринов в фотошопе.
Мне кажется, что изготовление мокапа, работающего непосредственно на устройстве, вполне по силам дизайнерам UI. Современные инструменты позволяют создавать их, не прибегая к кодированию или ограничиваясь минимальным программированием. Это значит, что реализовать эту задачу можно за такой же срок и теми же усилиями, что и, к примеру, создав серию скринов в фотошопе.
Как показала моя практика — html+jscript нет ничего лучше для быстрого прототипирования веб-приложения. На выходе получаем почти готовое рабочее решение + наброски дизайна, а последующее юзабилити тестирование выявит всевозможные огрехи интерфейса на ранней стадии разработки проекта.
Какие инструменты используете?
Для быстрых прототипов — бумагу и карандаш.
Для более прорисованных omnigraffle.
Для динамических пробовал разные (silverlight, catalist и очень много других), но остановился на связке html+jquery. Плюс в том, что можно сразу работать над дизайном приложения и видеть, что получается в реальности.
Иногда, если нужно очень быстро использую www.ixedit.com/.
Для более прорисованных omnigraffle.
Для динамических пробовал разные (silverlight, catalist и очень много других), но остановился на связке html+jquery. Плюс в том, что можно сразу работать над дизайном приложения и видеть, что получается в реальности.
Иногда, если нужно очень быстро использую www.ixedit.com/.
Народ, а для iOS что вы используете?
Есть классное, но недоделанное приложение interface для проектирования непосредственно на телефоне. А вообще, думаю, можно приспособиться Xcode юзать, используя в основном Interface Builder.
Я узаю keynotopia.com/, но хотелось бы иметь возможность генерировать интерфейс по прототипу
что-то как то бедственно описан процесс и инструментарий. особенно ничего не сказано про кросс-платформенное прототипирование. у нас есть некий опыт в этом, надо будет набраться времени и написать статью.
Есть хорошее правило: «Прототипировать надо только то, что нужно проверить. Т.е. реализовывать в прототипе нужно столько функциональности, сколько необходимо для проверки гипотез, ответов на вопросы и уточнения понимания Требований.» Если отойти от этого правила, то работа над прототипом очень легко выходит из под контроля, и есть очень большой шанс, что на подготовку нормального рабочего решения уже не хватит времени и ресурсов.
Второе. Прототипирование не должно подменять собой другие необходимые маркетинговые действия, и прежде всего — проработку сценариев использования. При проработке сценариев очень важно оперировать платформо-независимыми и интерфейсо-независимыми критериями. Попытка сперва нарисовать интерфейс, а потом описать сценарий использования этого интерфейса порочна. Дизайнер не владеет полностью идеей продукта, поэтому рисовать его будет в меру своего понимания, а потом вдруг оказывается, что именно такое кривое видение оказывается закрепленным в ТЗ.
В третьих, при таком раннем прототипировании есть очень большой шанс, что заказчики и пользователи начнут воспринимать прототип как «почти готовое приложение».
Но самое главное и самое большое возражение вот в чем. При раннем прототипировании, когда сценарии использования еще не проработаны, дизайнер, даже если у него есть общее описание логики работы программы, не владеет информацией о приоритезации различных частей программы. В результате он будет долго и тщательно прорисовывать экраны дополнительных настроек, а главные экраны могут быть не проработаны. При демонстрации подобного прототипа мнение о продукте у пользователей/Заказчика сложится совершенно неадекватное. Поэтому «горизонтальное» прототипирование можно делать только на этапе, когда сценарии уже завершены, общая конфигурация продукта согласована и утверждена.
Второе. Прототипирование не должно подменять собой другие необходимые маркетинговые действия, и прежде всего — проработку сценариев использования. При проработке сценариев очень важно оперировать платформо-независимыми и интерфейсо-независимыми критериями. Попытка сперва нарисовать интерфейс, а потом описать сценарий использования этого интерфейса порочна. Дизайнер не владеет полностью идеей продукта, поэтому рисовать его будет в меру своего понимания, а потом вдруг оказывается, что именно такое кривое видение оказывается закрепленным в ТЗ.
В третьих, при таком раннем прототипировании есть очень большой шанс, что заказчики и пользователи начнут воспринимать прототип как «почти готовое приложение».
Но самое главное и самое большое возражение вот в чем. При раннем прототипировании, когда сценарии использования еще не проработаны, дизайнер, даже если у него есть общее описание логики работы программы, не владеет информацией о приоритезации различных частей программы. В результате он будет долго и тщательно прорисовывать экраны дополнительных настроек, а главные экраны могут быть не проработаны. При демонстрации подобного прототипа мнение о продукте у пользователей/Заказчика сложится совершенно неадекватное. Поэтому «горизонтальное» прототипирование можно делать только на этапе, когда сценарии уже завершены, общая конфигурация продукта согласована и утверждена.
Мне кажется, что дизайнер UI просто обязан полностью владеть идеей продукта и «приоретизацией различных частей программы». И реализовывать прототип именно в ключе «почти готового приложения». Прелесть в том, что мокап можно 100 раз изменить при обсуждениях в команде и 100 раз — при обсуждении с заказчиком. И при этом никто не будет плакать, потому что пропадает полгода совместных усилий по проекту и срываются сроки.
Дизайнер обычно не участвует в подготовке маркетинговых документов, т.е. — в начальной проработке ТЗ. Обычно он получает его уже готовым. И лучше всего, если это ТЗ оперирует понятиями, отвязанными от интерфейса конкретной операционки. Только если разрабатывается что-то принципиально новое, то дизайнер привлекается для согласования на предмет трудозатратности реализации той или иной функциональности.
Давайте уточним, о каких типах проектов мы говорим? Я говорю не про стартапы, а про производственный процесс, когда продукты эволюционируют и развиваются. В таком случае роли в процессе разработки ПО уже четко распределены, и на позиции дизайнера UI находится действительно дизайнер, а не разработчик, освоивший Expression Blend. Если же говорить о стартапах, то тут все может быть очень кучеряво.
Давайте уточним, о каких типах проектов мы говорим? Я говорю не про стартапы, а про производственный процесс, когда продукты эволюционируют и развиваются. В таком случае роли в процессе разработки ПО уже четко распределены, и на позиции дизайнера UI находится действительно дизайнер, а не разработчик, освоивший Expression Blend. Если же говорить о стартапах, то тут все может быть очень кучеряво.
Я имел в виду разработку мобильных приложений. Конкретнее, не веб-приложений, а native applications, работающих на смартфоне. Собственно, глобальные проекты, в которых надо реализовать приложение на нескольких мобильных платформах, я бы тоже оставил за кадром — обсуждать это интересно, но проблемы там несколько другие.
В таком контексте дизайнер, находящийся «в теме» и создавший работоспособный прототип, находится в ключевой точке проекта, позволяя корректировать на основании работы с этим прототипом ТЗ, совершенствуя и добавляя сценарии использования и исправляя ошибки usability.
Таким образом, функционирующий прототип на этапе согласования ТЗ (начальной фазе проекта) помогает:
1. Окончательно сформировать ТЗ, обнаружить и исправить ошибки в нем, проработать и зафиксировать детали.
2. Показать заказчику примерный функциональный облик будущего приложения и получить его approve.
3. Внести полную ясность по задаче в команду разработчиков.
В таком контексте дизайнер, находящийся «в теме» и создавший работоспособный прототип, находится в ключевой точке проекта, позволяя корректировать на основании работы с этим прототипом ТЗ, совершенствуя и добавляя сценарии использования и исправляя ошибки usability.
Таким образом, функционирующий прототип на этапе согласования ТЗ (начальной фазе проекта) помогает:
1. Окончательно сформировать ТЗ, обнаружить и исправить ошибки в нем, проработать и зафиксировать детали.
2. Показать заказчику примерный функциональный облик будущего приложения и получить его approve.
3. Внести полную ясность по задаче в команду разработчиков.
Мне кажется, мы говорим о разных «дизайнерах». Вы больше говорите о «программисте, реализующем интерфейс». Я же говорю о дизайнере, который даже не имеет понятия, как интерфейс реализовывается программным кодом. В задачу такого дизайнера входит не только реализация интерфейса конкретного приложения, но и соблюдения общей идеологии интерфейса, принятого для компании, соблюдение требований BrandBook-а и тому подобное. Т.е. он может быть, был бы и рад поразбираться во всех тонкостях реализации алгоритма, да времени нет…
В том-то и дело, что современные среды разработки (IDE) обеспечивают рабочее место, в том числе и дизайнеру интерфейсов — человеку, далекому от алгоритмов и программирования, зато владеющему вопросами usability, эргономики приложения. В процессе проектирования интерфейса он должен сформировать ключевые блоки приложения, распределить функционал по экранам и детализировать по каждому экрану функциональные и информационные элементы. О графическом дизайне речи не идет и, по-хорошему, UI-дизайнер не должен им заниматься.
Вот это новость! Это как это?
О графическом дизайне речи не идет и, по-хорошему, UI-дизайнер не должен им заниматься.
О графическом дизайне речи не идет и, по-хорошему, UI-дизайнер не должен им заниматься.
Похоже, мы просто спорим о распределение ролей в проекте…
Да, это не то, что хотелось бы обсудить ;-).
Графический дизайн — чтобы было красиво, дизайн интерфейса — чтобы было удобно. Удобно — это чтобы пользователь быстро выполнил все задачи, которые хотел выполнить в приложении.
В прототипе пользователь видит, какие задачи он может решить с помощью приложения и насколько быстро/удобно.
Если у прототипа есть красивый графический дизайн — это замечательно, но можно и без него обойтись на начальном этапе.
Графический дизайн — чтобы было красиво, дизайн интерфейса — чтобы было удобно. Удобно — это чтобы пользователь быстро выполнил все задачи, которые хотел выполнить в приложении.
В прототипе пользователь видит, какие задачи он может решить с помощью приложения и насколько быстро/удобно.
Если у прототипа есть красивый графический дизайн — это замечательно, но можно и без него обойтись на начальном этапе.
Если UI-дизайнер не понимает, как это может реализовываться в программном коде, то это не UI-дизайнер, а просто дизайнер картинок, которые очень сильно похожи на интерфейс. К какому месту потом эти картинки лепить, не совсем понятно. Ему не нужно знать тонкости алгоритмов, но «толстости» обязан делать дизайнер, а не программист. Возьмем пример — реализация интерфейса работы со списком пользователей. Администратор системы должен иметь возможность
1. просматривать список пользователей с указанием их должности и отдела.
2. иметь возможность добавлять пользователей, редактировать их данные и удалять.
С первого взгляда все всем понятно. Нужно сделать интерфейс со списком пользователей и интерфейс добавления/редактирования пользователя.
Что будет на первом интерфейсе? Логично разбить таблицу со списком на отделы. Имя пользователя сделать ссылкой, чтобы можно было открывать интерфейс редактирования данного пользователя. Теперь стоит вопрос удаления. Напрашивается очевидный вариант — каждому пользователю по чекбоксу и одну кнопку удаления. А в реальности такое делать запрещено категорически. Удаление пользователя должно быть персональным, чтобы админ четко понимал, что он делает.
Что мы видим после прототипирования? Мы видим, что нужна сортировка по отделам, не нужна функция мультиудаления. На таких мелочах многократно сокращается время работы программеров.
1. просматривать список пользователей с указанием их должности и отдела.
2. иметь возможность добавлять пользователей, редактировать их данные и удалять.
С первого взгляда все всем понятно. Нужно сделать интерфейс со списком пользователей и интерфейс добавления/редактирования пользователя.
Что будет на первом интерфейсе? Логично разбить таблицу со списком на отделы. Имя пользователя сделать ссылкой, чтобы можно было открывать интерфейс редактирования данного пользователя. Теперь стоит вопрос удаления. Напрашивается очевидный вариант — каждому пользователю по чекбоксу и одну кнопку удаления. А в реальности такое делать запрещено категорически. Удаление пользователя должно быть персональным, чтобы админ четко понимал, что он делает.
Что мы видим после прототипирования? Мы видим, что нужна сортировка по отделам, не нужна функция мультиудаления. На таких мелочах многократно сокращается время работы программеров.
Мне кажется, идёт выдача желаемого за действительное.
Дизайнер интерфейсов — как резчик. Бывают резчики по дереву, по кости, по металлу… Специальность — одна, а вот специализаций — множество. Поэтому вполне логично, что дизайнер, имеющий очень хорошую квалификацию в разработке UI под MAC, будет очень долго приспосабливаться под Android. Даже в эпоху расцвета Windows Mobile дизайнерам с десктопной винды приходилось приспосабливаться под мобильную, и хороших дизайнеров под мобильные приложения было не найти. А выцепить на hh.com сразу специалиста по дизайну UI под Android просто так вряд ли удастся и сейчас.
Я это все говорю к тому, что тезис о понимании дизайнером аспектов реализации тех или иных интерфейсных элементов в коде и о предугадывании дизайнером аспектов программирования — это некая идеализация, которая хотя и может быть достижима в отдельных идеальных случаях (ваш дизайнер в комманде уже 5 лет и на мобильных интерфейсах собаку съел), в большинстве случаев остается утопией.
Поэтому всё то, что в вашем примере вам кажется логичным и само собой разумеющимся, должно быть детально отображено в документации, которую получает на руки дизайнер UI прежде чем приступить к работе. И именно в документации, а не на словах, иначе вы рискуете провалить сроки. И документация при этом должна оперировать понятиями общей функциональности и логического взаимодействия, а не описывать «кнопочки» и «скроллбары».
Дизайнер интерфейсов — как резчик. Бывают резчики по дереву, по кости, по металлу… Специальность — одна, а вот специализаций — множество. Поэтому вполне логично, что дизайнер, имеющий очень хорошую квалификацию в разработке UI под MAC, будет очень долго приспосабливаться под Android. Даже в эпоху расцвета Windows Mobile дизайнерам с десктопной винды приходилось приспосабливаться под мобильную, и хороших дизайнеров под мобильные приложения было не найти. А выцепить на hh.com сразу специалиста по дизайну UI под Android просто так вряд ли удастся и сейчас.
Я это все говорю к тому, что тезис о понимании дизайнером аспектов реализации тех или иных интерфейсных элементов в коде и о предугадывании дизайнером аспектов программирования — это некая идеализация, которая хотя и может быть достижима в отдельных идеальных случаях (ваш дизайнер в комманде уже 5 лет и на мобильных интерфейсах собаку съел), в большинстве случаев остается утопией.
Поэтому всё то, что в вашем примере вам кажется логичным и само собой разумеющимся, должно быть детально отображено в документации, которую получает на руки дизайнер UI прежде чем приступить к работе. И именно в документации, а не на словах, иначе вы рискуете провалить сроки. И документация при этом должна оперировать понятиями общей функциональности и логического взаимодействия, а не описывать «кнопочки» и «скроллбары».
Все правильно. Вот если ТЗ попадет к дизайнеру UI на этапе первых версий, он, в процессе создания прототипа, может найти там ошибки и принять участие в дополнении этого документа. И прототип в этом случае является рабочим инструментом для продумывания ТЗ всеми заинтересованными лицами проекта.
Опять повторюсь: всё зависит от выработанного в компании процесса работы. Если команда не большая, то да, дизайнер может и с прототипами поиграться, и в ТЗ поковыряться… В серьёзных конторах, когда «на конвейере» одновременно несколько проектов, а дизайнер — только один (а он, как правило один, ибо это очень дорогой и узкопрофильный специалист), то его рабочее время расшарено между проектами, и у него даже при всём желании нет возможности «поиграться» и «поразбираться». Максимум, как можно задействовать дизайнера в таком случае на ранних стадиях — привлечь его к согласованию ТЗ, дабы в него не прокрались «воздушные замки». Прототипированием такой дизайнер если и будет заниматься, то только в случае, если такие работы заранее прописаны в проекте и руководство дало «добро» на это.
Есть два подхода к разработке: дизайнер делает красивые картинки к тому, что сделали программеры и дизайнер, который делает прототипы. В основном все делают по первому варианту, а потом удивляемся, что проблемы с качественным продуктом.
Не вижу связи. Дизайнер следит за эргономикой, юзабельностью, соблюдением брендинга. За соблюдением удобства использования должен следить дизайнер взаимодействия. А за качеством реализации кода — девелопер менеджер.
И нет ничего плохого в том, что дизайнер делает «бумажные» прототипы. Этому их учат и это они умеют делать хорошо. Опять же, для каких целей. Для целей выяснения юзабилити бумажные прототипы ничуть не хуже, чем сделанные в виде ПО.
И нет ничего плохого в том, что дизайнер делает «бумажные» прототипы. Этому их учат и это они умеют делать хорошо. Опять же, для каких целей. Для целей выяснения юзабилити бумажные прототипы ничуть не хуже, чем сделанные в виде ПО.
Не очень понимаю распределение функций. Мне кажется так:
1. Графический дизайнер. Внешний вид, цветовая гамма, иконки, брендинг.
2. Дизайнер UI. Удобство использования, общая логика работы с интерфейсами приложения, эргономика элементов управления и пр.
3. Архитектор. Структура данных, общая архитектура приложения.
4. Разработчик. Код. Программная реализация всего, что наворотили Архитектор с Дизайнером UI.
Поясните, кто такой «дизайнер взаимодействия», может тогда все встанет на свои места.
1. Графический дизайнер. Внешний вид, цветовая гамма, иконки, брендинг.
2. Дизайнер UI. Удобство использования, общая логика работы с интерфейсами приложения, эргономика элементов управления и пр.
3. Архитектор. Структура данных, общая архитектура приложения.
4. Разработчик. Код. Программная реализация всего, что наворотили Архитектор с Дизайнером UI.
Поясните, кто такой «дизайнер взаимодействия», может тогда все встанет на свои места.
1. Системный архитектор (SA) — тот, кто следит, чтобы для всех продуктов соблюдалась Стратегия развития, чтобы проекты правильно и качественно взаимодействовали между собой. Именно он дает согласие на перенос той или иной функциональности «как-нибудь в следующей версии».
2. Маркетинг-Менеджер — определяет целесообразно ли разрабатывать приложение вообще и в каком именно виде его надо разрабатывать, какие пользовательские характеристики оно должно нести. В т.ч. именно ММ занимается Product Naming & Product Vision (рисует не он, разумеется, но обеспечивает процесс). Прорабатывает и актуализирует Концепцию продукта и Стратегию развития продукта, которые изначально должны быть подготовлены либо System Architect, либо руководителем проекта.
3. Проектировщик взаимодействия (Interaction Designer) — прорабатывает Сценарии использования продукта, Профили пользователей и готовит Общее описание продукта — то, на основании чего потом будет выработано ТЗ.
4. Development Manager — главный из разработчиков. Именно он на основании Общего описания продукта готовит ТЗ, по которому дальше будут работать его подчиненные.
5. UI Designer — разработчик интерфейса. Он получает Общее описание продукта для разработки интерфейса и для справки все остальные документы. При дизайне UI он руководствуется BrandBook и System GuideLine по текущей мобильной платформе. Работает он в паре с программистом, который ответственен за реализацию интерфейса.
6. Есть еще Testing Manager — бравый МЧ, который везде видит бяку и верховодит бандой «дураков», от которых программисты должны суметь поставить защиту. Утрирую. По факту, квалификация Testing Manager-а должна быть не ниже Development Manager-а, т.е. ведущего программиста. TM получает от DM код, который тестирует в соответствии с полученной от MM & ID документацией.
7. Всю эту команду пинает в хвост и в гриву Project Manager, который следит за соблюдением сроков и обеспечением рабочего процесса. Единственным его противником, который следит, чтобы от программы в процессе разработки не остались ручки да ножки, является System Architect.
В этой команде, как правило, нет Brand Designer, который разрабатывает BrandBook и конкретные иконки. Нет его просто потому, что это либо outsource, либо shared resource с другими проектами.
Если всё еще непонятно, зачем нужен Interaction Designer, то настоятельнейшим образом рекомендую прочитать книгу Алана Купера «Психбольница в руках пациентов». Вот после нее действительно всё встанет на свои места.
2. Маркетинг-Менеджер — определяет целесообразно ли разрабатывать приложение вообще и в каком именно виде его надо разрабатывать, какие пользовательские характеристики оно должно нести. В т.ч. именно ММ занимается Product Naming & Product Vision (рисует не он, разумеется, но обеспечивает процесс). Прорабатывает и актуализирует Концепцию продукта и Стратегию развития продукта, которые изначально должны быть подготовлены либо System Architect, либо руководителем проекта.
3. Проектировщик взаимодействия (Interaction Designer) — прорабатывает Сценарии использования продукта, Профили пользователей и готовит Общее описание продукта — то, на основании чего потом будет выработано ТЗ.
4. Development Manager — главный из разработчиков. Именно он на основании Общего описания продукта готовит ТЗ, по которому дальше будут работать его подчиненные.
5. UI Designer — разработчик интерфейса. Он получает Общее описание продукта для разработки интерфейса и для справки все остальные документы. При дизайне UI он руководствуется BrandBook и System GuideLine по текущей мобильной платформе. Работает он в паре с программистом, который ответственен за реализацию интерфейса.
6. Есть еще Testing Manager — бравый МЧ, который везде видит бяку и верховодит бандой «дураков», от которых программисты должны суметь поставить защиту. Утрирую. По факту, квалификация Testing Manager-а должна быть не ниже Development Manager-а, т.е. ведущего программиста. TM получает от DM код, который тестирует в соответствии с полученной от MM & ID документацией.
7. Всю эту команду пинает в хвост и в гриву Project Manager, который следит за соблюдением сроков и обеспечением рабочего процесса. Единственным его противником, который следит, чтобы от программы в процессе разработки не остались ручки да ножки, является System Architect.
В этой команде, как правило, нет Brand Designer, который разрабатывает BrandBook и конкретные иконки. Нет его просто потому, что это либо outsource, либо shared resource с другими проектами.
Если всё еще непонятно, зачем нужен Interaction Designer, то настоятельнейшим образом рекомендую прочитать книгу Алана Купера «Психбольница в руках пациентов». Вот после нее действительно всё встанет на свои места.
Отнюдь. Дизайнер интерфейсов не просто рисовальщик красивых картинок. В этом проблема большинства отечественных дизайнеров, они думают, что их задача заканчивается как раз на картинке. Приведу простой пример. Дизайнер интерьеров тоже дизайнер. Он просто обязан знать кучу технологических тонкостей, например, что у ванной есть слив, и про него нельзя забывать. Раковина должна быть на высоте примерно 90см от пола, иначе будет неудобно. Ширина дверей не может быть меньше 60 см, а более-менее нормальные двери шириной 90см. Дверь должна куда-то открываться, а значит и должно быть место под ее траекторию движения. Это все формирует мышление дизайнера.
Аналогично с интерфейсами. Кнопка не должна содержать много текста, иначе никто не будет ее читать. У кнопки есть как минимум три состояния: нормальное, подсвеченное, нажатое. Но могут быть вариации с неактивными кнопками и так далее. Но кнопки ничего не значат, они должны порождать какую-то реакцию на их нажатие. Например, нужно запустить процесс отправки формы на сервер. А это порождает следующий элемент — прогресс-бар для отображения процесса отправки данных. А результатом может быть как сообщение о том, что все Ок, так и сообщение об ошибке. А что делать, когда пришло сообщение об ошибке, показывать его вместе с формой, вместо формы? А нужно ли вообще сообщение о том, что все отправлено? И так далее. Приведенный мной пример платформонезависимый, так как конечная реализация будет на уровне картинок. UI-дизайнер придумывает не картинки, а процесс работы человека с интерфейсом. Потому что в ТЗ обычно пишут: «должна быть возможность отправки данных на сервер». И ни слова про процесс отправки, валидацию, сообщения об ошибках или о нормальном завершении процесса.
Аналогично с интерфейсами. Кнопка не должна содержать много текста, иначе никто не будет ее читать. У кнопки есть как минимум три состояния: нормальное, подсвеченное, нажатое. Но могут быть вариации с неактивными кнопками и так далее. Но кнопки ничего не значат, они должны порождать какую-то реакцию на их нажатие. Например, нужно запустить процесс отправки формы на сервер. А это порождает следующий элемент — прогресс-бар для отображения процесса отправки данных. А результатом может быть как сообщение о том, что все Ок, так и сообщение об ошибке. А что делать, когда пришло сообщение об ошибке, показывать его вместе с формой, вместо формы? А нужно ли вообще сообщение о том, что все отправлено? И так далее. Приведенный мной пример платформонезависимый, так как конечная реализация будет на уровне картинок. UI-дизайнер придумывает не картинки, а процесс работы человека с интерфейсом. Потому что в ТЗ обычно пишут: «должна быть возможность отправки данных на сервер». И ни слова про процесс отправки, валидацию, сообщения об ошибках или о нормальном завершении процесса.
Я не спорю про то, каким должен быть «идеальный» дизайнер. Я говорю про то, что чем более точно будет проработана документация (и особенно — сценарии использования продукта), тем проще будет работать и самому дизайнеру, и всем остальным членам команды.
А говорю я про это в контексте того, что первично: прототип или документация. Я стою на стороне того, что документация первична. На начальном этапе прототип уместен только в случае, когда надо что-то протестировать или когда просто нет другого способа уточнить общее ТЗ. Замещать подготовку документации прототипированием, как это предлагает топикстартер, на мой взгляд не верно в корне.
А говорю я про это в контексте того, что первично: прототип или документация. Я стою на стороне того, что документация первична. На начальном этапе прототип уместен только в случае, когда надо что-то протестировать или когда просто нет другого способа уточнить общее ТЗ. Замещать подготовку документации прототипированием, как это предлагает топикстартер, на мой взгляд не верно в корне.
Даже не думал предлагать замещать «подготовку документации прототипированием»! Просто высказываю предположение, что РАБОТАЮЩИЙ прототип очень сильно может помочь подготовить качественное ТЗ, покажет ошибки и заблуждения разработчиков и клиентов и внесет ясность в то, каким приложение будет на выходе в самом начале проекта.
Вот этого я и не понимаю — как можно подготовить работающий прототип, при помощи которого будет готовиться качественное ТЗ, и на котором разработчики увидят свои заблуждения? Как такой прототип сможет подготовить дизайнер, который не программист и который видит только предварительный вариант ТЗ? Где логика?
Объяснение может быть только одно: идейный вдохновитель проекта — сам программист, и чем писать документацию, ему проще сварганить быстренько прототип и потом показывать: «вот здесь видите, будет вот так… а здесь — вот так вот работаем...»
Такая схема работает только в стартапе. В нормальном процессе производства ПО она неприемлема.
Объяснение может быть только одно: идейный вдохновитель проекта — сам программист, и чем писать документацию, ему проще сварганить быстренько прототип и потом показывать: «вот здесь видите, будет вот так… а здесь — вот так вот работаем...»
Такая схема работает только в стартапе. В нормальном процессе производства ПО она неприемлема.
В том-то и дело, что прототип сейчас можно сделать без программирования. Инструментом, сильно напоминающим по подходам и сложности, к примеру, фотошоп или иллюстратор.
Логика простая:
1. Клиент передает функциональные требования.
2. Команда разработчиков превращает это в ТТ и начальную версию ТЗ.
3. Дизайнер UI воплощает это в первый прототип.
4. Прототип «крутится» в команде, помогая исправлять ТЗ. Прототип, естественно, тоже меняется.
5. Прототип тестится и обсуждается с заказчиком.
6. ТЗ фиксируется.
Вопрос в том, сколько времени и ресурсов понадобится на весь цикл. У меня ощущение, что недели будет достаточно.
Логика простая:
1. Клиент передает функциональные требования.
2. Команда разработчиков превращает это в ТТ и начальную версию ТЗ.
3. Дизайнер UI воплощает это в первый прототип.
4. Прототип «крутится» в команде, помогая исправлять ТЗ. Прототип, естественно, тоже меняется.
5. Прототип тестится и обсуждается с заказчиком.
6. ТЗ фиксируется.
Вопрос в том, сколько времени и ресурсов понадобится на весь цикл. У меня ощущение, что недели будет достаточно.
Неделя, как правило, уходит только на переписку с заказчиком для выяснения, чего он вообще хочет. Встреча, подробная беседа, пара дней на подготовку документа, передача документа на согласование, день на чтение документа заказчиком, «вы чего мне прислали?»… и так по кругу несколько раз.
Реализуя прототип на раннем этапе, обсуждая и тестируя его, вы оказываетесь заложником тех решений, которые были приняты в начале работы, при подготовке прототипа, когда еще не было четкого понимания конечного продукта. Зачастую заказчик сам до конца не понимает, чего он хочет. Если общаться с ним в терминах сценариев использования, не показывая общего прототипа, фиксации восприятия не произойдет, и UID не будет повязан по рукам и ногам первоначальной реализацией.
Я понимаю, откуда «ноги растут» у этой статьи — Expression Blend действительно очень быстро и легко позволяет рисовать интерфейсы, не занимаясь при этом программированием. И действительно возникает очень большой соблазн не заниматься бумагомаранием и подготовкой этих всяких ТЗ и прочея. Чё там?! Ща тут быстренько раз два… Будет готов прототип — его и покажем.
Решайте сами. Для простенькой игрульки, конечно, не имеет смысла разводить весь этот зоопарк с MM, AS, ID, DM, TM, PM, UID и остальными действующими лицами и исполнителями. Но если проект серьёзный, расчитан не на одну версию и не одну платформу (где нет такого щчастья типа Expression Blend), то без качественной проработки документации на начальном этапе не обойтись.
Реализуя прототип на раннем этапе, обсуждая и тестируя его, вы оказываетесь заложником тех решений, которые были приняты в начале работы, при подготовке прототипа, когда еще не было четкого понимания конечного продукта. Зачастую заказчик сам до конца не понимает, чего он хочет. Если общаться с ним в терминах сценариев использования, не показывая общего прототипа, фиксации восприятия не произойдет, и UID не будет повязан по рукам и ногам первоначальной реализацией.
Я понимаю, откуда «ноги растут» у этой статьи — Expression Blend действительно очень быстро и легко позволяет рисовать интерфейсы, не занимаясь при этом программированием. И действительно возникает очень большой соблазн не заниматься бумагомаранием и подготовкой этих всяких ТЗ и прочея. Чё там?! Ща тут быстренько раз два… Будет готов прототип — его и покажем.
Решайте сами. Для простенькой игрульки, конечно, не имеет смысла разводить весь этот зоопарк с MM, AS, ID, DM, TM, PM, UID и остальными действующими лицами и исполнителями. Но если проект серьёзный, расчитан не на одну версию и не одну платформу (где нет такого щчастья типа Expression Blend), то без качественной проработки документации на начальном этапе не обойтись.
Зачастую заказчик сам до конца не понимает, чего он хочет.
Именно поэтому ТЗ ничего не дает. Оно содержит некую интерпретацию разработчиком идей заказчика.
Но, как только заказчику показываешь прототип, у него сразу возникает набор рацпредложений и уточнений, что это не совсем удобно, что тут нужно вместо многих кусочков свести все воедино, что этот функционал избыточен, и можно сократить до простой кнопки «сделать красиво».
Но если проект серьёзный, расчитан не на одну версию и не одну платформу (где нет такого щчастья типа Expression Blend), то без качественной проработки документации на начальном этапе не обойтись.
Я три года без ТЗ живу, никаких проблем нет. Проект серьезный, большой. Но ТЗ я за все время ни разу не увидел и не хочу видеть.
Прикол в том, что, в отличие от фотошопа, Expression Blend является частью IDE и не позволит соорудить такое, что потом невозможно будет закодировать. В этом большое преимущество таких средств прототипирования.
Ну а в целом, меня укрепляет мысль о том, что вокруг стали появляться инструменты разработки для дизайнеров. Как вы думаете, для чего они, как не для ранних прототипов? И если разработчики IDE включают рабочее место дизайнера в среду, значит, может быть расчитывают на какой-то тренд?
Ну а в целом, меня укрепляет мысль о том, что вокруг стали появляться инструменты разработки для дизайнеров. Как вы думаете, для чего они, как не для ранних прототипов? И если разработчики IDE включают рабочее место дизайнера в среду, значит, может быть расчитывают на какой-то тренд?
Прототип и есть ТЗ. Это звучит странно, но я выше приводил пример со списком пользователей. Что увидит программер, когда получит прототип? Он получит 90% информации о том, какие данные необходимы интерфейсу, какие запросы будут сделаны в базу, какие методы будут у объекта, что не потребуется. Зачем ему читать ТЗ, если он может просто по прототипу работать?
Это звучит странно, непривычно, но это работает! Чертовски хорошо работает!
Это звучит странно, непривычно, но это работает! Чертовски хорошо работает!
Я говорю про то, что чем более точно будет проработана документация (и особенно — сценарии использования продукта), тем проще будет работать и самому дизайнеру, и всем остальным членам команды.
Ваше мышление кардинально отличается от нашего. Вы сначала пытаетесь написать бумажку, а потом по ней что-то делать. А мы сначала пытаемся понять, что нужно пользователям продукта, как пользователь будет общаться с продуктом, как лучше построить его процесс взаимодействия с интерфейсом, а потом уже понимаем, какой объем данных ему нужно, и какие функции стоит реализовывать, а какие выкидывать на мусорку.
Замещать подготовку документации прототипирование можно, просто это не укладывается в ваши принципы разработки. Мне, к примеру, документация не нужна, чтобы начать работу над проектом. Мне нужно всего лишь понимание того, какую задачу/проблему будет решать разрабатываемый продукт. А это всего лишь пара предложений текста.
«Ваше мышление кардинально отличается от нашего.» — в этом вы совершенно правы! Я привык мыслить критериями команды, ведущей несколько проектов одновременно, в которой задействован не один десяток человек, и проблемы текучести кадров (в т.ч. — по беременности) имеют место быть.
Поэтому время, которое сэкономил идеолог продукта на написании бумажек, через пару месяцев оборачивается жутчайшим гиморроем для всей комманды: «что же тут имелось ввиду, под этими двумя сточками в ТЗ?!?»
Поэтому время, которое сэкономил идеолог продукта на написании бумажек, через пару месяцев оборачивается жутчайшим гиморроем для всей комманды: «что же тут имелось ввиду, под этими двумя сточками в ТЗ?!?»
Вы знаете, я тоже мыслю аналогичными критериями. И на бумажки под названием ТЗ мы почти совсем не обращаем внимание. Потому что они мешают, а не помогают. В классической водопадной схеме разработки вы действительно будете постоянно наступать на одни и те же грабли. Прототипистам ваши проблемы не понятны.
«Прототипировать надо только то, что нужно проверить»
Не только, но и то, что нужно показать (утвердить).
Просмотрите статью Скотта Беркуна goo.gl/2o8eI
Он называет три причины для прототипирования:
1. Проверка идеи
2. Изучение дизайна
3. Изучение технологии
Но явно это не полный перечень. У Ивана Бурмистрова я находил более полный список целей и преимуществ прототипирования:
1. экономят затраты: позволяют выявить проблемы и найти их решения на ранней стадии проекта (Я. Нильсен: «На поздних стадиях проекта испытания улучшают интерфейс примерно на 100%, в то время как на ранней стадии можно достичь 1000% и даже больше»)
2. конкретны: позволяют перейти от абстрактных рассуждений к общему для команды разработчиков пониманию проблем и вариантов их решения
3. стимулируют поиск альтернатив и выполнение итераций: приводят к принятию наилучших дизайн-решений
4. способствуют активному, раннему и глубокому вовлечению пользователей в разработку продукта
5. являются важным (хотя и не завершающим) этапом в процессе формулирования требований к продукту
Подробнее: sigchi.ru/Seminars/02/Burmistrov-Prototyping-VB.ppt (Внимание! PPT)
«При раннем прототипировании, когда сценарии использования еще не проработаны...»
Нельзя начинать прототипировать экраны, если не определены сценарии. Это бессмысленно, и даже вредно. Будет большой соблазн подогнать сценарии под представление, которое уже сформировалось на базе прорисованных экранов.
Не только, но и то, что нужно показать (утвердить).
Просмотрите статью Скотта Беркуна goo.gl/2o8eI
Он называет три причины для прототипирования:
1. Проверка идеи
2. Изучение дизайна
3. Изучение технологии
Но явно это не полный перечень. У Ивана Бурмистрова я находил более полный список целей и преимуществ прототипирования:
1. экономят затраты: позволяют выявить проблемы и найти их решения на ранней стадии проекта (Я. Нильсен: «На поздних стадиях проекта испытания улучшают интерфейс примерно на 100%, в то время как на ранней стадии можно достичь 1000% и даже больше»)
2. конкретны: позволяют перейти от абстрактных рассуждений к общему для команды разработчиков пониманию проблем и вариантов их решения
3. стимулируют поиск альтернатив и выполнение итераций: приводят к принятию наилучших дизайн-решений
4. способствуют активному, раннему и глубокому вовлечению пользователей в разработку продукта
5. являются важным (хотя и не завершающим) этапом в процессе формулирования требований к продукту
Подробнее: sigchi.ru/Seminars/02/Burmistrov-Prototyping-VB.ppt (Внимание! PPT)
«При раннем прототипировании, когда сценарии использования еще не проработаны...»
Нельзя начинать прототипировать экраны, если не определены сценарии. Это бессмысленно, и даже вредно. Будет большой соблазн подогнать сценарии под представление, которое уже сформировалось на базе прорисованных экранов.
— 2. Изучение дизайна
3. Изучение технологии
— Это все не имеет прямого отношения к конкретному проекту. Это все НИОКР. Хочется заказчику оплачивать ваше обучение и разработки — ради бога. Большинство за подобные вольности порвет на британский флаг: «Я вам деньги не за это плачу!!!» Не зря перед проектом HR получает четкие требования к персоналу — по каким требованиям какие скилзы должны наличествовать.
А привлекать пользователей на ранней стадии — себе дороже. Гораздо важнее с ними тщательно проработать сценарии. А показывать — только альфу…
3. Изучение технологии
— Это все не имеет прямого отношения к конкретному проекту. Это все НИОКР. Хочется заказчику оплачивать ваше обучение и разработки — ради бога. Большинство за подобные вольности порвет на британский флаг: «Я вам деньги не за это плачу!!!» Не зря перед проектом HR получает четкие требования к персоналу — по каким требованиям какие скилзы должны наличествовать.
А привлекать пользователей на ранней стадии — себе дороже. Гораздо важнее с ними тщательно проработать сценарии. А показывать — только альфу…
Прочитал я статью Скотта Беркуна, спасибо за ссылочку. Интересно, но есть о чем поспорить. Думаю, надо разделять общую идеологию и конкретные случаи, когда наиболее оптимальное для данного конкретного случая решение может отличаться от идеального очень сильно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Раннее прототипирование мобильных приложений