Comments 44
Спасибо за четкую концепцию! Ранее уже пользовался проектированием, но описать для себя было лень.
Пример бы готового документа по этому плану.
Спасибо за вопрос.
По соображениям NDA мы не можем выкладывать реальные проекты, но мы как раз готовим шаблон проекта для вымышленного шоу-рума женской одежды «XXX», упоминавшегося в предыдущей статье в шаблоне видения.
Это будет тем более полезно, что будет заметно реальное отличие видения, короткого пред-проекта для оценки задачи, от реального проекта — постановки задачи.
По соображениям NDA мы не можем выкладывать реальные проекты, но мы как раз готовим шаблон проекта для вымышленного шоу-рума женской одежды «XXX», упоминавшегося в предыдущей статье в шаблоне видения.
Это будет тем более полезно, что будет заметно реальное отличие видения, короткого пред-проекта для оценки задачи, от реального проекта — постановки задачи.
>Если вам эта статья показалась полезной, отпишите в комментариях, о каких этапах проектирования вы хотели бы узнать подробнее.
Создание концепции сайта подробнее не помешало бы. Как вы ее проводите? Какими инструментами или технологиями пользуюутесь? есть какой-либо шаблон или план создания ??? Ну в общем поподробнее с практической точки зрения хотелось бы рассмотреть, чтобы перенести на себя какие-то моменты
Создание концепции сайта подробнее не помешало бы. Как вы ее проводите? Какими инструментами или технологиями пользуюутесь? есть какой-либо шаблон или план создания ??? Ну в общем поподробнее с практической точки зрения хотелось бы рассмотреть, чтобы перенести на себя какие-то моменты
LIAL,
Принято. Напишу об этом отдельно.
Принято. Напишу об этом отдельно.
Все правильно, однако реалии таковы, что часто приходится демпинговать с конкурентами по срокам, и времени на все эти анализы не остается. К тому же, большинству клиентов нельзя заявить «мы ваших конкурентов будем неделю анализировать и писать отчет, а вы нам за это будете много платить» — клиент откажется от такой услуги, у него нет понимания зачем это, многие даже элементарно за ТЗ отказываются платить, заявляя «я у вас сайт покупаю, а ваше ТЗ не моя проблема» — приходится каждый раз воевать с ними.
Все это работает только с крупными заказчиками, которые понимают зачем им проектирование, которые готовы много платить и долго ждать, но таких мало.
И да, очень хорошо, если клиент хотябы к моменту завершения сроков по написанию ТЗ определится какие вообще разделы будут у него на сайте. Я к последнему клиенту уже 3 раза ездил, 4 раза переписывался и 3 раза напоминал по телефону. За это время мы родили только 70% основных разделов. А надо еще подразделы, т.к. некоторые из них будут на главной и дизайнеру нужно знать сколько их там будет. Невозможно что-то проектировать в таких условиях.
Все это работает только с крупными заказчиками, которые понимают зачем им проектирование, которые готовы много платить и долго ждать, но таких мало.
И да, очень хорошо, если клиент хотябы к моменту завершения сроков по написанию ТЗ определится какие вообще разделы будут у него на сайте. Я к последнему клиенту уже 3 раза ездил, 4 раза переписывался и 3 раза напоминал по телефону. За это время мы родили только 70% основных разделов. А надо еще подразделы, т.к. некоторые из них будут на главной и дизайнеру нужно знать сколько их там будет. Невозможно что-то проектировать в таких условиях.
Какой отличный комментарий. Давайте-ка по пунктам:
1. Проект и Техническое задание — это принципиально разные вещи. Клиент действительно, за некоторыми исключениями, может не знать про существование ТЗ как такового. Его дело — согласовать ключевые моменты, которые и формируются при проектировании, а остальное — сугубо ваша ответственность.
2. 99% наших клиентов, вне зависимости от размера, сферы деятельности, возраста, пола, национальной принадлежности, социального статуса и т.п. после непродолжительной, но весьма содержательной беседы, понимают, зачем нужно проектировать. Повторюсь, только в проектах с маленьким бюджетом и столь же маленькими задачами проектирование нерентабельно.
3. Уважаемый Alexx_ps, клиент НЕ должен определяться, какие разделы у него будут на сайте. Это должны определять вы и только вы в процессе проектирования. Вы должны родить 100% разделов и подразделов, детально их описать по предложенной нами или другой схеме, а клиент должен это утвердить.
1. Проект и Техническое задание — это принципиально разные вещи. Клиент действительно, за некоторыми исключениями, может не знать про существование ТЗ как такового. Его дело — согласовать ключевые моменты, которые и формируются при проектировании, а остальное — сугубо ваша ответственность.
2. 99% наших клиентов, вне зависимости от размера, сферы деятельности, возраста, пола, национальной принадлежности, социального статуса и т.п. после непродолжительной, но весьма содержательной беседы, понимают, зачем нужно проектировать. Повторюсь, только в проектах с маленьким бюджетом и столь же маленькими задачами проектирование нерентабельно.
3. Уважаемый Alexx_ps, клиент НЕ должен определяться, какие разделы у него будут на сайте. Это должны определять вы и только вы в процессе проектирования. Вы должны родить 100% разделов и подразделов, детально их описать по предложенной нами или другой схеме, а клиент должен это утвердить.
С третьим пунктом не согласен. Мы можем только частично предложить разделы, которые работают для любого бизнеса. По остальному — мы не знаем специфики бизнеса клиента, не знаем что важно, а что второстепенно при выборе покупателем «насосов взрывобезопасных» и заказе услуги по рытью колодцев.
Если вы не знаете специфики бизнеса-клиента, её надо узнать. Как можно делать сайт, не зная, как работает бизнес клиента?!
Ну и опять же 8 из 10 клиентов среднего размера не читают наш договор на 12 страниц и ТЗ на 32 страницы, а только пролистывают. Не знаю где вы берете клиентов, которые все понимают, читают и даже вносят правки.
Какая у вас минимальная цена на сайт?
У нас по городу средняя 60 000р. и начинается все с «ну мы же в 15 уложимся?» — заявляет крупная компания с офисами в 5 регионах.
Какая у вас минимальная цена на сайт?
У нас по городу средняя 60 000р. и начинается все с «ну мы же в 15 уложимся?» — заявляет крупная компания с офисами в 5 регионах.
я вот дизайнер, работаю в фирме небольшой и мне дали один проект, заказчик там дурной на всю голову, ну не знает он, что ему нужно, я уже третий макет сделал, а ему все не нравится, у него такая политика, что я должен предоставлять разные макеты пока ему не понравится, и главное мое начальство молчит по этому поводу. Что вот тут делать с такими паршивыми заказчиками?
Аркадий,
Вам нужно заниматься своим делом, а проектировать должен проектировщик до того, как вы приступите к работе. Если же вы и есть проектировщик, то не начинайте рисовать до создания проекта сайта.
Вам нужно заниматься своим делом, а проектировать должен проектировщик до того, как вы приступите к работе. Если же вы и есть проектировщик, то не начинайте рисовать до создания проекта сайта.
Заказчику нужен уже результат, а не какой то проект.
В вашем случае уже трудно что-то сделать, поскольку вы уже работаете над проектом и, видимо, долго. Естественно, сейчас заказчику проект уже не нужен.
Я к тому, что зачастую заказчики не хотят не заполнять никакие брифы, не втыкать в какие-то проекты, а хотят сразу сайт. Если даже им объяснять, для чего это нужно и т.д. они просто могут забить и уйти в другую студию, а клиента же терять не хочется, поэтому приходится прогибаться и т.д. Вот у вас же наверняка были такие случаи…
Надо объяснять и, лучше всего, если не понимают, не работать. Не надо прогибаться: сделаете плохой сайт, клиент останется недоволен, ничего не заработаете, потратите время и нервы.
У нас были такие случаи, но нам почти всегда удавалось объяснить клиенту, зачем нужно проектирование. В тех редких случаях, когда не удавалось, отказывались работать.
У нас были такие случаи, но нам почти всегда удавалось объяснить клиенту, зачем нужно проектирование. В тех редких случаях, когда не удавалось, отказывались работать.
А Ваша компания заключала договор? Лучше вписать в договор, что Исполнитель обязуется нарисовать N вариантов дизайна, а все остальное Заказчик оплачивает дополнительно. Это в идеале. А по сути такие вопросы должен решать менеджер проекта.
И заказчики сайта-визитки согласны за это платить? В какой стране вы работаете, в России? Серьезно, несколько дней седеть и проектировать сайт из пяти статичных страниц?
Мы работаем в России. И проектируем несколько дней, несколько недель или месяцев — столько, сколько нужно.
Насчёт сайтов-визиток: размер сайта не играет роли. Проектирование нерентабельно только в проектах с очень маленьким бюджетом — 10-20 тысяч рублей. Да и то, можно сократить проектирование хотя бы до уровня, который есть в видении, и результат уже будет лучше.
Насчёт сайтов-визиток: размер сайта не играет роли. Проектирование нерентабельно только в проектах с очень маленьким бюджетом — 10-20 тысяч рублей. Да и то, можно сократить проектирование хотя бы до уровня, который есть в видении, и результат уже будет лучше.
Значит вы очень крутые. У меня на работе этим не занимаются. Описывают задачу дизайнеру, программисту и делаем. Проговариваем сложные вопросы и всё. Правда, ничего не записывается, есть тз. Может это оно и есть?
Я просто серьезно не представляю как подойду к менеджеру и скажу «а давайте попроектируем этот сайт», он спросит «а что там проректировать? Три странички с текстом?», и мне нечего будет ответить.
Я просто серьезно не представляю как подойду к менеджеру и скажу «а давайте попроектируем этот сайт», он спросит «а что там проректировать? Три странички с текстом?», и мне нечего будет ответить.
Статья понравилась, хотя, на мой взгляд, слишком общо. Хотелось бы на конкретном примере получить информацию об общих принципах проектирования схемы раздела, особенно с точки зрения взаимодействия с пользователем и «защиты от дурака».
Пока в головах сайтостроителей есть мысль о том, что можно сделать сайт за 5-15 тысяч рублей, у нас не будет ни денег, ни хороших сайтов.
Мне выгоднее курьером работать, чем сайты клепать за такие деньги.
Мне выгоднее курьером работать, чем сайты клепать за такие деньги.
Ждём примеров. Мне было бы интересно подробнее ознакомиться с каждым этапом проектирования, т.к. опыта в этом нет.
А может это сделать в виде блога на конкретном примере? Т.е. берется задача — сделать сайт. Выбирается тематика, придумывается легенда, моделируется заказчик и пр. И на примере его разработки описываются все этапы, на выходе будет готовый сайт. Получится неплохой обучающий материал + наглядный пример этапов вашей работы для клиентов.
А может это сделать в виде блога на конкретном примере? Т.е. берется задача — сделать сайт. Выбирается тематика, придумывается легенда, моделируется заказчик и пр. И на примере его разработки описываются все этапы, на выходе будет готовый сайт. Получится неплохой обучающий материал + наглядный пример этапов вашей работы для клиентов.
Александр,
Мы уже придумали заказчика, выбрали легенду — вот здесь можно посмотреть — и как раз занимаемся проектированием. Выложим отдельно описание каждого этапа проектирования, начиная с целеполагания и исследования.
Мы уже придумали заказчика, выбрали легенду — вот здесь можно посмотреть — и как раз занимаемся проектированием. Выложим отдельно описание каждого этапа проектирования, начиная с целеполагания и исследования.
Как вы определяете стоимость сайта и на каком этапе?
Александр,
Общий алгоритм определения стоимости сайта прост как пареная репа: все затраты + ожидаемая прибыль. А вот как определить все затраты — это уже интереснее.
Мы всегда стараемся сначала заключить договор на проектирование и оцениваем сайт уже по готовому проекту. Если клиент решительно не готов к такой схеме, то есть два варианта развития событий:
1. Если это простой сайт, то мы можем прикинуть его стоимость +10%, включая проектирование, и заявить её клиенту.
2. Если это сложный сайт, то мы вынуждены отказываться от работы без предварительного проектирования. Увы, корректная оценка без проектирования часто просто невозможна.
Общий алгоритм определения стоимости сайта прост как пареная репа: все затраты + ожидаемая прибыль. А вот как определить все затраты — это уже интереснее.
Мы всегда стараемся сначала заключить договор на проектирование и оцениваем сайт уже по готовому проекту. Если клиент решительно не готов к такой схеме, то есть два варианта развития событий:
1. Если это простой сайт, то мы можем прикинуть его стоимость +10%, включая проектирование, и заявить её клиенту.
2. Если это сложный сайт, то мы вынуждены отказываться от работы без предварительного проектирования. Увы, корректная оценка без проектирования часто просто невозможна.
Ох, вы разложили все по полочкам, все то, что у меня так не получалось. И позвольте еще спросить. Если после проектирование, вы или клиент решает остановить дальнейшую разработку. Выходит у нас есть клиент с проектом сайта и допустим он с ним обращается к другим разработчикам. И меня беспокоит, согласятся ли другие разработчики работать по вашему проекту? Ведь они могут отказаться, а клиент получается потратил деньги только зря. Можно ли как то избежать таких неприятностей?
Да, такое может произойти, но в принципе другим разработчикам боятся хорошего проекта, сделанного чужими руками, не стоит. Проект даёт им ту информацию, которая им всё-равно понадобится.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
Стоит добавить, что если клиент планирует в будущем продвигать свой сайт (SEO), то необходимо и это учитывать при проектировании. Как минимум предусмотреть оптимальные точки входа (страницы) по основным группам запросов.
В целом из статьи ничего нового не узнала. Очевидные вещи для разработчика с головой.
Интересно было бы прочитать про конкретные исследования в разных отраслях — с какими сложностями столкнулись, какие особенности поведения пользователей/покупок/продаж и пр.
Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.
В целом из статьи ничего нового не узнала. Очевидные вещи для разработчика с головой.
Интересно было бы прочитать про конкретные исследования в разных отраслях — с какими сложностями столкнулись, какие особенности поведения пользователей/покупок/продаж и пр.
Или про разработку больших проектов (если есть опыт), где только этап исследования занимает от 2-3 месяцев.
Конечно, любое продвижение учитывается в задачах.
Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…
Про исследования подробнее будет в следующей статье, но только не про особенности, а про методику с примерами. Особенности поведения пользователей в каждой области свои или вовсе от области не зависят. Возможно, если будет интересный материал касательно конкретной области, опубликуем.
Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.
Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…
Про исследования подробнее будет в следующей статье, но только не про особенности, а про методику с примерами. Особенности поведения пользователей в каждой области свои или вовсе от области не зависят. Возможно, если будет интересный материал касательно конкретной области, опубликуем.
Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.
Про большие проекты: интересно как не увязнуть в цифрах и бумагах и перейти во время к разработке.
Т.е. какой объем и детализацию на этапе проектирования/ТЗ можно считать достаточной для перехода к следующим этапам разработки.
Попробую пояснить.
При разработке больших проектов достаточно сложно сразу спроектировать и предусмотреть всё, вплоть до мелочей. Во-первых, это может занять слишком много времени. Во-вторых, данные могут потерять актуальность в процессе работы. В-третьих, на выходе можно получить такое многотомное ТЗ, что ни заказчик, ни прочие участники проекта, не смогут в нем разобраться.
Но без ТЗ начинать работу нельзя.
Где золотая середина?:)
Например, есть у вас задача сделать агрегатор объявлений по продаже автомобилей. С поиском, отзывами, импортом/экспортом объявлений и прочими клевыми штуками.
Можно указать в ТЗ, что одна из характеристик авто — объем двигателя. Потом разобраться глубже и узнать, что на разных сайтах люди указывают данную характеристику по-разному: где-то в литрах, где-то в кубических сантиметрах. Изучаем дальше — выясняем, что привычнее для людей искать именно по литрам, то есть необходимо будет конвертировать для одних объявлений и оставлять как есть для других.
Стоит ли углубятся в такие детали сразу при проектировании или решать их уже в процессе?
Т.е. какой объем и детализацию на этапе проектирования/ТЗ можно считать достаточной для перехода к следующим этапам разработки.
Попробую пояснить.
При разработке больших проектов достаточно сложно сразу спроектировать и предусмотреть всё, вплоть до мелочей. Во-первых, это может занять слишком много времени. Во-вторых, данные могут потерять актуальность в процессе работы. В-третьих, на выходе можно получить такое многотомное ТЗ, что ни заказчик, ни прочие участники проекта, не смогут в нем разобраться.
Но без ТЗ начинать работу нельзя.
Где золотая середина?:)
Например, есть у вас задача сделать агрегатор объявлений по продаже автомобилей. С поиском, отзывами, импортом/экспортом объявлений и прочими клевыми штуками.
Можно указать в ТЗ, что одна из характеристик авто — объем двигателя. Потом разобраться глубже и узнать, что на разных сайтах люди указывают данную характеристику по-разному: где-то в литрах, где-то в кубических сантиметрах. Изучаем дальше — выясняем, что привычнее для людей искать именно по литрам, то есть необходимо будет конвертировать для одних объявлений и оставлять как есть для других.
Стоит ли углубятся в такие детали сразу при проектировании или решать их уже в процессе?
Светлана, я понял ваш вопрос. Изумительно, что вы это спросили.
Тут имеет смысл уточнить, что проект и ТЗ — суть вещи принципиально разные. Задача проекта — определить цели, направление и ключевые точки, а задача ТЗ — прописать детально, что и как делать, чтобы разработчик мог выполнить работу. Проект либо не содержит таких деталей, либо содержит их, но допускает их изменение. ТЗ же должно быть предельно чётким, хотя и оно должно допускать изменение.
Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.
Про потерю актуальности данных могу сказать, что если входящие данные имеют свойство быстро терять актуальность, что в идеале должно выясниться в процессе исследования, то это — отличная информация для проекта: связанные вещи на сайте прописываются как предполагающие частые изменения.
Резюмирую: углубляться в детали на уровне проекта не стоит, а какой объём данных можно считать достаточным для перехода к разработке интерфейсов и программированию — это лучше показать на примере реального проекта.
Тут имеет смысл уточнить, что проект и ТЗ — суть вещи принципиально разные. Задача проекта — определить цели, направление и ключевые точки, а задача ТЗ — прописать детально, что и как делать, чтобы разработчик мог выполнить работу. Проект либо не содержит таких деталей, либо содержит их, но допускает их изменение. ТЗ же должно быть предельно чётким, хотя и оно должно допускать изменение.
Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.
Про потерю актуальности данных могу сказать, что если входящие данные имеют свойство быстро терять актуальность, что в идеале должно выясниться в процессе исследования, то это — отличная информация для проекта: связанные вещи на сайте прописываются как предполагающие частые изменения.
Резюмирую: углубляться в детали на уровне проекта не стоит, а какой объём данных можно считать достаточным для перехода к разработке интерфейсов и программированию — это лучше показать на примере реального проекта.
Вот отличная статья на эту тему — uxmovement.com/thoughts/the-web-design-process-everyone-should-follow
Но вы, наверное, ее уже читали.
Но вы, наверное, ее уже читали.
Молча положу тут ссылочку: http://webmascon.com/
Хороший текст, скажу я как PM. Всем, кто изучает тему, посоветовал бы A Practical Guide to Information Architecture (pdf 20 mb www.mediafire.com/?o0qdcxcb0dwx3q3)
Sign up to leave a comment.
Что такое проектирование сайта и почему его нужно делать