Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению
Как часто можно услышать это: «Сайт должен быть стильным», «Сайт должен внушать доверие», «Мой дизайн должен быть эксклюзивным и непохожим на другие» и другие варианты необъективных критериев. «Стильное, лаконичное, внушающее доверие» — это все субъективные оценочные критерии, которые зависят от восприятия каждого конкретного человека.
Дизайн должен основываться на тех задачах, которые должен решать сайт, и разрабатываться для целевой аудитории, а не для представителей заказчика дизайна.
Представители заказчика, которые курируют этап разработки дизайна, очень часто не просто не относятся к целевой аудитории, а вообще очень далеки от неё по многим критериям. Как вы думаете, кто со стороны заказчика будет заниматься согласованием дизайна сайта интернет-магазина молодёжной одежды? Относящиеся к целевой аудитории молодые люди 15–17 лет, обладающие неформальным мировосприятием, или руководство компании-заказчика и представители отдела маркетинга в возрасте 30+ и тяготеющие к консервативным решениям? Кто будет заниматься вопросами дизайна сайта компании, которая продаёт продукцию, относящуюся к эконом‑классу: потенциальный клиент этой компании, человек с низким уровнем дохода и таким же низким уровнем требовательности к качеству, или топ‑менеджеры этой компании с высоким доходом и потребительским перфекционизмом? Кто вероятнее всего будет согласовывать дизайн приложения для call‑центра: типичный оператор или собственник компании? Вопросы риторические.
Дизайн не должен быть «непохожим на другие сайты», напротив, он как раз должен быть похожим. Люди привыкли к определенной структуре сайтов, к тому расположению блоков, которое часто встречается на других сайтах. И делать дизайн непохожим на другие ради «вау-эффекта» и при этом убить продажи из‑за непонимания посетителями, как этим пользоваться — совершенно глупо с точки зрения бизнеса. Безусловно, сайт должен иметь некоторую индивидуальность, но она должна быть некричащей и просматриваться в мелочах.
О дизайне можно говорить много, но, опять же, из‑за особой субъективности этого критерия никто и никогда не придет к единому мнению, каким он должен быть.
Помните главное — дизайн должен не мешать пользователю в работе с сайтом и не отвлекать его от решения задач. Никто не принимает решение о покупке товара или услуги исходя из того, понравился ли дизайн или нет (если только речь не о сайте дизайн‑студии). Вспомните себя, ведь наверняка были случаи, когда вы заказывали товары в интернет-магазине, дизайн которого, с вашей точки зрения, был плох, но тем не менее сделали заказ. Это говорит лишь о том, что дизайн не является основополагающим фактором в принятии решения о покупке. Дело в том, что сейчас в России большинство заказчиков как раз делают упор на дизайн и совсем забывают об остальных факторах, влияющих на продажу.
Часто при разработке дизайна дело заканчивается утверждением внешнего вида главной страницы, а внутренние страницы делаются на основе главной, но внимания к ним уделяется гораздо меньше. Хотя это в корне неверно. Именно на внутренних страницах пользователь проводит большую часть времени, и именно им надо уделять много внимания, чтобы убедить пользователя сделать то, что нужно вам. Возможно, вы удивитесь, но на многих сайтах значительная часть пользователей попадает не на главную страницу, а сразу на внутренние, через поисковые выдачи, прямые ссылки и закладки.
Если резюмировать, то правильный процесс создания дизайна сайта или веб‑приложения позволяет избежать очень многих ошибок.
Тематические статьи
Часто, когда встает вопрос о создании сайта, цели и задачи не формулируются или формулируются нечётко. В этом случае вы никогда не получите то, что хотели, так как разработчикам просто непонятно,, что именно вы хотите.
То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.
Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями. Сценарий лучше всего описывать по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно. Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходит в фазу поддержки и сопровождения.
Итеративная (итерационная, инкрементная или эволюционная) разработка программного обеспечения — это процесс, который осуществляется небольшими этапами, в ходе которых ведётся анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы. Жизненный цикл проекта при итеративной разработке разбит на последовательность итераций. Каждая из этих итераций является водопадным проектом в миниатюре, то есть включает в себя все ключевые процессы разработки ПО, а результатом работы по каждой итерации обычно является пригодная для использования версия продукта.
Создание дизайна для сайта или веб‑приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи‑приёмки выполненных работ. Задача этапа дизайна — разработка графических макетов интерфейса. К интерфейсу обычно выдвигаются вполне понятные технические требования — он должен быть понятен, удобен и позволять делать то, ради чего он создавался. В этой статье разберём основные подходы, позволяющие создать действительно качественный дизайн сайта.
В этой статье будут затронуты некоторые особенности разработки и поддержки ПО с точки зрения экономических критериев оценки целесообразности.
Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку». Невозможно сделать разработку сайта одновременно и быстрой, и дешевой, и индивидуальной, и качественной.
Самый простой ответ на этот вопрос: прямо пропорционально. На разработку действительно хорошего проекта требуется много времени и денег, а плохой проект можно и «на коленке» за пару часов собрать. При профессиональном менеджменте результат проекта гарантированно лучше, чем в случае, когда менеджмента нет или он неэффективный. Но есть нюансы, и влияние этих факторов достаточно нелинейно.