каркасные

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

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

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

Точность должна соответствовать задаваемому вопросу. На ранних этапах исследования, когда рассматривается несколько направлений, уместны черновые эскизы. Более подробные макеты с реальным контентом, точной иерархией и реалистичными объемами данных уместны после выбора направления, поскольку текст-заполнитель скрывает проблемы, которые выявляет реальный контент: заголовки, которые не помещаются, названия продуктов, которые некорректно переносятся, пустые состояния, которые никто не рассматривал, и списки, которые ведут себя по-разному при наличии трех и трехсот элементов.

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

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

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