что такое прототип в технике
Правильно «готовим» прототип. Технологии прототипирования корпуса
Как выбрать правильную технологию для прототипа корпуса любого устройства, какие головные боли возникают у разработчиков, когда виртуальная 3D-модель становится физической, и как их лечить? Смотрите инструкцию. Главное здесь — понять, что конкретная технология прототипирования предназначена для решения конкретной задачи.
«Прототип — это работающая модель, опытный образец устройства, механизма или детали». Так пишет Википедия об этом термине.
Для чего нужен прототип? Для проверки свойств устройства, механизма или детали. Свойств для проверки может быть несколько.
Иными словами, опытный образец нужен в тот момент, когда виртуальная модель переходит в физический мир. При этом переходе обязательно всплывают проблемы, которые нельзя выявить в среде разработки. Их нужно выловить до того, как начнётся процесс подготовки корпуса или изделия к серийному производству.
Технологий прототипирования много. Берём самые распространённые для изготовления пластиковых корпусов (как наиболее популярных). Кстати, чем дальше к концу списка, тем ближе эта технология находится к серийному производству.
Технологии прототипирования: каждому своё
1. Макеты, сделанные вручную — из пластилина, пенопласта, глины и других легкообрабатываемых материалов. Такие макеты позволят условно оценить внешний вид изделия, не более. Ну, может, ещё и эргономику проверить. Срок производства — дни (один, два и т.д.), стоимость — несущественная.
2. Печать пластиковой нитью (FDM) — послойное нанесение расплавленного пластика на площадку. Пока такие детали нужно серьёзно дорабатывать перед использованием (плюс покраска и финишная обработка). Подобные прототипы, как и макеты, тоже не решают сложных проблем, но позволяют оценить дизайн и эргономику. Часто с их помощью можно понять реальный вес изделия, какие-то свойства по жёсткости. Срок производства — часы (если не считать ручной обработки). Стоимость — копейки.
3. Лазерное спекание, печать фотополимером (SLA, SLS). Прототип корпуса, сделанный по таким технологиям, уже более-менее полноценен: позволяет проверить не только дизайн и эргономику, но ещё организовать первичную проработку собираемости изделия, а также в какой-то степени оценить жёсткость.
Плюсом технологии является возможность печатать многотельные прототипы, т.е. сразу всё изделие. Детали требуют уже минимальной шлифовки, годятся для окрашивания и издалека неотличимы от реальных. Можно сделать их даже прозрачными.
А проблема таких прототипов кроется в хрупкости и жёсткости — сломать напечатанный корпус легко, а проверить, например, хорошо ли нажимается кнопка, может не получиться. Короче, реальной картины деталь, сделанная по технологиям SLA или SLS, не даст.
Срок изготовления — несколько часов, ценник — несколько тысяч рублей.
4. Фрезеровка пластика и металла. Такие технологии позволят близко подойти к свойствам серийного изделия. По сути, с этой технологии начинается «проверка жизнью» дизайна или корпуса устройства. Ведь материал прототипа обладает теми же свойствами, что и серийного корпуса — жёсткость, кручение, пружинистость и т.д. И таким прототипом можно закрыть все вопросы по собираемости, дизайну, весу, разрушению, поведению в реальных «уличных» условиях.
Хуже обстоят дела с проверкой герметичности — ведь резиновую прокладку фрезеровкой уже не сделать. С прозрачностью тоже непросто.
Срок изготовления — несколько дней, оборудование для многоосной фрезеровки нельзя назвать распространённым, то есть подрядчика надо ещё поискать (но если нужно, пишите, дадим контакты). Ценник — десятки тысяч рублей.
На фотографии — фрезерованный корпус в сравнении с корпусом, сделанным методом FDM
5. Литьё полиуретана в силиконовые формы — отличная технология, которая отвечает на почти все вопросы по физическим свойствам корпуса: резина, прозрачные детали, точное соответствие пластику по жёсткости, пружинности, цвету, фактуре. Литьё в силикон позволяет проверить даже такие свойства будущего устройства, как его «поведение» на морозе или жаре.
Эта технология хотя и простая, но дорогая. Подрядчиков немного. Ещё меньше тех, кто делает аккуратно и красиво. Срок — несколько дней, стоимость — десятки тысяч рублей.
6. Литьё пластика под давлением в легкообрабатываемые формы. По сути, это уже тиражное производство, максимально близкое к серии. Но его стоимость иногда в 2-3 раза дешевле производства с изготовлением полноценной оснастки, да и по срокам всё быстрее.
Оснастка под такое литьё изготавливается из мягких металлов с помощью фрезеровки и ручной доводки. А вот материал (расплавленный пластик) подаётся под давлением, как при нормальном производстве. Можно получить прототип, идентичный серийному изделию по всем свойствам, и изготавливать малые (тысячи штук) серии корпусов или деталей. Стоимость — сотни тысяч рублей, срок — несколько недель. 
Выбираем правильную технологию
Итак, нужно ответить себе на вопрос: «Для чего мне нужен прототип?» и выбрать технологию в зависимости от ответа. Например:
— Прототип нужен, чтобы проверить только дизайн → Выбираем трёхмерную печать (3D).
— Важна проверка «собираемости» корпуса прибора с реальными компонентами (например, платой) → Лучше использовать 3D-печать или фрезеровку пластика.
— Изделие тестируем в реальных условиях с реальным железом. Или вы хотите показать устройство клиенту, инвестору или отвезти на выставку → Выбираем фрезеровку или литьё полиуретана.
— Если задача ещё сложнее (например, важно, как, сколько раз нажимается и когда сломается кнопка) → Только полиуретан или литьё пластика под давлением.
ВНИМАНИЕ! Все технологии требуют разной степени проработки исходной модели и конструкции. И, если первые три из перечисленных выше достаточно терпимы к ошибкам при проектировании, то начиная с фрезеровки при подготовке документации вам потребуется опыт конструктора, а при выборе последней технологии в списке (6) — конструктора с опытом подготовки литьевых изделий.
Если есть вопросы, присылайте информацию по вашему изделию (проекту), посоветуем технологию производства и/или подрядчика (разумеется, уже много раз проверенного).
Значение слова «прототип»
Источник (печатная версия): Словарь русского языка: В 4-х т. / РАН, Ин-т лингвистич. исследований; Под ред. А. П. Евгеньевой. — 4-е изд., стер. — М.: Рус. яз.; Полиграфресурсы, 1999; (электронная версия): Фундаментальная электронная библиотека
Прототип (когнитивная психология) — абстрактный образ, воплощающий множество сходных форм одного и того же объекта или паттерна, наиболее репрезентативный пример понятия, фиксирующий его типичные свойства.
Прототип персонажа — конкретная историческая или современная личность, послужившая основой для образа в литературе, искусстве, кинематографе.
Прототип — быстрая, черновая реализация будущей системы. См.: прототипирование.
Прототип (инженерия) — работающая модель, опытный образец устройства или детали в дизайне, конструировании, моделировании. См. также: Быстрое прототипирование.
Спортпрототип — автомобиль, построенный специально для гонок, а не на основе дорожного автомобиля.
Прототип (шаблон проектирования) — порождающий шаблон проектирования.
Прототип функции — описание интерфейса функции в языках программирования: объявление функции, которое не содержит её тела, но указывает имя, арность, типы аргументов и тип возвращаемых данных.
Прототипное программирование — стиль объектно-ориентированного программирования, в котором нет понятия класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.
Prototype (игра) — видеоигра, научно-фантастический экшн от третьего лица, разработан компанией Radical Entertainment. Выпущена в июне 2009 года.
Prototype (фреймворк) — JavaScript-фреймворк.
ПРОТОТИ’П, а, м. (лит.). Первообраз, оригинал, первоначальный образец; действительное лицо, послужившее автору для создания литературного типа, а также литературный тип, образ, послуживший образцом для другого автора. См. [прото]. Думают, что прототипом пушкинского Ленского был Кюхельбекер. Онегин — п. Печорина. Прототипом Лопухина, героя «Что делать», считают известного физиолога Сеченова.
Источник: «Толковый словарь русского языка» под редакцией Д. Н. Ушакова (1935-1940); (электронная версия): Фундаментальная электронная библиотека
прототи́п
1. лицо, послужившее прообразом персонажа в художественном произведении ◆ Прототипом Ключика в книге Катаева был Юрий Олеша.
2. техн. ранняя версия нового продукта, используемая разработчиками для исследовательских и демонстрационных целей ◆ На конференции в Сан-Франциско компания Apple продемонстрировала прототип телевизионной приставки iTV.
4. комп. в объектно-ориентированном программировании — родительский класс, от которого класс потомок наследует свойства и методы
5. спорт. автомоб. то же, что спортпрототип; гоночный автомобиль с кузовом (не одноместный болид), сделанный с нуля, не берущий за основу серийный автомобиль
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я стал чуточку лучше понимать мир эмоций.
Вопрос: ввалить — это что-то нейтральное, положительное или отрицательное?
Прототипы: как создать успешный продукт и сэкономить
Полгода назад в статье о том, как мелкие юзабилити-ошибки создают бизнесу большие проблемы, я упоминал неудачный запуск Делисамоката, сырое приложение которого, вызвало большую волну негатива.
Недавно, прогуливаясь по Москве, вспомнил о стартапе и решил проверить его лично. Но уже через 15 минут понял, что шансов взять самокат в аренду нет, а рейтинг 1.5 в AppStore полностью оправдан и подтверждает, что сложности не только у меня.
На запуск стартапа такого масштаба, вероятно, было потрачено довольно много денег. И рейтинг 1.5 как бы намекает, что тратить придется еще.
Могли ли разработчики Делисамоката избежать такой ситуации и выпустить более удобное приложение сразу? Да, если бы сначала сделали прототип и протестировали его на реальных пользователях.
Из статьи вы узнаете:
Что же такого важного в этих ваших прототипах?
Концепция прототипов в обычном мире довольно стара. Строительству любого здания предшествует проект (проект = прототип), выпуску серийного автомобиля — концепт (концепт-кар = прототип). Несмотря на это, в цифровом мире долгое время даже высокобюджетные проекты фактически разрабатывались методом тыка, а продукты для среднего и малого бизнеса вообще по наитию подрядчиков.
Прототип в цифровом мире – это визуализация будущего продукта, достаточная для проверки гипотез среди пользователей этого продукта, и/или для донесения идей до людей, принимающих решение о его создании. Прототип позволяет быстро и, главное, дешево получить обратную связь: решает ли разработанный вами интерфейс бизнес-задачи, удобен и понятен ли ваш инновационный способ взаимодействия пользователям, правильно ли вообще понята проблематика и задачи. В противном случае решать все это придется уже после запуска продукта, а это не только потраченное время, но и деньги.
Прототип-прототипу — рознь
Прототипы, как средство быстрой визуализации идей, в последние годы получили большое распространение и оказали позитивное влияние на качество цифровых продуктов в целом.
Вместе с тем, взяв на вооружение инструменты прототипирования, рынок все еще не до конца усвоил, что прототип – часть юзабилити-процесса, а не проджект-менеджмента.
За последние несколько лет я общался со многими дизайнерами, у которых в портфолио есть пара десятков прототипов, при этом часто они не только не понимают до конца процесс создания прототипов, но и не всегда уверенно могут объяснить зачем они вообще нужны.
В итоге, все чаще можно встретить прототип, в котором нет и намека на реальный контент, а графическая форма преобладает над содержанием. В быстрорастущем сегменте UI/UX-дизайна доходит до того, что прототипом начинают называть полноценные дизайн-макеты, на создание которых были затрачены десятки человеко-часов.
Влияет на ситуацию и развитие рынка инструментов прототипирования, где все больший акцент получает работа с визуальной частью. Все это подталкивает к соблазну уделить особое внимание композиции и красоте прототипа, забывая о главном — структуре и контенте.
Формирование эффективной структуры и подготовка контента – наиболее длительный и трудозатратный процесс, при этом, как показывает практика, максимально влияющий на конечный продукт.
Прототип – результат комплекса работ
Рассмотрим шаги, выполнение которых позволит создать действительно эффективные интерфейсные решения, основанные на потребностях пользователей и решающие конкретные бизнес-задачи:
Исследования
Исследования – важнейший этап, фундамент успеха всей последующей работы. Несмотря на это, на рынке до сих пор приняты два способа «исследований»: «пришлите нам ТЗ» и «заполните бриф на 150 вопросов».
Ни техническое задание, ни бриф не способны обеспечить необходимый уровень погружения для создания действительно эффективных решений: техническое задание ни что иное, как субъективное восприятие действительности клиентом, которое во многом заимствует существующие решения конкурентов, а любимые многими брифы – не только ставят разные бизнесы в один ряд, но и заставляют клиента потратить значительное время, отвечая на шаблонные вопросы, реальный смысл которых он, зачастую, не понимает до конца.
Поэтому в вопросе исследования бизнеса самым эффективным является путь личного общения с клиентом. Это позволяет максимально погрузится в процессы и особенности каждого конкретного бизнеса, выявить едва заметные нюансы, которые в итоге могут и часто становятся основой всего последующего продукта.
Многие UI/UX-дизайнеры не считают необходимым общаться с пользователями, тем не менее, исследование пользователей позволяет взглянуть на задачу с другой стороны, выявить причинно-следственные связи, понять мотивацию, обнаружить страхи, услышать сомнения, найти инсайты.
Разработка дизайн-решения
На этом этапе результаты исследований интерпретируются в конкретные требования к продукту: какой должна быть навигация, какие нужны экраны, какие потребности они должны закрывать и многое другое.
Для трансформации исследований в требования к продукту существует множество инструментов: User-Centered-Design, Value Proposition Canvas, Jobs-To-Be-Done и другие, но все они приводят к одному результату – осознанному проектированию интерфейса.
Результатом разработки дизайн-решения становятся бумажные наброски – скетчи, которые в дальнейшем превращаются в прототипы высокой детализации.
Контент
Прежде, чем перейти от скетчей к прототипам высокой детализации, нужно подготовить весь контент. Соблазн использовать текстовую рыбу чреват последствиями: такой прототип невозможно реально оценить, к тому же, когда реальный контент все-таки появится, окажется, что он не ложится в уже разработанный продукт. И тогда контент придется подгонять под заданные рамки.
Поэтому сначала ЧТО (контент), а потом КАК (дизайн).
Прототип
Пройдя весь путь от исследований и выработки дизайн-решений до написания контента, команда находится в максимальном вовлечении и способна выдать действительно свежие интерфейсные решения, учитывающие потребности целевой аудитории и поставленные бизнес-задачи. Такие прототипы легко тестировать на пользователях и/или использовать для донесения идеи людям, принимающим решение о создании продукта.
Как отличить хороший прототип от плохого
Вот простой чек-лист, который без каких-то знаний в области проектирования взаимодействия позволит определить, подсовывают ли вам под видом прототипа «заливную рыбу» или результат реальной работы.
Итак, всего несколько пунктов:
Заключительная история
Но все решилось уже в процессе исследований, когда выяснились, что пользователям не нужен такой продукт и эффективней использовать более простое, и, главное, уже существующее решение.
Эта история хороша тем, что отлично иллюстрирует, с одной стороны, важность создания прототипа перед разработкой реального продукта, с другой — важность процессов, необходимых перед слепым проектированием интерфейса.
Если вам показалось, что все слишком сложно и долго, вот доказательство обратного: UX-challenge: проектирование приложения мобильного банка за 5 дней
Практика прототипирования в софтверной компании
Нет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.
Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ.
Однако сделать процесс прототипирования полезным и эффективным — непростая задача. Встречаются подводные камни, появляются вопросы. Кто и когда должен прототипировать? Как делать прототипы? Как их использовать? Ответы на эти вопросы и последующие шаги определяют успешность и полезность нововведения. Если они будут неверными – прототипирование может стать не только вредным, но и крайне дорогостоящим процессом.
В статье я хочу поделиться опытом построения процесса прототипирования в моей компании. Расскажу, как мы ответили на озвученные вопросы и каких успехов достигли.
Когда и как использовать прототипы? Теории и практики
Для определения места прототипирования в процессе разработки ПО, в первую очередь мы обратились к международным стандартам в этой области и собрали следующую информацию.
Первое упоминание прототипирования в своде знаний встречается в главе Программные требования в секции Извлечение требований в теме Техники извлечения требований как один из подходов к извлечению требований. Говорится, что прототипы – это отличный инструмент для уточнения и/или детализации требований.
Далее в секции Утверждения требований прототипированию вообще посвящена отдельная тема, как средству проверки и утверждения требований. В ней говорится, что прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований.
Таким образом формулируется первая цель прототипирования – решение проблемы недопонимания между аналитиком и пользователем. Упущение тех или иных аспектов, неоднозначность или тем более некорректность интерпретации информации, полученной от пользователей – все это наиболее типичные причины “сверхзатрат” (времени, денег и т.п.), а иногда и полного провала проектов. Первая задача прототипирования – не допустить этого.
Далее свод знаний предполагает использование прототипирования и на этапе проектирования – как технику проверки программного дизайна в целом или отдельных его атрибутов качества.
В публикациях «по теме» я впервые встретил мысли об использовании прототипов за рамками этапов сбора требований и проектирования.
В своих публикациях Влад Головач предлагает использовать прототипирование в первую очередь для написания и улучшения качества ТЗ или даже для его частичной замены. По его словам, прототипы интерфейса являются тем единственным документом, который заказчик может понять и оценить. Да, это опять этап проектирования. Но, кроме этого, Влад предлагает использовать прототипы для проведения юзабилити-тестирования. А это уже этап тестирования.
В цикле статей Юрия Ветрова об интерактивных прототипах я встретил мысль об использовании прототипов на этапе реализации. Он предлагает разработчикам использовать прототип в качестве образца, поскольку он намного проще и правильнее понимается, нежели многостраничное ТЗ.
Промежуточные итоги. Выжимка из теории
Как ещё можно использовать прототип?
На этапе коммерческого предложения
Иногда мы делаем прототипы на этапе коммерческого предложения, т.е. ещё до запуска проекта и до сбора требований, основываясь только на базовой информации от потенциального заказчика. Как мы это делаем – я уже рассказывал.
Для чего мы это делаем? Тут всё просто: прототип позволяет нам выделиться из десятка похожих коммерческих предложений и расположить к себе заказчика.
Мы делаем это не всегда, т.к. всегда есть риск того, что исполнителями проекта выберут не нас, и, соответственно, работы по прототипированию оплачены не будут.
Как образец при тестировании готового ПО
Мы используем прототип в качестве образца не только при реализации системы, но и при её тестировании. У наших тестировщиков сейчас под рукой, помимо ТЗ, всегда есть прототип. Некоторые интерфейсные функции тяжело описываются и воспринимаются в текстовом виде, и в этом случае прототип является хорошим помощником.
Как образец при приёмке-сдаче работ
Здесь уже больше используем прототип не мы, а наши заказчики. При приёмке работ они теперь помимо, а иногда и вместо проверки функций по ТЗ, сравнивают реализованную систему с прототипом. Это выгодно обеим сторонам. Заказчик вправе предъявить претензии, если в реализованной системе что-то не так, как в прототипе. Но и мы как исполнитель можем защитить себя от претензий, если реализуем систему точно так же, как в прототипе. У заказчика просто не будет оснований быть недовольным. Таким образом, исполнитель отдаёт, а заказчик получает ровно то, что было согласовано – ни больше, ни меньше. Никто не делает лишней работы, и все довольны.
Как пример решения для демонстрации потенциальным заказчикам
Иногда у нас нет возможности продемонстрировать заказчику готовую систему и мы показываем ему прототипы, разработанные и использованные на прошлых проектах.
Жизненный цикл прототипа
Теперь, когда перечислены, наверное, все возможные способы использования прототипов, покажу полный цикл использования прототипов у нас.
Последствия прототипирования
После внедрения прототипирования у нас изменился процесс разработки ПО в целом. Как видно из жизненного цикла, прототип пронизывает весь процесс разработки. Прототип стал элементом, который все видят и который все обсуждают: от пользователя до программиста. Он стал своего рода объединяющим, центральным звеном. Он вывел коммуникацию как с заказчиком, так и внутри компании на новый уровень. Значительно уменьшилась потеря информации по пути от заказчика к программисту, потому что все видят один и тот же прототип.
Если раньше процесс передачи информации выглядел примерно так:
то сейчас он представляет собой что-то вроде этого:
Картинки позаимствовал из презентации Геннадия Драгуна, за что ему премного благодарен.
Прототипы бывают разные.
Существует множество мнений о том, что нужно/можно считать прототипом и какими характеристиками он должен обладать. Чтобы не выставлять своё субъективное видение за истину, я опять обращусь к своду знаний SWEBOK. Он говорит, что прототипом могут считаться как “бумажные” модели, так и пилотные подсистемы, реализуемые как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов.
Одноразовые прототипы являются макетом интерфейса, который в последствии не станет частью готовой системы и на определённом этапе будет «выброшен». Такие прототипы создаются и изменяются быстро, поскольку не требуют качественной реализации. Зачастую они создаются в специализированных инструментах без программирования.
Эволюционный прототип – это предварительная реализация программы, альфа-версия, которая по мере своего развития становится всё ближе и ближе к готовому продукту и, в конце концов, становится им. Эволюционные прототипы менее гибкие, их создание и изменение более длительное и дорогое. Поскольку на начальном этапе не все требования известны и утверждены, прототип в ходе своего развития может обрасти «заплатками». При таком подходе есть большой риск получить на выходе продукт неудовлетворительного качества. Преимуществом эволюционных прототипов считается то, что, во-первых, уже на ранних стадиях заказчик получает работающую систему, во-вторых, не нужно тратить ресурсы на создание прототипа, который потом будет «выброшен».
У каждого из подходов есть свои преимущества и недостатки. Каждый сам для себя решает, какие прототипы ему создавать в зависимости от решаемой задачи, от особенности процесса разработки ПО в компании, от квалификации сотрудников. Мы для себя решили использовать одноразовое прототипирование, как наиболее гибкий, эффективный и менее рискованный инструмент. На нём я и акцентирую внимание.
Какие прототипы мы используем?
Одноразовые прототипы делятся в свою очередь по:
Большинство из нас делает «бумажные» прототипы в самом начала этапа сбора требований. Затем по мере уточнения требований увеличивается точность прототипов. Кто-то останавливается на вайрфрейме (каркас интерфейса без конечного дизайна), кто-то доводит до мокапов с дизайном, близким к конечному. Но наибольший интерес представляют интерактивные прототипы. Именно они позволят полноценно вовлечь пользователя, показать систему целиком и в действии. Для нас интерактивные прототипы являются наиболее эффективными, поэтому именно их мы и используем в нашей деятельности.
Прототипирование на постсоветском пространстве
Теперь краткая информация о распространении и тенденциях прототипирования в России и странах СНГ. Как показывает опрос, проведённый Павлом Коноплицким на Хабре, в половине компаний процесс прототипирования вообще отсутствует.
Однако радует осознание того, что ситуация с прототипированием в компании неудовлетворительна. Это видно по результатам другого опроса: более 70% опрошенных не удовлетворены текущей ситуацией и почти половина из них находится на данный момент в поиске хорошей методики и инструмента. Хорошая тенденция.
Кто должен прототипировать?
Вернёмся к первому опросу. Если смотреть на исполнителей, прототипированием в большинстве проектов занимаются технические специалисты. Для меня это стало неожиданностью: как я уже сказал, большинство стандартов и публикаций рассматривают прототипирование в первую очередь как инструмент для извлечения и утверждения требований. А кто занимается сбором требований? Менеджер или аналитик, но никак не технический специалист. Если это будет делать он – у нас опять появятся большие потери информации, менеджер будет играть роль сломанного телефона. Поэтому мы считаем, что прототипировать должен именно менеджер, как центральное звено команды проекта и как лицо, непосредственно контактирующее с заказчиком. В нашей компании должность менеджера и аналитика объединена, что является ещё одним фактором в пользу прототипирования менеджерами.
Как мы делаем прототипы?
Мы поставили перед собой два условия: во-первых, прототипы должны быть интерактивными, во-вторых, прототипировать должны менеджеры. Нам нужен был инструмент, который позволяет создавать интерактивные прототипы без программирования, т.к. менеджеры в общем случае не умеют программировать. Пробовали Visio – но интерактивность созданных в нём прототипов была невысокой. Пробовали GUI Design Studio. Но и он не прижился.
В итоге мы пришли к собственной разработке и сделали её такой, какой хотим видеть инструмент прототипирования. Если не хватало каких-либо функций – добавляли. В итоге разработка доросла до качественного продукта, и мы выпустили его на рынок. Назвали GUI Machine. Сейчас это кроссплатформенный инструмент прототипирования, который позволяет создавать интерактивные прототипы декстоп и веб-приложений без программирования.
Использование для создания прототипов собственного инструмента имеет как положительные, так и отрицательные стороны. Минусом для компании является необходимость выделения ресурсов на развитие GUI Machine. С выводом продукта на рынок количество необходимых ресурсов только увеличиваются: инструмент нужно продвигать, развивать, поддерживать. Преимущества своего продукта в том, что мы можем сделать инструмент таким, каким мы хотим его видеть. Кроме того, продукт начал приносить коммерческую прибыль.
Зри в корень. Ищи ответы
Прототипировать ли?
В качестве итогов – плюсы и минусы от внедрения процесса прототипирования.
Цифры
Это только сухие цифры, но, как я уже говорил, прототипирование даёт далеко не только уменьшение сроков.
Вывод
Для нас процесс прототипирования стал однозначно выгодным и полезным.
Если вы ещё не прототипируете – попробуйте, не пожалеете.