Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению

Как часто можно услышать это: «Сайт должен быть стильным», «Сайт должен внушать доверие», «Мой дизайн должен быть эксклюзивным и непохожим на другие» и другие варианты необъективных критериев. «Стильное, лаконичное, внушающее доверие» — это все субъективные оценочные критерии, которые зависят от восприятия каждого конкретного человека.

Дизайн должен основываться на тех задачах, которые должен решать сайт, и разрабатываться для целевой аудитории, а не для представителей заказчика дизайна.

Представители заказчика, которые курируют этап разработки дизайна, очень часто не просто не относятся к целевой аудитории, а вообще очень далеки от неё по многим критериям. Как вы думаете, кто со стороны Заказчика будет заниматься согласованием дизайна сайта интернет‑магазина молодёжной одежды? Относящиеся к целевой аудитории молодые люди 15-17 лет, обладающие неформальным мировосприятием, или руководство компании‑заказчика и представители отдела маркетинга в возрасте 30+ и тяготеющие к консервативным решениям? Кто будет заниматься вопросами дизайна сайта компании, которая продаёт продукцию, относящуюся к эконом‑классу: потенциальный клиент этой компании, человек с низким уровнем дохода и таким же низким уровнем требовательности к качеству, или топ‑менеджеры этой компании с высоким доходом и потребительским перфекционизмом? Кто вероятнее всего будет согласовывать дизайн приложения для call‑центра: типичный оператор или собственник компании? Вопросы риторические.

Дизайн не должен быть «непохожим на другие сайты», напротив, он как раз должен быть похожим. Люди привыкли к определенной структуре сайтов, к определенному расположению блоков, которое часто встречается на других сайтах. И делать дизайн непохожим на другие ради «вау-эффекта» и при этом убить продажи из‑за непонимания посетителями как этим пользоваться — совершенно глупо с точки зрения бизнеса. Безусловно, сайт должен иметь некоторую индивидуальность, но она должна быть некричащей и просматриваться в мелочах.

О дизайне можно говорить много, но, опять же, из‑за особой субъективности этого критерия никто и никогда не придет к единому мнению каким он должен быть.

Помните главное — дизайн должен не мешать пользователю в работе с сайтом и не отвлекать его от решения задач. Никто не принимает решение о покупке товара или услуги исходя из того понравился ли дизайн или нет (если только речь не о сайте дизайн‑студии). Вспомните себя, ведь наверняка были случаи, когда вы заказывали товары в интернет‑магазине, дизайн которого, с вашей точки зрения, был плох, но тем не менее сделали заказ. Это говорит лишь о том, что дизайн не является основополагающим фактором в принятии решении о покупке. Дело в том, что сейчас в России большинство заказчиков как раз делают упор на дизайн и совсем забывают об остальных факторах, влияющих на продажу.

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

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

управление продуктамиуправление проектами
Статья опубликована в 2014 году

Тематические статьи

Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования

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

управление продуктами
управление проектами
Статья опубликована в 2014 году

Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска

То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.

управление продуктами
управление проектами
Статья опубликована в 2014 году

Как написать функциональное техническое задание?

Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.

Сценарий лучше всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.

управление продуктами
управление проектами
проектирование
Статья опубликована в 2019 и обновлена в 2020 году

Водопадная модель разработки

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

Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.

управление проектами
управление продуктами
Статья опубликована в 2019 году

Итеративная модель разработки

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

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

управление продуктами
управление проектами
Agile
Статья опубликована в 2019 и обновлена в 2022 году

Создание дизайна сайта или веб‑приложения

Создание дизайна для сайта или веб‑приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи‑приёмки выполненных работ.

Задача этапа дизайна — разработка графических макетов интерфейса. К интерфейсу обычно выдвигаются вполне понятные технические требования — он должен быть понятен, удобен и позволять делать то, ради чего он создавался. В этой статье разберём основные подходы, позволяющие создать действительно качественный дизайн сайта.

дизайн
UX / UI
управление проектами
управление продуктами
Статья опубликована в 2018 году

Использование экономических критериев в веб‑разработке для оценки целесообразности реализации

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

управление продуктами
управление проектами
веб-разработка
Статья опубликована в 2014 году

​Создание сайта быстро, дешево, индивидуально и качественно

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».

экономика
веб-разработка
управление продуктами
управление проектами
Статья опубликована в 2014 году

Как зависит качество разработанного сайта от количества выделенных ресурсов и менеджмента проекта?

Самый простой ответ на этот вопрос: прямо пропорционально. На разработку действительно хорошего проекта требуется много времени, а плохой — можно «на коленке» за пару часов собрать. При профессиональном менеджменте результат проекта гарантированно лучше, чем в случае, когда менеджмента нет или он неэффективный.

экономика
веб-разработка
управление проектами
управление продуктами
Статья опубликована в 2014 году