{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

Сайт для строительной компании

Рассказываю о процессе реализации проекта для строительной компании. О решении задач и преодолении трудностей, с которыми пришлось столкнуться. А также показываю, что в итоге получилось :))

Введение и задачи

В январе ко мне обратились за созданием сайта для #строительнойкомпании ООО «СЕВЕР-ЛЕС», которая на протяжении многих лет занимается строительством деревянных зданий – бань, частных домов (преимущественно), и др.

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

Исходя из цели, изначально, были поставлены след. #задачи :

1. Создать #многостраничныйсайт , чтобы пользователь мог легко и понятно передвигаться по интересующим его разделам, а также для более эффективной работы настроек SEO в дальнейшем.

2. Разместить и оформить необходимую информацию о компании, о порядке осуществления заказа и т.д., включая отзывы клиентов, чтобы закрыть возникающие у пользователя вопросы и решить проблему с доверием;

3. Разместить информацию о преимуществах и выгодах, чтобы привлечь новых потенциальных покупателей (заказчиков);

4. Разместить информацию об основных «продуктах» строительства, чтобы оставить у пользователя наглядное представление того, что он может получить в итоге, за что будет платить деньги компании, а также подтолкнуть его к новым идеям проектировки;

5. Настроить и подключить сервис приема данных на сайте (базовая форма заявки: ФИО, номер тел. и эл. почта для связи);

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

Структура и прототипирование

Обсудив проект и проведя маркетинговый анализ, я выяснила, какой сайт нужен конкретно этой компании для достижения поставленной цели и предложила след. решение:

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

Дизайнерское решение

С учетом ниши, целевой аудитории и современных тенденций был разработан соответствующий #дизайн

Сайт выполнен на привычном светлом фоне в минималистическом стиле с добавлением базовой анимации элементов.

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

Лидирующие цвета: желто-оранжевый - олицетворяющий тепло, солнце, радость, природный свет; синий (небесный) - ассоциирующийся с надежностью, спокойствием, стабильностью; светло-серый #цвет – нейтральный, балансирующий.

Разработка

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

В других случаях, более предусмотрительные компании (на мой субъективно-объективный взгляд))) создают на сайте формы заявок, которые можно заполнять и отправлять в любое время суток и никто и практически ничто тебе не помешает это сделать (в отличие от тел. звонка). Но в 90% таких форм я не увидела никакого уточняющего вопроса. Всё, что спрашивается в этих заявках, это контактные данные (ФИО, тел., эл. почта). В них нет ни слова об интересующем вопросе/проекте. Мне показалось это большим упущением, поскольку при созвоне обеим сторонам будет сложнее выстраивать эффективный диалог. Менеджеру придется задавать лишние вопросы, человеку по ту сторону придется вспоминать, что он хотел спросить, какой объект ему понравился, а менеджеру быстро придумывать ответы на эти вопросы и склеивать находу «готовое предложение», чтобы не потерять потенциального заказчика.

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

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

Таким образом, получая более конкретизированные запросы от пользователя, менеджеру будет проще их обрабатывать. У него будет возможность заранее рассмотреть определенный вопрос и дать хорошо подготовленный ответ, что в свою очередь поможет более успешно закрывать заявки и тем самым увеличивать прибыль компании. Разделение форм для заявок с вопросами и заявок на конкретные проекты также помогло разграничить «более теплых» пользователей - готовых на сделку, и «менее теплых» - которые только думают, присматриваются, знакомятся с компанией.

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

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

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

Мессенджер находится в нижнем правом углу и сопровождает пользователя по всему сайту. При нажатии на иконку, пользователь может выбрать наиболее удобный для него способ взаимосвязи и задать вопрос напрямую (а не через форму заявки).

Если со всеми остальными элементами сайта всё было предельно ясно и понятно, то с тем, как лучше оформить и преподнести сами «товары» (объекты строительства) возникли определенные трудности. Я представляла, как это должно выглядеть по желанию заказчика, но не очень представляла, каким образом это можно будет реализовать технически. P.s: честно говоря, при составлении ТЗ, не знала как именно решу этот вопрос, но точно знала, что что-нибудь (хорошее))) придумаю. В конце концов, это же моя работа – находить решения в нерешаемых ситуациях пхахах (наверное, тут дизайнеры меня поймут))))

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

Кроме того, карточек много (50+) – делать их по отдельности полностью вручную неразумно, как минимум из-за дальнейших сложностей с их редактированием. Здесь, как и многим другим, мне явилась очевидная идея с к а т а л о г о м.

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

Итак, проблема с каталогом была решена – задача реализована. Пользователь заходит на страницу с каталогом, применяет необходимую фильтрацию, выбирает понравившуюся постройку и в случае интереса нажимает на кнопку «обсудить этот проект», попадает в форму заявки, пишет название товара, которое у него перед глазами (что очень удобно) и отправляет данные. Плюс ко всему, пользователь может выбрать сразу несколько объектов (количество которых будет отображаться цифрой на иконке с домом в правом верхнем углу) и оставить по ним одну заявку. Преимуществом также является и то, что менеджер получает данные не только о пользователе, но и проекте (проектах), который(е) этого пользователя заинтересовал(и). Это дает ему возможно не просто звонить заказчику и задавать вопросы, но и подготовиться, собрать информацию по определенному, заранее известному проекту перед разговором. Отпадает необходимость вспоминать что-то находу, импровизировать, чтобы не тревожить заказчика дважды. Появляется возможность здесь и сейчас озвучивать конкретное предложение, что делает весь процесс более удобным и эффективным для обеих сторон (продавца/исполнителя и заказчика).

P.s:

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

0
9 комментариев
Написать комментарий...
Альберт Базалеев

Мне интересны технические детали, если можно.

В разделе Структура и прототипирование можно было бы показать прототипы.

А структуру сайта Вы в Miro делали? Или какой редактор UML-диаграмм Вы предпочитаете?

Кстати, что касается структуры, то Вы ограничились только построением этой структуры или Ваш вариант User Flow более широкий?

Прототипирование в Figma или вся работа в Тильде?

Ответить
Развернуть ветку
Дарина Грызунова
Автор

Спасибо за вопросы, Альберт)

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

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

Вы грамотно подметили, что структура сокращённая, да) User flow намного шире и именно поэтому я не смогла его опубликовать (слишком большое изображение получалось, либо не отображалось в надлежащем качестве).

Вся работа от и до выполнена на Tilda (этапы согласовывались посредством ссылки на «черновой» вариант сайта).
Честно говоря, создавать прототипы и дизайн я предпочитаю в фигме, но иногда это просто создает бОльший объём работы, т.к потом всё это придётся переносить на тильду (особенно когда речь идёт о многостраничном сайте). В данном случае просто не было смысла создавать весь макет в фигме, а потом ещё тратить время на его перенос в тильду.

Ответить
Развернуть ветку
Михаил Хананашвили

Мдэ, самую малость забыли - поговорить с пользователями :/
Ну такое себе, надо бы уже давно осознать важность этого этапа

Ответить
Развернуть ветку
Дарина Грызунова
Автор

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

Ответить
Развернуть ветку
Михаил Хананашвили

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

Ответить
Развернуть ветку
Дарина Грызунова
Автор

Эмм, ну понятно. Рада, что у вас получается общаться с пользователями интерфейса до создания интерфейса

Ответить
Развернуть ветку
Виталий Асташкин

Плохо, что у вас это не получается

Ответить
Развернуть ветку
Михаил Хананашвили

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

Ответить
Развернуть ветку
Сергей Болдин

Можно использовать готовые решения, например Аспро.Стройка или СтройРазраб.

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда