После юридических и этических вопросов техническая часть может показаться следующим большим барьером. Нужно выбрать платформу, разобраться с формами, календарем, безопасностью, хостингом, резервными копиями, аналитикой и передачей сайта команде.
Но техническая глава не про то, что региональной команде обязательно нужно стать разработчиками. Ее задача — помочь принять понятные решения: что нужно сделать сразу, что можно упростить в первый год, а что спокойно оставить на следующий этап развития.
Для сайта «Щедрый Екатеринбург» техническая часть важна не сама по себе. Она поддерживает главную идею проекта: собрать в одном месте участников движения, события, организации, идеи, истории и способы включиться. Поэтому выбор платформы, формы регистрации и календарь событий стоит оценивать не по принципу «самое модное» или «самое сложное», а по вопросу: поможет ли это команде устойчиво вести сайт после запуска?
Что важно сделать сразу, а что можно докрутить позже
| Блок | Минимум для первого года | Можно доработать в 2027 году |
| Платформа | Выбрать решение, которое команда или подрядчики смогут запустить и поддерживать. | Пересмотреть архитектуру после первого сезона, если появятся новые сценарии и нагрузка. |
| WordPress или конструктор | Понять ограничения каждого варианта и не выбирать платформу только по привычке или рекламе. | Расширить сайт за счет дополнительных модулей, интеграций и автоматизаций. |
| Структурированные данные | Заложить понятные типы материалов: организации, события, новости, идеи, партнеры. | Добавить расширенные связи, фильтры, теги, подборки и автоматические витрины. |
| Формы | Сделать короткие и понятные формы для регистрации, заявок и обратной связи. | Настроить автоматические уведомления, статусы заявок и интеграции с таблицами или CRM. |
| Календарь событий | Дать пользователю возможность увидеть дату, место, организатора и способ участия. | Добавить фильтры, экспорт, повторяющиеся события и удобную модерацию. |
| Регистрационные данные | Хранить только нужную информацию и понимать, кто имеет к ней доступ. | Описать регламент хранения, выгрузки, удаления и передачи данных организаторам. |
| Домен, SSL, хостинг | Подключить домен, защищенное соединение и надежный хостинг. | Оптимизировать тариф, мониторинг, почту домена и техническое сопровождение. |
| Резервные копии и безопасность | Настроить обновления, резервное копирование и базовую защиту доступа. | Ввести регулярный технический аудит и план восстановления после сбоев. |
| Производительность и мобильная версия | Проверить, что сайт быстро открывается и удобно работает с телефона. | Улучшить скорость, доступность и пользовательские сценарии по данным аналитики. |
| Документация и передача | Зафиксировать доступы, основные инструкции и ответственных. | Подготовить полноценную базу знаний для команды и новых участников проекта. |
С чего начать
Техническое решение лучше выбирать не в отрыве от команды, а вместе с пониманием того, кто будет работать с сайтом после запуска.
Перед выбором платформы полезно ответить на несколько вопросов:
- кто будет добавлять новости, события и организации;
- есть ли у команды человек, который сможет администрировать сайт;
- есть ли подрядчик или технический партнер;
- какие функции нужны уже в первый год;
- какие функции можно отложить;
- нужно ли будет подключать внешние сервисы;
- насколько важно владеть сайтом и переносить его при необходимости;
- какой бюджет есть не только на запуск, но и на поддержку.
Самая частая ошибка — выбирать платформу только по тому, насколько легко на ней собрать первый экран. Для регионального сайта важен не только старт, но и дальнейшая жизнь: обновления, безопасность, новые разделы, формы, календарь, интеграции, права доступа и передача проекта другим людям.
В первый год не обязательно строить сложную систему. Достаточно выбрать устойчивую основу, на которой можно запустить рабочую версию и не упереться в ограничения через несколько месяцев.
Такую первую рабочую версию часто называют MVP — минимально жизнеспособным продуктом. В данном случае это сайт, на котором уже работают основные пути пользователя: понять идею проекта, найти событие или организацию, увидеть следующий шаг и связаться с ответственным человеком. Дополнительные функции можно развивать после проверки этих путей на реальных посетителях.
5.1. Выбор платформы
Выбор платформы зависит от опыта команды, доступных подрядчиков, бюджета и задач сайта. Универсального ответа здесь нет. Один проект можно быстрее запустить на конструкторе, другой — удобнее сразу делать на WordPress, третий может потребовать отдельной разработки.
Главный критерий — не абстрактная «правильность» платформы, а способность команды с ней жить.
При выборе стоит учитывать:
- кто сможет настроить сайт;
- кто будет обновлять материалы;
- насколько легко добавить новые типы страниц;
- можно ли подключить формы, календарь, аналитику и рассылки;
- можно ли перенести сайт на другой хостинг;
- сколько стоит поддержка через год;
- насколько легко найти специалиста, который поможет с доработками.
Если у команды уже есть надежный подрядчик, который хорошо работает с конкретной системой, это важный аргумент. Если в регионе есть специалисты по WordPress, а команда готова освоить администрирование, WordPress может стать более гибкой основой. Если нужно очень быстро сделать простой сайт без сложных связей между материалами, иногда подойдет конструктор.
Минимум для первого года: выбрать платформу, которую команда реально сможет поддерживать.
Что можно доработать в 2027 году: после первого сезона оценить, каких возможностей не хватило, и развивать сайт уже на основе реального опыта.
5.2. Почему сайт «Щедрый Екатеринбург» сделан на WordPress
WordPress выбран как открытая и распространенная платформа. У него большая экосистема платных и бесплатных дополнений, много разработчиков и опытных пользователей, а значит, проект не оказывается привязан к одному конкретному исполнителю.
Для регионального сайта это особенно важно. Сайт может развиваться постепенно: сначала главная страница, новости, календарь и формы, затем каталог организаций, фильтры, интеграции, дополнительные сценарии для партнеров и участников.
Сильные стороны WordPress для такого проекта:
- сайт принадлежит владельцу и может размещаться на выбранном хостинге;
- можно создавать разные типы материалов: события, организации, новости, кейсы, партнеры;
- есть готовые решения для форм, календарей, SEO, аналитики и безопасности;
- можно настроить роли пользователей для редакторов и администраторов;
- легко найти специалистов для поддержки и доработок;
- можно начать с простой версии и постепенно усложнять структуру.
Важно понимать: WordPress не означает, что сайт обязательно должен быть сложным. Современный WordPress может работать вместе с визуальными редакторами и конструкторами страниц, шаблонами дизайна, автоматизациями и внешними сервисами. То есть команда получает не только гибкость открытой платформы, но и удобство дальнейшего редактирования.
Минимум для первого года: настроить WordPress так, чтобы команда могла самостоятельно обновлять основные разделы.
Что можно доработать в 2027 году: добавить более сложные шаблоны, роли, автоматизации и интеграции, когда появится понятная потребность.
5.3. Когда может подойти конструктор
Конструкторы сайтов удобны, когда нужно быстро собрать простую страницу или небольшой сайт без сложной структуры. Они дают готовые блоки, визуальное редактирование и часто снимают часть технических вопросов: хостинг, SSL-сертификат, базовую публикацию.
Такой вариант может подойти, если:
- сайт нужен как простая витрина;
- нет сложного календаря и каталога организаций;
- не нужны нестандартные формы и интеграции;
- команда не планирует глубокую доработку;
- важнее быстрый старт, чем гибкость.
Но у конструкторов есть ограничения. Часто сайт фактически находится внутри сервиса: его сложнее перенести, доработать нестандартную функцию или подключить то, что не предусмотрено платформой. Если проект начнет расти, может оказаться, что нужная возможность недоступна или требует обходных решений.
Поэтому конструктор лучше рассматривать как вариант для очень простой версии или временного запуска, а не как универсальное решение для развивающейся региональной платформы.
Минимум для первого года: если выбран конструктор, заранее проверить, можно ли реализовать календарь, формы, аналитику, домен и нужные страницы.
Что можно доработать в 2027 году: при росте проекта оценить переход на более гибкую платформу или расширение текущего решения.
5.4. Структурированные данные сайта
Региональный сайт удобнее поддерживать, когда разные материалы не смешаны в одну общую ленту. Событие, организация, новость, идея и партнер — это разные сущности. У них разные поля, разные страницы и разные пользовательские сценарии.
Например, для события нужны дата, место, организатор, формат, регистрация и контакт. Для организации — описание, сфера работы, сайт, социальные сети и способы участия. Для новости — дата публикации, текст, изображения и связанные материалы.
Такой подход помогает:
- быстрее добавлять материалы;
- не забывать важные поля;
- строить фильтры и подборки;
- связывать события с организациями;
- переиспользовать информацию в разных разделах сайта.
Минимум для первого года: определить основные типы материалов и обязательные поля для каждого.
Что можно доработать в 2027 году: добавить связи между материалами, расширенные фильтры, теги и автоматические подборки на главной странице.
5.5. Формы
Формы — один из главных рабочих инструментов сайта. Через них организации подают заявки, партнеры связываются с командой, пользователи сообщают об ошибках, а в некоторых проектах люди регистрируются на события.
Форма должна быть короткой, понятной и честной. Пользователь должен видеть, зачем он оставляет данные, кто их получит и что произойдет после отправки. Чем меньше лишних полей, тем выше вероятность, что человек дойдет до конца и отправит заявку.
Важно не смешивать разные сценарии в одной форме. У посетителя, который хочет прийти на мероприятие, одни задачи. У организации, которая хочет добавить событие, другие. У партнера, который предлагает помощь, третьи. Если всех вести в одну большую анкету, форма становится длинной, непонятной и неудобной для всех сразу.
Для первого года обычно нужны:
- ссылка на форму организатора или собственная форма регистрации на мероприятие;
- форма заявки для организации или инициативы;
- форма добавления или предложения события;
- форма для партнеров;
- форма обратной связи;
- форма сообщения об ошибке или уточнении.
У каждой формы должна быть своя логика и свой минимальный набор полей. Для участника мероприятия обычно достаточно имени, одного способа связи и выбранного события. Для организации могут понадобиться название, контактное лицо, описание инициативы, ссылка на сайт или социальные сети. Для партнера — тип предложения и контакт для связи.
Есть два рабочих сценария регистрации. Региональный сайт может вести на форму организатора и не получать данные участника. Либо регистрация может проходить на самом сайте с последующей передачей заявки организатору. Первый вариант проще для старта; второй дает более цельный путь, но требует заранее определить оператора данных, доступы, сроки хранения и правила передачи.
На «Щедром Екатеринбурге» обычные участники записываются на стороне организаций, которые проводят события. Собственная форма сайта используется для заявок от потенциальных организаторов и партнеров и передает обращения во внутреннюю CRM фонда «Менора» — Битрикс24.
Отдельно нужно предусмотреть согласие на обработку персональных данных. Оно должно быть не спрятано в глубине сайта, а понятно связано с отправкой формы. Пользователь должен видеть, что он соглашается на обработку данных, понимать, для чего они собираются, и иметь возможность перейти к политике обработки персональных данных.
Каждую форму стоит проверить вручную: отправляется ли заявка, приходит ли уведомление, понятен ли текст после отправки, есть ли согласие на обработку данных, не собираются ли лишние сведения, понятно ли пользователю, что будет дальше.
Минимум для первого года: настроить только действительно нужные формы, разделить их по аудиториям и проверить на реальных сценариях.
Что можно доработать в 2027 году: добавить статусы заявок, автоматические письма, выгрузки в таблицы и интеграции с CRM.
5.6. Календарь событий
Календарь — один из центральных разделов регионального сайта. Он помогает показать движение не как разовую акцию, а как живую карту событий, к которым можно присоединиться.
При этом у «Щедрого вторника» есть особенность: основная дата акции обычно одна. Часть мероприятий проходит в сам день акции, часть — рядом с ним, за несколько дней до или после. Поэтому обычная календарная сетка по датам может оказаться не самым информативным способом показать программу. Если почти все события собраны вокруг одного периода, пользователю важнее не только «когда», но и «что это за событие», «для кого оно», «как можно участвовать» и «какой смысл за ним стоит».
Поэтому календарь лучше проектировать как систему навигации по событиям, а не ограничиваться списком дат. Важную роль играют фильтры, рубрики и направления.
События можно разделять по таким признакам:
- формат: офлайн, онлайн, смешанный;
- аудитория: жители, семьи, дети, бизнес, НКО, волонтеры, партнеры;
- направление помощи: культура, образование, экология, социальная поддержка, инклюзия, животные, городские инициативы;
- способ участия: прийти, пожертвовать, стать волонтером, передать вещи, рассказать о проекте;
- район или город;
- организатор;
- дата и время.
Для пользователя в карточке события должны быть понятны:
- название;
- дата и время;
- место или онлайн-формат;
- организатор;
- краткое описание;
- кому подойдет событие;
- как зарегистрироваться;
- куда обратиться с вопросами.
Для команды важно, чтобы события было легко добавлять, редактировать, переносить и снимать с публикации. Если каждое изменение требует разработчика, календарь быстро устареет. Также важно заранее договориться, какие поля обязательны для события: без этого фильтры и рубрики быстро становятся хаотичными.
На «Щедром Екатеринбурге» техническая основа фильтров подготовлена. Чтобы они начали помогать посетителям, редактору нужно последовательно назначить событиям согласованные метки. Это хороший пример того, что функция зависит не только от разработки, но и от качества данных.
Минимум для первого года: сделать календарь, который удобно обновлять вручную, содержит базовую информацию о каждом событии и позволяет пользователю искать события не только по дате, но и по смыслу.
Что можно доработать в 2027 году: расширить фильтры по формату, аудитории, теме, району, организатору и способу участия, добавить подборки событий и возможность выгрузки программы.
5.7. Интеграции
Интеграции нужны, когда сайт должен обмениваться данными с другими сервисами: таблицами, рассылками, CRM, платежными страницами, социальными сетями, аналитикой или календарями.
В первый год лучше не подключать интеграции «на всякий случай». Каждая связь между сервисами требует настройки, проверки и поддержки. Если команда пока спокойно обрабатывает заявки вручную, это может быть нормальным решением для MVP.
Полезно начать с простого списка:
- куда попадают заявки из форм;
- кому приходят уведомления;
- где хранится список участников;
- как команда передает данные организаторам;
- какие сервисы уже используются в проекте.
Минимум для первого года: подключить только те интеграции, без которых команда не сможет нормально работать.
Что можно доработать в 2027 году: автоматизировать повторяющиеся процессы, если они действительно начали занимать много времени.
5.8. Работа с регистрационными данными
Регистрационные данные — это не просто строки в таблице. За ними стоят люди, которые доверили сайту свои контакты и ожидают понятной коммуникации.
Если регистрация полностью проходит на стороне организатора, региональный сайт не должен создавать у посетителя впечатление, что хранит или подтверждает его запись. В этом случае техническая задача площадки — поддерживать актуальную ссылку и ясно обозначать переход. Правила ниже относятся к тем заявкам, которые региональная команда действительно получает через собственные формы.
Технически важно заранее определить:
- где хранятся заявки;
- кто имеет доступ к этим данным;
- как данные передаются организатору;
- как удалить заявку по просьбе пользователя;
- как долго данные сохраняются после события;
- что делать, если событие отменено или перенесено.
Для первого года не обязательно внедрять сложную систему управления заявками. Но должен быть понятный порядок: ответственный человек, место хранения, доступы и простой способ найти нужную заявку.
Минимум для первого года: хранить заявки в понятном месте и ограничить доступ только тем, кому он нужен.
Что можно доработать в 2027 году: описать регламент хранения, удаления, передачи и архивирования регистрационных данных.
5.9. Социальные функции
Социальные функции помогают участникам чувствовать, что они часть общего движения. Это могут быть кнопки для распространения события, ссылки на социальные сети, подборки историй, отметки партнеров, публичные страницы организаций.
В первый год лучше выбирать простые и понятные функции:
- кнопки «поделиться»;
- ссылки на социальные сети проекта;
- карточки организаций и партнеров;
- истории реализованных инициатив;
- возможность быстро отправить ссылку на событие.
Не стоит сразу создавать сложную внутреннюю социальную сеть, личные кабинеты или рейтинги участников, если без этого можно запустить проект. Такие функции требуют модерации, поддержки и отдельной логики безопасности.
Минимум для первого года: дать людям возможность легко делиться событиями и находить страницы организаций.
Что можно доработать в 2027 году: рассмотреть личные кабинеты, избранное, профили участников или другие функции только после проверки реального спроса.
5.10. Домен
Домен — это адрес сайта. Он должен быть понятным, легко произноситься и ассоциироваться с проектом или регионом.
При выборе домена важно проверить:
- свободен ли адрес;
- кто будет владельцем домена;
- у кого есть доступ к управлению;
- когда нужно продлевать оплату;
- не похож ли домен на адрес другой организации;
- легко ли его написать без ошибки.
Домен лучше регистрировать на организацию или ответственное лицо, которое действительно связано с проектом, а не на случайного подрядчика. Иначе при смене исполнителя могут возникнуть проблемы с доступом.
Минимум для первого года: зарегистрировать домен, сохранить доступы и записать дату продления.
Что можно доработать в 2027 году: настроить доменную почту, дополнительные поддомены и резервный порядок управления доступами.
5.11. SSL-сертификат
SSL-сертификат нужен, чтобы сайт открывался по защищенному соединению. Для пользователя это выглядит как адрес, начинающийся с https://, и значок защищенного соединения в браузере.
Для сайта с формами это обязательная базовая настройка. Без нее браузеры могут показывать предупреждения, а пользователи будут меньше доверять регистрации и обратной связи.
Во многих случаях SSL-сертификат можно подключить бесплатно через хостинг. Главное — проверить, что все страницы открываются по защищенному адресу и нет ошибок после подключения.
Минимум для первого года: подключить SSL-сертификат и убедиться, что сайт стабильно открывается через https://.
Что можно доработать в 2027 году: настроить автоматическое продление, мониторинг сертификата и проверку технических ошибок.
5.12. Хостинг
Хостинг — это место, где физически размещается сайт. От него зависят скорость, стабильность, резервные копии, безопасность и удобство поддержки.
Для регионального сайта не всегда нужен дорогой тариф. Но хостинг должен быть надежным и понятным для тех, кто будет обслуживать проект.
При выборе хостинга стоит смотреть на:
- поддержку WordPress, если сайт сделан на WordPress;
- автоматические резервные копии;
- понятную панель управления;
- техническую поддержку;
- возможность быстро увеличить ресурсы;
- расположение серверов и требования к хранению данных;
- стоимость продления.
Минимум для первого года: выбрать стабильный хостинг, к которому есть доступ у ответственных людей.
Что можно доработать в 2027 году: настроить мониторинг доступности, оптимизировать тариф и разделить рабочую и тестовую версии сайта.
5.13. Резервное копирование
Резервные копии нужны не тогда, когда все работает, а когда что-то пошло не так: обновление сломало сайт, материал случайно удалили, возникла техническая ошибка или понадобилось вернуться к предыдущей версии.
Для сайта важно копировать:
- файлы;
- базу данных;
- загруженные изображения и документы;
- настройки темы и плагинов;
- экспорт важных форм и заявок, если они хранятся внутри сайта.
Копии должны создаваться регулярно и храниться не только на самом сайте. Иначе при проблеме с хостингом можно потерять и сайт, и резервную копию.
Минимум для первого года: настроить автоматические резервные копии и один раз проверить восстановление.
Что можно доработать в 2027 году: описать план восстановления, периодичность копий и ответственного за проверку.
5.14. Безопасность
Безопасность сайта начинается с простых привычек. Не нужно сразу строить сложную систему, но базовые меры должны быть с первого дня.
Минимальный набор:
- сложные пароли;
- отдельные учетные записи для каждого участника команды;
- доступ администратора только тем, кому он действительно нужен;
- регулярные обновления платформы и дополнений;
- резервные копии;
- защита форм от спама;
- удаление неиспользуемых плагинов и тем.
Для WordPress особенно важно не устанавливать лишние плагины без необходимости. Каждый дополнительный модуль — это не только новая функция, но и то, что нужно обновлять и проверять.
Минимум для первого года: настроить доступы, обновления, резервные копии и защиту форм.
Что можно доработать в 2027 году: провести технический аудит, настроить журнал действий и более строгие правила доступа.
5.15. Производительность
Сайт должен быстро открываться, особенно с телефона и неидеального интернета. Если страница долго загружается, пользователь может не дождаться календаря, формы или важной информации.
На скорость чаще всего влияют:
- тяжелые изображения;
- большое количество подключенных скриптов;
- лишние плагины;
- сложные визуальные эффекты;
- слабый хостинг;
- отсутствие кэширования.
В первом году достаточно следить за базовыми вещами: сжимать изображения, не перегружать страницы, включить кэширование и проверять скорость главной страницы, календаря и форм.
Минимум для первого года: убедиться, что ключевые страницы открываются быстро на телефоне.
Что можно доработать в 2027 году: провести оптимизацию изображений, кода, кэширования и сценариев загрузки.
5.16. Мобильная адаптация
Многие пользователи будут заходить на сайт с телефона: из социальных сетей, мессенджеров, рассылок или по ссылке от знакомых. Поэтому мобильная версия не должна быть второстепенной.
На телефоне особенно важно проверить:
- читается ли текст;
- удобно ли нажимать кнопки;
- помещается ли форма на экран;
- легко ли найти дату и место события;
- не ломается ли календарь;
- открываются ли карты, ссылки и контакты;
- понятно ли, что произошло после отправки формы.
Мобильная адаптация — это не только красивый внешний вид. Это возможность человеку быстро понять, куда он попал и что он может сделать.
Минимум для первого года: вручную проверить главную страницу, календарь, карточку события и формы на телефоне.
Что можно доработать в 2027 году: провести пользовательское тестирование и улучшить сценарии по реальным наблюдениям.
5.17. Веб-аналитика
Аналитика помогает понять, как сайт используется на практике. Без нее команда опирается только на ощущения: кажется, что раздел читают, форма работает, календарь нужен, но данных нет.
В первом году достаточно базовых показателей:
- сколько людей заходит на сайт;
- какие страницы смотрят чаще всего;
- откуда приходят пользователи;
- какие события открывают;
- сколько людей отправляют формы;
- где пользователи чаще всего уходят со страницы.
Важно собирать аналитику аккуратно и в соответствии с правилами обработки данных. Команде не нужно знать о пользователе больше, чем требуется для улучшения сайта.
Минимум для первого года: подключить базовую аналитику и регулярно смотреть ключевые страницы и формы.
Как подключить Яндекс Метрику: создать счетчик для сайта, установить его код на все страницы и проверить, что визиты появляются в отчетах. Для WordPress можно использовать официальный плагин. После этого выбрать несколько важных действий — например, переход к организатору или отправку формы — и настроить для них цели. Пошаговый порядок есть в инструкции Яндекс Метрики. Если сайт настраивает специалист, передайте ему эту задачу и попросите показать, где команда сможет смотреть результаты.
Что можно доработать в 2027 году: расширить набор целей, настроить отчеты по кампаниям и показатели эффективности, которые дальше будут раскрыты в отдельной главе.
5.18. Документация и передача сайта
Сайт становится устойчивым, когда он не держится в голове одного человека. Даже если проект запускает один подрядчик или активный участник команды, нужно заранее подумать о передаче.
В документации стоит зафиксировать:
- где зарегистрирован домен;
- где расположен хостинг;
- кто имеет доступ к панели управления;
- какие плагины и сервисы используются;
- как добавить новость;
- как добавить событие;
- как изменить карточку организации;
- как выгрузить заявки;
- как восстановить сайт из резервной копии;
- к кому обращаться по техническим вопросам.
Такая документация не должна быть большой. В первый год достаточно короткой инструкции в общей папке и списка доступов, который хранится безопасно у ответственных людей.
Минимум для первого года: подготовить краткую инструкцию для команды и список ответственных за технические вопросы.
Что можно доработать в 2027 году: создать полноценную базу знаний, чек-листы обновления и порядок передачи сайта новым участникам.
Итоговый чек-лист главы
Перед запуском сайта проверьте:
- платформа выбрана с учетом реальных возможностей команды;
- команда понимает ограничения выбранного решения;
- основные типы материалов и поля описаны;
- формы короткие, понятные и проверены;
- календарь событий удобно обновлять;
- регистрационные данные хранятся в понятном месте;
- подключены только нужные интеграции;
- домен зарегистрирован и доступы сохранены;
- сайт открывается по защищенному соединению;
- выбран надежный хостинг;
- настроены резервные копии;
- доступы выданы только нужным людям;
- ключевые страницы быстро открываются;
- сайт удобно работает на телефоне;
- подключена базовая аналитика;
- команда получила краткую инструкцию по работе с сайтом.
Техническая часть не должна становиться причиной откладывать запуск. Хороший региональный сайт можно развивать постепенно: сначала сделать устойчивую основу, затем проверить ее на реальных пользователях, а после первого сезона улучшать те места, где действительно возникла потребность.
Техническая основа отвечает на вопрос, работает ли сайт. Следом возникает другой: помогает ли его внешний вид людям понять, куда нажать, чему доверять и как присоединиться? Ответ связан с дизайном регионального сайта — балансом между общей айдентикой «Щедрого вторника» и локальным характером региона, фотографиями, цветом, типографикой и решениями, благодаря которым площадка остается рабочей, живой и узнаваемой.