Является ли Wireframing Чрезмерным планированием?

Question

37 Сигналов Становление Реальным убедил меня в том, что создание каркаса и написание документов функциональных спецификаций - это промежуточные шаги, ненужные для создания веб-приложений и динамических веб-сайтов.

Оправдывают ли накладные расходы на эти шаги свой вес?Является ли создание прототипов в документах HTML / CSS или даже PhotoShop (чтобы дизайнеры могли работать с ними напрямую) лучшим вариантом, чем использование таких программ, как Visio?Лично я склоняюсь к последнему, но не уверен.

Answer 1

"Невыполнение плана - это план на провал" - или что-то в этом роде.

Создание каркаса не ограничивается веб-приложениями;он широко используется везде, где требуется высокоуровневый обзор какой-либо системы (просто он называется как-то по-другому).

Функциональные спецификации, когда вы знаете, что нужно сделать и как это сделать, действительно были бы излишеством.Достаточно было бы высокоуровневой диаграммы ваших намерений.И это никогда не будет ненужным.В первую очередь это помогает вам сосредоточиться на масштабах и намерениях / цели того, что вы хотите сделать.

Основное внимание должно быть сосредоточено на предотвращении напрасной траты усилий - обнаружить на полпути, что отсутствует что-то существенное, влияющее на все остальные объекты, - это не то, что вы хотите обнаружить.Каркас в этом случае помог бы выявить большинство основных функциональных потребностей.Вам нужно будет уточнить функциональные спецификации только там, где это абсолютно необходимо.Использование Photoshop для вашего дизайна также будет "напрасной тратой сил" - гораздо лучше использовать эволюционное прототипирование (RAD technique) с использованием CSS / HTML - но все равно делайте макет ваших намерений с помощью ручки и бумаги.

Answer 2

37Signals выступает за то, чтобы отказаться даже от Photoshop и перейти сразу к HTML.Видишь http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop.Я согласен с их оценкой предварительного планирования.Я не думаю, что это стоит того, чтобы тратить время в долгосрочной перспективе, когда вы могли бы тратить время на создание рабочего прототипа в HTML / CSS / JS.

Answer 3

В реальной жизни вы хотите избежать поиска "идеального" способа ведения дел.Вместо этого используйте то, что вы понимаете, для четкой и конкретной цели.

Макеты могут сэкономить вам МАССУ времени и усилий.Поскольку они могут быть просто дополнительным временем, которое вы потратили на их создание и обслуживание.

Пример из реальной жизни №1: Положение спасли макеты.Большая система для правительства, дедлайн просто смехотворен.

Причина:Месяцы ушли на подготовку всевозможных архитектурных документов, которые на самом деле совершенно не нужны, потому что архитектура HW и SW зафиксирована в камне до мельчайших деталей и фактически уже существует.

Решение:20 безумных дней создания макетов вместе с заказчиком, пока мы просто не передали экраны с нашими заметками разработчикам.Разработчикам действительно пришлось обратиться за некоторыми разъяснениями, но благодаря фиксированной архитектуре и четким и визуализированным требованиям они смогли в кратчайшие сроки реализовать множество необходимых функций.

Пример из реальной жизни №2: Макеты испортили весь день.Крупная правительственная система, которая "признала" необходимость макетов.

Этот фильм демонстрирует человеческую (или корпоративную?) способность превращать лучшее в мире в кошмар.

Крупное правительственное агентство попросило крупную компанию-консультанта возглавить крупную ИТ-компанию для решения проблемы.Правительственное агентство также создало большую специальную группу правительственных экспертов в данной области, чтобы помочь и ускорить этот процесс.

Месяцы прошли в громких словах и принятии решения о соответствующих методологиях для использования и надлежащих способах их использования.Конечно, были сделаны всевозможные компромиссы, чтобы не задеть чьи-либо чувства или значимость.

Результат:Архитектура Sw должна была стать источником всего, включая макеты.Которые должны были быть спроектированы в первую очередь и нарисованы во вторую.Было составлено отображение действий из OOAD и диаграмм последовательности, UX-диаграмм, затем были распознаны логические объекты пользовательского интерфейса и пакеты контента, нарисованы фактические экраны и включены в официальные варианты использования, UC были представлены пользователям на официальных семинарах раз в месяц, эти семинары удваивались как собрания по принятию требований, поскольку кто-то понял, что время уходит.

На этих семинарах даже принудительно нельзя было заставить клиентов отказаться от destand (строго формализованный, с большим количеством таблиц, описывающих атрибуты данных и тому подобное) UC, каждая длиной примерно в 30 страниц.Когда клиенты получали какие-то отзывы, это касалось макетов.Но обратная связь не поощрялась, потому что любое изменение в макете приводило к изменению диаграмм последовательности, диаграмм компонентов, операционной модели, диаграмм UX, проверке матриц отслеживаемости, обновлению текстов UC и т.д. И т.п.И только для того, чтобы получить больше отзывов.("Черт бы побрал клиентов, они никогда не бывают довольны". это был девиз).После выхода версии v1.0 с ограниченной функциональностью никто больше не заботился о документации, ее было так много.Разработчики боролись за свои жизни, ежедневно внося множество мелких изменений, просто чтобы запустить систему (после вчерашней серии изменений что-то еще сломалось).

Это НЕ тот способ использования макетов.Проект длился почти на 2 года дольше, чем планировалось.

Другими словами, не ищите идеальную методологию.Или любая методология, которую вы не понимаете.Какова ваша цель на данный момент?Какой самый быстрый способ, который вы знаете (другие способы не в счет), достичь этой цели?Дерзай.

Answer 4

Вероятно, это зависит от того, с кем вы работаете.Если это вы и дизайнер, то с функциональной спецификацией может возникнуть слишком много проблем.Но в моей работе руководители хотят точно знать, что они получат в конце проекта, и поэтому нам было очень трудно внедрять итеративную разработку.Обычно итерации определяются с помощью каркасов, функциональных спецификаций и макетов ..:)

Answer 5

Основная цель создания проволочных каркасов - уточнить требования.Всегда желательно четко документировать требования, и нет лучшего способа, чем визуализировать их.Каркасы здесь очень помогают, они дают владельцу продукта (клиенту) четкое представление о том, чего ожидать от конечного продукта.После одобрения владельцем продукта это также дает команде разработчиков более четкое представление о том, что нужно разрабатывать.В некотором смысле это экономит много времени на разработку и позволяет избежать конфликтов.На мой взгляд, проволочные каркасы всегда полезны для бесперебойного выполнения проекта, даже если проект небольшой.

Answer 6

Я считаю, что это зависит от того, насколько хорошо вы понимаете, что пытаетесь сделать.Если вы работаете на клиента, и он мало что сказал о требованиях, вам может понадобиться подход с чрезвычайно быстрыми итерациями.Если у вас уже есть хорошее понимание и вы можете создать что-то более существенное, не беспокоясь о том, что выбросите это из-за того, что выбрали неправильное направление, тогда можно потратить больше времени.В любом случае, кликабельный прототип может иметь большое значение для определения того, каким в конечном итоге должен быть реальный сайт.Если вы сможете получить согласие по прототипу, то, когда ваша заявка будет соответствовать прототипу, вы будете знать, что она завершена.