Медицинский сайт приходится проектировать в условиях, где у
пользователя редко бывает абстрактный интерес к учреждению. Чаще он
приходит с конкретным вопросом: понять, чем занимается организация,
найти нужное направление, получить контакт, разобраться в порядке
обращения или перейти к заявке. При этом сам ресурс может одновременно
содержать медицинскую, организационную, научную и образовательную
информацию.
В проектах Mercury RUS этот диапазон хорошо виден на разных типах
медицинских ресурсов: от специализированного лендинга
сайта Научного центра инновационных
лекарственных средств ВолгГМУ, крупного ресурса
государственных медицинских учреждений в Рязани и Нефтеюганске. Общий
вывод здесь не нормативный, а проектный: чем разнороднее информация, тем
важнее сначала определить сценарии пользователя и только затем строить
разделы.
Один сайт — несколько
информационных задач
У медицинского ресурса может быть очень разная глубина.
Специализированный лендинг решает узкую задачу и ведёт пользователя к
одному основному действию. Многостраничный сайт учреждения, напротив,
должен удерживать большое количество независимых информационных
направлений.
В проекте центра хирургии «РЖД-МЕДИЦИНА Волгоград» задача была
конкретной: создать лендинг, связанный с Bitrix24, для работы с
обращениями пациентов. Здесь информационная архитектура подчинена
короткому пути — человек знакомится с направлением и может перейти к
обращению.
У Научного центра инновационных лекарственных средств ВолгГМУ другая
логика. В исходной задаче зафиксировано создание единой
информационно-образовательной среды; сайт содержит информацию о научных
исследованиях, образовательных программах и деятельности центра. Это уже
не один целевой сценарий, а несколько самостоятельных массивов контента,
которые должны сосуществовать в одной структуре.
Поэтому первый вопрос при проектировании медицинского сайта — не
«какие разделы обычно бывают у больницы», а «какие типы задач должен
решать именно этот ресурс».
Начинать
лучше со сценариев, а не с дерева разделов
Информационная архитектура становится устойчивее, если до построения
меню описать несколько ключевых пользовательских путей.
Человек может прийти на сайт, чтобы узнать о конкретном направлении
учреждения. Другому нужен общий контакт. Третий изучает деятельность
центра. Четвёртый переходит к обращению. Для научно-образовательного
ресурса отдельными сценариями становятся поиск информации об
исследованиях или образовательных программах.
Эти сценарии необязательно превращать в отдельные пользовательские
роли и тем более не нужно придумывать функции, которых нет в исходных
данных. Достаточно использовать их как проверку структуры: может ли
пользователь начать с понятной точки и дойти до нужной информации без
необходимости разбираться во внутренней административной организации
учреждения.
Такой подход особенно важен для крупных сайтов, где внутреннее
устройство учреждения и логика пользователя часто не совпадают.
лендинг и большой медицинский сайт требуют разной архитектуры
Опыт проекта центра хирургии показывает ценность узкой структуры.
Если ресурс посвящён конкретному медицинскому направлению, лишние уровни
навигации могут только увеличивать дистанцию до целевого действия. Здесь
важны ясная подача специализации, последовательный контент и понятный
переход к обращению.
У многостраничного сайта задача обратная: не сократить всё до одного
пути, а развести несколько равноправных информационных потоков. В таких
проектах структура должна помогать пользователю понимать, где он
находится и какой тип информации получит дальше.
Это различие полезно зафиксировать ещё до прототипирования. Нельзя
просто взять структуру большого учреждения и сжать её в лендинг. И
наоборот, логика посадочной страницы не масштабируется автоматически на
ресурс с большим объёмом контента.
Обработка
обращения — часть пользовательского пути
В проекте центра хирургии лендинг был интегрирован с CRM-системой
Bitrix24 для обработки заявок. Для пользователя это выглядит как обычная
форма, но с точки зрения проектирования здесь появляется важная связь
между публичной частью сайта и внутренним процессом учреждения.
Это означает, что форма обращения должна рассматриваться не как
декоративный финальный блок страницы. Нужно заранее понимать, куда
попадает запрос и какой следующий шаг ожидает пользователя и
организацию.
При этом такой механизм нельзя автоматически переносить на все
медицинские проекты. Для Городской детской
поликлиники № 7 в Рязани,
Рязани и Нефтеюганской районной
больницы исходный Content Graph подтверждает сами государственные
медицинские проекты, но не даёт достаточной детализации конкретной
механики записи или обработки обращений. Поэтому эти кейсы важны как
подтверждение практики Mercury в сегменте, но не как основание
приписывать всем медицинским сайтам одинаковую функциональность.
Большой объём
контента требует приоритетов
Медицинская тематика легко приводит к перегруженной навигации: всё
кажется важным, и поэтому всё пытаются вывести на первый уровень.
Практически это создаёт обратный эффект — пользователь видит множество
равнозначных ссылок и хуже понимает, с чего начать.
Рабочий подход — сначала разделить контент по задачам, затем
определить, какие точки входа нужны чаще всего, и только после этого
строить меню и внутреннюю навигацию.
Для научного центра это может означать явное разведение информации о
деятельности, исследованиях и образовательных программах. Для
специализированного медицинского лендинга — концентрацию на одном
направлении и обращении. Для крупного учреждения — отдельную работу с
несколькими информационными массивами без попытки показать весь сайт в
первом экране.
Не
смешивать информационную архитектуру и нормативный аудит
Для государственных медицинских ресурсов нормативный контекст
действительно существует, но это отдельная задача. Требования
законодательства, обязательные разделы, стандарты и актуальные правила
должны проверяться по действующим первоисточникам на момент проекта.
Поэтому при проектировании полезно разделять два слоя. Первый —
нормативная проверка того, что обязано присутствовать на сайте. Второй —
информационная архитектура: как организовать подтверждённый состав
информации так, чтобы пользователь мог им пользоваться.
Эта статья касается именно второго слоя. Такой подход не подменяет
правовую проверку и не превращает общие проектные наблюдения в
нормативные требования.
Практическая схема
предпроектной работы
Перед созданием прототипов медицинского сайта полезно
зафиксировать:
- какие типы информации реально будут поддерживаться;
- какие пользовательские задачи являются основными;
- какие сценарии требуют короткого пути;
- где пользователю достаточно информации, а где требуется
обращение; - какие массивы контента должны быть разделены;
- кто будет поддерживать и актуализировать каждый тип информации;
- какие нормативные вопросы требуют отдельной внешней проверки.
После этого дерево сайта перестаёт быть перечнем «типовых медицинских
разделов» и становится отражением реальных задач учреждения.
Главное
Информационная архитектура медицинского сайта начинается с понимания
того, зачем пользователь пришёл на ресурс и какой тип информации ему
нужен.
Проекты Mercury RUS показывают разные масштабы этой задачи: короткий
специализированный лендинг с обработкой обращений,
информационно-образовательная среда научного центра, крупные сайты
медицинских учреждений. Универсальной структуры для них нет. Но есть
общий принцип: сначала определить сценарии и массивы контента, затем
строить навигацию и только после этого переходить к интерфейсам.