Модернизация семиуровневой навигационной системы SGS: пример из практики

SGS (ранее Societe Generale de Surveillance ) — глобальная сервисная организация и поставщик услуг по инспекции, проверке, тестированию и сертификации в 14 отраслях. Веб-сайт SGS (наряду с 60 локализованными веб-сайтами) в первую очередь продвигает основные услуги организации, а также предоставляет доступ к множеству полезных услуг, дополнительного контента и инструментов. Нашей целью было превратить sgs.com из настольного сайта в адаптивный.

Это представляло собой уникальный набор проблем, особенно в отношении устаревшей навигационной системы, которая в некоторых областях имела глубину до семи уровней (разделенных на две части) и состояла примерно из 12 000 отдельных элементов навигации .

Дополнительная литература на SmashingMag: ссылка

• Разработка тематических исследований: демонстрация процесса проектирования, ориентированного на человека
• Адаптация к адаптивному дизайну
• Кейс по унификации дизайна продукта
• 75 поучительных кейсов — вот как мы это построили

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

Проще говоря, структура дерева навигации должна была оставаться неизменной. Тем не менее, это не помешало нам внести небольшие коррективы в IA. Например, «Новости, СМИ и ресурсы» и «Офисы и лаборатории SGS» были перемещены на верхний уровень для большей наглядности. В первом случае важно было более четко отразить, что SGS регулярно публикует новости и проводит мероприятия. Что касается последнего, было жизненно важно, чтобы он, наряду со страницей контактов, был легко доступен из любой точки структуры веб-сайта. Таким образом, ключевой вопрос заключался в том, как заставить такого гиганта навигационной системы легко переключаться между различными окнами просмотра, оставаясь при этом пригодным для использования?

Установление политик проекта

Здоровые отношения между клиентом и дизайнером необходимы для успеха каждого проекта. Установление четких ожиданий, а также эффективное руководство гарантируют не только то, что основные заинтересованные стороны остаются сосредоточенными на всем протяжении, но и то, что доверие между всеми сторонами развивается по мере продвижения проекта. Это определенно имело место с этим проектом; сотрудничество между всеми сторонами и взаимное признание роли и опыта друг друга были поистине замечательными.

Однако, чтобы все стороны оставались сосредоточенными, на стартовой встрече мы установили ряд важных руководящих принципов и требований, в рамках которых мы также могли проявить творческий подход (на некоторых из них настаивали мы, на других настаивал клиент):

• Контент-паритет . Контент должен быть доступен на всех устройствах и платформах и ни при каких обстоятельствах не должен быть скрыт на мобильных устройствах.
• Производительность . Веб-сайт должен работать как минимум на 20% быстрее, чем конкурирующие веб-сайты. Это было особенно полезно при принятии решения о том, сколько информации должно быть на каждой странице.
• Доступность . Веб-сайт должен соответствовать рекомендациям по доступности уровня AA WCAG 2.0. Нам удалось достичь этой цели, за исключением пограничной проблемы цветового контраста, благодаря брендингу компании.
• Удобство использования . Внутренней команде пришлось всесторонне проверять концепции и проводить личное и удаленное тестирование удобства использования.
• Бесперебойный бизнес . Редизайн никоим образом не должен нарушать работу компании. Понятно, что задача заключалась не в оптимизации сервисов компании, а в оптимизации сайта с учетом налаженных бизнес-процессов. Например, у нас была возможность оптимизировать веб-формы, но структура данных в CRM должна была оставаться неизменной.

Три основные проблемы

С установленными ключевыми рекомендациями и зная, что редизайн навигации не потребует значительного пересмотра IA, мы разделили редизайн на три ключевых, но взаимозависимых набора действий:

• Размещение макета . В основном этим занималась внутренняя команда, а мы предлагали улучшения и следили за тем, чтобы любые решения не имели радикальных последствий для других аспектов нового адаптивного дизайна.
• Взаимодействие и удобство использования . Они были разработаны совместно с командой дизайнеров SGS. Идеи обменивались по электронной почте и на выездных семинарах и регулярно проверялись на соответствие пользователям, заинтересованным сторонам и общим бизнес-требованиям.
• Производительность . Этим вопросом занимались исключительно мы, потому что это была скорее техническая задача и не требовалось принятия каких-либо стратегических решений, кроме того, что нам нужно было быстро сделать новый адаптивный веб-сайт.

Размещение макета

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

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

Принятие решения о концепции

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

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

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

Умное прототипирование

Мы всегда разрабатываем прототипы непосредственно в HTML, CSS и JavaScript, используя семантическую, доступную и надежную разметку, потому что впоследствии мы часто можем повторно использовать первоначальные прототипы позже в процессе проектирования. Это означало, что наш первоначальный прототип новой навигационной системы стал краеугольным камнем для возможного полного прототипа веб-сайта, который включал все шаблоны страниц и модули.

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

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

Взаимодействие и удобство использования

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

Три интерактивные версии

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

Аккордеон

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

Вот плюсы аккордеона:

• Пользователям это знакомо.
• Пользователи могут развернуть все дерево навигации для предварительного просмотра нескольких вариантов (в конце концов, семь уровней навигации могут быть немного сложными).
• Он работает без JavaScript, используя псевдокласс :target .
• Развивать его несложно.

И минусы аккордеона:

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

Слайдер

Изначально это было нашим любимым решением, но оно упускает один важный элемент: позволяет по-настоящему просматривать основные разделы сбоку. Это не было бы такой проблемой, если бы пользователь всегда начинал просмотр с домашней страницы, потому что он лучше знакомился бы с основными разделами. Однако для пользователей, которые попадут на страницу глубоко в дереве навигации, это определенно станет проблемой юзабилити. Например, пользователи, попадающие на третий, четвертый или пятый уровень, должны будут пройти вверх по дереву, чтобы попасть на страницу контактов. Прохождение семи уровней не доставляет удовольствия, независимо от того, насколько мотивирован пользователь.

Плюсы слайдера:

• Иерархия понятна.
• Анимация крутая.
• Он следует мобильным соглашениям.
• Его относительно легко разработать.

Минусы слайдера:

• Просмотр сбоку невозможен.
• Анимация не производительна.

Гибрид (аккордеон и слайдер)

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

Плюсы гибрида:

• Возможен боковой просмотр.
• Анимация крутая.
• Иерархия понятна.

Минусы гибрида:

• Это требует некоторого начального обучения.
• Его сложно разработать, поскольку необходимо учитывать множество движущихся частей.
• У него есть некоторые проблемы с производительностью.

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

Восемь различных типов ссылок

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

• возможность перехода непосредственно на родительскую страницу;
• возможность предварительного просмотра как родительского, так и дочернего уровней, при этом оставаясь на исходном URL-адресе;
• быстро понять свою текущую позицию в браузере, имея возможность изучить навигацию.
• быстро понять свое текущее положение на странице.

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

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

Детали анимации

Все элементы навигации анимированы с помощью CSS, причем каждая анимация состоит из двух отдельных частей:

• горизонтально анимированные уровни,
• вертикально анимированные обертки.

Во-первых, различные уровни дерева в ползунке переключаются путем изменения класса основной оболочки. Например, закрытая оболочка навигации имеет класс .depth-0 . Когда элемент верхнего уровня расширяется, класс изменяется на .depth-1 . Когда выбирается элемент второго уровня из этого элемента верхнего уровня, класс изменяется на .depth-2 и так далее. Это приводит к довольно простому набору правил CSS, которые применяются к одному элементу — самому верхнему упорядоченному списку в ползунке:

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

В приведенном выше примере .l-0 соответствует элементу списка нулевого уровня, а .nav-open переключается всякий раз, когда аккордеон настроен на open . Это означает, что упорядоченный список прямого дочернего элемента в open элементе списка аккордеона абсолютно смещен в отрицательную левую позицию.

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

Для этого мы позаботились о том, чтобы всегда было достаточно места по вертикали для плавной горизонтальной анимации. Высота рассчитывается и применяется «на лету» путем получения вертикального смещения элемента, который должен появиться на экране. Это означает, что нам нужно было учитывать в общей сложности четыре возможных сценария, но на самом деле нужно было решить только два, каждый с немного другим порядком выполнения:

• Элемент из короткого списка в элемент более длинного списка . Горизонтальная и вертикальная анимация запускаются одновременно.
• Длинный элемент списка в более короткий элемент списка . После того, как навигация перестанет скользить по горизонтали, запустится вертикальная анимация.

Обе анимации запускаются одновременно, но вторая анимация запускается с задержкой в ​​300 миллисекунд, которая равна продолжительности первой анимации (задается в CSS с помощью свойства transition-duration ). Причиной этого является неоптимальная производительность анимации на устройствах с меньшими возможностями, когда несколько слоев перекрываются, прежде чем исчезнуть «за кулисами». Упрощенный код выглядит так:

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

Дальнейшие улучшения

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

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

Поскольку все должно было быть очень компактным (поскольку мы должны были использовать абсолютное позиционирование для анимации скольжения), единственным решением было сбросить высоту затронутого элемента после загрузки веб-шрифта. Это было сделано с помощью Web Font Loader, разработанного Bram Stein для Adobe Typekit и Google Fonts.

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

Примечание. Вы заметили, как мы использовали 5-секундный тайм-аут? В нашем тестировании мы обнаружили, что это было приятное место, которое заставило его работать на нашем базовом «хорошем 2G» (450 КБ в секунду) соединении!

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

Наконец, мы добавили код-заполнитель в DOM с помощью JavaScript перед запросом ветки навигации. Это делает DOM максимально чистым.

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

Представление

Если вы помните, одной из наших ключевых задач в проекте было сделать веб-сайт как минимум на 20% лучше, чем сайты конкурентов. Мы не только достигли этой цели, но и помогли SGS значительно уменьшить общий вес страницы и время загрузки. Взгляните на следующую статистику до и после:

Знаете ли вы, что 12 000 ссылок равняются 3 МБ HTML-кода?

Правильно! Когда мы впервые визуализировали полное дерево навигации в нашем прототипе, оно занимало 3 МБ чистого HTML. Ни шапки, ни футера, ни контента — только дерево навигации, состоящее из 12 000 отдельных ссылок.

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

Изучение вариантов повышения производительности

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

Принимая во внимание размер полного дерева навигации (до семи уровней в глубину и 12 000 ссылок для навигации), важно было иметь возможность тестировать части дерева навигации, а также само дерево целиком. Собственные разработчики SGS смогли экспортировать полное дерево навигации в виде CSV-файла из своей системы управления контентом, что позволило нам создать легко настраиваемую функцию PHP для вывода либо полного дерева, либо его части, в зависимости от того, что нам нужно. тестировать.

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

Условная загрузка ссылок

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

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

Во-вторых (и как мы изначально думали), отраслевые ветки вызывали большую часть накладных расходов на производительность. Когда мы полностью убрали отрасли промышленности, размер HTML сократился до 70 КБ, что намного лучше, чем 3 МБ! Тем не менее это означало, что каждая из 14 отраслей промышленности весила от 300 до 500 КБ. Когда мы еще больше фрагментировали каждую ветку службы, мы обнаружили, что каждый последующий уровень будет весить в среднем около 24 КБ.

Хотя мы знали, что HTML можно еще больше сократить, оптимизировав имена классов и добавив узлы DOM с помощью JavaScript (подробнее об этом чуть позже), нам все же нужно было определить, лучше ли инициировать один HTTP-запрос на уровне около 300, чтобы 500 КБ или инициировать HTTP-запрос размером около 24 КБ на каждом уровне. Первоначально казалось, что отправка запроса размером 24 КБ каждый раз, когда пользователь продвигается дальше вниз по дереву навигации, будет более выгодной. Однако это привело бы к отправке нескольких HTTP-запросов по сети, что было далеко не идеально, учитывая, что задержка в сети часто является одним из самых больших узких мест для производительности веб-сайта. Также не имело смысла предсказывать загрузку каких-либо отраслей промышленности, за исключением случаев, когда пользователь демонстрировал намерение, наводя курсор на ссылку отрасли.

Из-за сложности навигации и количества ссылок, следующая схема предлагает лучший компромисс:

• Загрузите первые три уровня по умолчанию в HTML.
• Загружайте отраслевую навигацию с помощью JavaScript, когда отображается намерение, обнаруженное с помощью события mouseover .
• Кэшируйте загруженные ветки, чтобы ускорить загрузку при последовательных загрузках страниц.

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

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

Оптимизация HTML

Если вы действительно хотите оптимизировать свой HTML, все несущественные элементы должны быть выгружены в CSS и JavaScript. Мы тщательно сократили все, кроме упорядоченного списка, его элементов списка и соответствующих им ссылок. Все второстепенные ссылки (например, средства навигации) также были удалены из HTML и снова вставлены в DOM с помощью JavaScript (поскольку без JavaScript они в любом случае неэффективны). Эти необязательные ссылки позволяют пользователю сделать несколько вещей:

• открыть следующий уровень (внутри мы назвали их «расширителями»);
• подняться на уровень выше (мы назвали этих «бэкеров» — показывая отсутствие воображения).

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

Наконец, последняя часть оптимизации, которую мы предприняли, состояла в том, чтобы уменьшить количество классов, а также сократить длину имен классов; например, .very-long-class-name стало .vlcn . Хотя последнее дало наибольший выигрыш, такую ​​оптимизацию трудно оправдать, поскольку она обычно не приводит к значительному уменьшению размера HTML-файла и, что более важно, снижает ясность кода, что, возможно, затрудняет обслуживание. Однако удаление хотя бы одного байта из каждого из 12 000 элементов списка сделало это стоящим упражнением и приемлемым компромиссом.

Результат? Целых 40 КБ или около того исходного HTML (от 8 до 9 КБ при сжатии и передаче по сети) и от 200 до 300 КБ HTML для каждой отрасли (от 15 до 25 КБ при сжатии и передаче).

Заключение: предельная прибыль имеет значение

Нам нравится использовать аналогию из мира спорта: улучшение каждой мелочи на 1% значительно повышает производительность. Это относится к тому, что мы сделали в проекте SGS и его сложной навигации. Сосредоточив внимание на более мелких деталях, немного улучшив каждую деталь, мы значительно упростили навигацию и сократили время загрузки, сохранив при этом привлекательность и привлекательность навигации для пользователей. То, что могло быть кошмаром и крепким орешком, превратилось в технически и интерактивно подходящее решение, достаточно гибкое для дальнейшего улучшения.

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