From 76f9460d99b65647121bfdb8239118d8854ab642 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=9C=D0=B0=D0=BA=D1=81=D0=B8=D0=BC=20=D0=98=D0=B2=D0=B0?= =?UTF-8?q?=D0=BD=D0=BE=D0=B2?= Date: Tue, 6 Oct 2026 08:13:06 +0300 Subject: [PATCH] docs: expand UI UX fundamentals --- src/pages/ui-ux/index.md | 454 +++++++++++++++++++++++++++++++++++---- 1 file changed, 408 insertions(+), 46 deletions(-) diff --git a/src/pages/ui-ux/index.md b/src/pages/ui-ux/index.md index dfbe6342..5162a589 100644 --- a/src/pages/ui-ux/index.md +++ b/src/pages/ui-ux/index.md @@ -28,9 +28,21 @@ UI, или user interface, это все элементы, через котор **Полный ответ** -UI, или user interface, это все элементы, через которые пользователь взаимодействует с продуктом: кнопки, формы, -таблицы, меню, тексты, иконки и layout. Для frontend-разработчика UI важен как конкретная реализация поведения и -визуального состояния. +UI — это не только внешний вид экрана, а весь слой взаимодействия между человеком и системой. В него входят controls, +navigation, typography, visual hierarchy, feedback, states и правила поведения элементов. + +Например, кнопка — это не просто прямоугольник с текстом. У нее есть accessible name, +default/hover/focus/active/disabled states, loading behavior, reaction на keyboard и touch, а также последствия +действия. + +Frontend-разработчик превращает design specification в работающий UI и поэтому отвечает за то, чтобы интерфейс корректно +вел себя с реальными данными, длинными текстами, ошибками, slow network и разными input methods. + +Важно отличать UI от visual decoration. Красивый gradient или animation может быть частью UI, но качество интерфейса +определяется прежде всего понятностью действия, предсказуемостью состояния и feedback. + +На интервью хороший ответ показывает, что **UI — это реализованный interaction layer продукта, а не только "как экран +выглядит"**. @@ -46,8 +58,25 @@ UX, или user experience, это опыт пользователя при до **Полный ответ** -UX, или user experience, это опыт пользователя при достижении цели в продукте. UX включает понятность сценария, -скорость, ошибки, доверие, доступность и ощущение контроля. +UX описывает весь опыт взаимодействия пользователя с продуктом: насколько легко он понимает, что делать, достигает цели, +восстанавливается после ошибок и доверяет результату. + +Например, у checkout может быть визуально хороший UI, но плохой UX, если пользователь не понимает итоговую цену, теряет +данные после ошибки оплаты или не может вернуться на предыдущий шаг. + +UX складывается из нескольких слоев: + +- полезности: решает ли продукт нужную задачу; +- usability: насколько легко эту задачу выполнить; +- accessibility: может ли интерфейс использовать более широкий круг людей; +- performance и reliability: насколько быстро и стабильно работает сценарий; +- feedback и recovery: понимает ли пользователь состояние системы и следующий шаг. + +UX нельзя оценивать только по вкусу команды. Его проверяют через research, analytics, support feedback, usability tests +и product metrics. + +На интервью полезно подчеркнуть: **UX — это качество пути к цели, а UI является одним из инструментов, через который +этот опыт формируется**. @@ -63,8 +92,24 @@ UI отвечает за интерфейсные элементы и их вн **Полный ответ** -UI отвечает за интерфейсные элементы и их внешний вид. UX шире: он описывает, насколько удобно и успешно пользователь -решает задачу с помощью этих элементов. +UI и UX связаны, но находятся на разных уровнях. + +UI отвечает на вопросы: какие controls используются, как они выглядят, где расположены, какие у них состояния и visual +hierarchy. + +UX отвечает на вопросы: понимает ли пользователь сценарий, может ли завершить его без лишних ошибок, получает ли нужный +feedback и сохраняет ли ощущение контроля. + +Например, форма может иметь аккуратные inputs и красивую кнопку — это хороший UI. Но если validation появляется только +после потери всех данных, submit неожиданно заблокирован, а backend error показывается как код 500, UX остается плохим. + +Обратная ситуация тоже возможна: простой визуально интерфейс может давать отличный UX, если он быстро решает задачу, +предсказуем и не создает лишних решений для пользователя. + +В реальной разработке граница не абсолютна: focus style одновременно относится к UI, accessibility и UX. + +На интервью лучше не сводить отличие к фразе "UI — красиво, UX — удобно". Точнее: **UI — конкретный interaction surface, +UX — результат взаимодействия пользователя со всем сценарием**. @@ -80,8 +125,27 @@ Frontend-разработчик реализует реальные состоя **Полный ответ** -Frontend-разработчик реализует реальные состояния, задержки, ошибки, фокус, валидацию и ограничения браузера. Даже -хороший макет можно испортить плохой обработкой edge cases. +Статичный макет обычно показывает только несколько happy-path состояний. В production появляются real data, network +latency, permissions, empty results, backend errors, keyboard navigation и ограничения devices. + +Именно frontend часто принимает решения вроде: + +- сохранять ли уже загруженные данные во время refresh; +- куда переводить focus после открытия dialog; +- когда показывать validation error; +- блокировать ли повторный submit; +- что делать при частичном failure; +- как вести себя с длинным content и маленьким viewport. + +Эти решения напрямую влияют на UX, даже если visual design не меняется. + +Например, дизайнер может нарисовать spinner на кнопке. Разработчик должен решить, сохраняется ли текст, блокируется ли +повторный click, объявляется ли loading state assistive technologies и что происходит после timeout. + +Понимание UX также помогает раньше находить пробелы в макете и обсуждать их с design/product до реализации. + +На интервью сильный ответ: **frontend не просто "верстает макет", а реализует runtime behavior интерфейса, поэтому часть +UX-качества неизбежно находится в зоне его ответственности**. @@ -97,8 +161,27 @@ Usability показывает, насколько интерфейс понят **Полный ответ** -Usability показывает, насколько интерфейс понятен, эффективен и прост в использовании. Хороший usability означает, что -пользователь может выполнить задачу без лишних догадок и повторных попыток. +Usability — это практическое качество использования интерфейса. Оно связано с тем, насколько успешно, быстро и без +лишнего напряжения человек выполняет конкретную задачу. + +Обычно смотрят на несколько аспектов: + +- learnability: насколько быстро новый пользователь понимает интерфейс; +- efficiency: сколько шагов и времени требуется после обучения; +- errors: как часто происходят ошибки и насколько легко восстановиться; +- memorability: насколько легко вернуться к продукту после перерыва; +- satisfaction: насколько взаимодействие воспринимается понятным и контролируемым. + +Например, форма с десятью понятными полями может иметь лучший usability, чем "минималистичная" форма с пятью полями, +если значения последних невозможно понять без документации. + +Usability всегда зависит от задачи и аудитории. Экспертный trading terminal может быть сложным визуально, но эффективным +для профессионального пользователя. + +Проверять usability лучше через наблюдение за выполнением реальных tasks, а не только через opinion review. + +На интервью: **usability — это не абстрактная "удобность", а измеримое качество выполнения пользователем конкретной +задачи**. @@ -109,13 +192,31 @@ Usability показывает, насколько интерфейс понят **Короткий ответ** -User flow - это последовательность шагов, которые пользователь проходит для достижения цели. Например: открыть форму, +User flow — это последовательность шагов, которые пользователь проходит для достижения цели. Например: открыть форму, заполнить поля, получить ошибку, исправить ее и отправить данные. **Полный ответ** -User flow - это последовательность шагов, которые пользователь проходит для достижения цели. Например: открыть форму, -заполнить поля, получить ошибку, исправить ее и отправить данные. +User flow описывает конкретный путь внутри продукта от starting point до результата. + +Например, flow восстановления пароля может выглядеть так: открыть sign-in → выбрать "забыли пароль" → ввести email → +получить письмо → открыть link → задать новый пароль → вернуться в sign-in. + +Хороший flow учитывает не только happy path, но и branches: + +- email не найден; +- link истек; +- письмо не пришло; +- пользователь уже авторизован; +- password policy не выполнена. + +Для frontend flow полезен тем, что помогает увидеть необходимые screens, states, navigation transitions и data contracts +до того, как код уже связан с одним счастливым сценарием. + +User flow часто изображают как diagram, но сама ценность не в формате, а в явном описании переходов и условий. + +На интервью можно сказать: **flow помогает проверить completeness сценария — какие состояния и переходы должны +существовать, чтобы пользователь действительно дошел до цели**. @@ -131,8 +232,30 @@ User journey описывает более широкий путь пользо **Полный ответ** -User journey описывает более широкий путь пользователя: контекст, ожидания, точки контакта, эмоции и проблемы. User flow -обычно уже и ближе к конкретному экрану. +User journey рассматривает опыт шире одного интерфейсного сценария. Он включает момент до входа в продукт, разные touch +points и то, что происходит после выполнения действия. + +Например, journey оформления кредита может включать рекламу, landing page, форму заявки, ожидание решения, email/SMS, +подписание документов и обращение в support. + +В journey обычно фиксируют: + +- цель пользователя; +- этапы пути; +- touch points и channels; +- ожидания; +- pain points; +- вопросы и эмоции; +- opportunities для улучшения. + +User flow может быть частью journey. Flow показывает "какие шаги в интерфейсе", а journey помогает понять "в каком +контексте и зачем человек проходит эти шаги". + +Для frontend это полезно, когда локально оптимальное решение создает проблему дальше. Например, скрыть статус заявки +после submit может упростить экран, но увеличить число обращений в support. + +На интервью: **user journey связывает интерфейс с полным пользовательским контекстом, тогда как user flow обычно +описывает конкретную последовательность действий в продукте**. @@ -143,13 +266,31 @@ User journey описывает более широкий путь пользо **Короткий ответ** -Wireframe - это черновая схема экрана без детальной визуальной стилистики. Он помогает договориться о структуре, +Wireframe — это черновая схема экрана без детальной визуальной стилистики. Он помогает договориться о структуре, приоритетах и сценарии до дорогой проработки деталей. **Полный ответ** -Wireframe - это черновая схема экрана без детальной визуальной стилистики. Он помогает договориться о структуре, -приоритетах и сценарии до дорогой проработки деталей. +Wireframe показывает информационную архитектуру и расположение ключевых элементов без попытки закончить visual design. + +Обычно в нем видны navigation, content blocks, forms, actions и примерная hierarchy, но нет финальных colors, +typography, icons и polish. + +Главная польза wireframe — дешево проверять структуру. На этом этапе проще спросить: + +- видно ли главное действие; +- хватает ли места для реальных данных; +- не перегружен ли экран; +- понятна ли последовательность шагов; +- есть ли необходимые secondary actions. + +Wireframe не должен создавать ложное ощущение готового interface contract. Например, серый прямоугольник "table" еще не +описывает loading, empty, pagination, error и responsive behavior. + +Для frontend-разработчика review wireframe полезен именно как ранняя возможность заметить технические и UX-риски. + +На интервью: **wireframe — low-fidelity инструмент для проверки структуры и flow до того, как команда инвестирует время +в визуальные детали и реализацию**. @@ -160,13 +301,32 @@ Wireframe - это черновая схема экрана без деталь **Короткий ответ** -Prototype - это интерактивная или частично интерактивная модель интерфейса. Он нужен, чтобы проверить сценарий, переходы +Prototype — это интерактивная или частично интерактивная модель интерфейса. Он нужен, чтобы проверить сценарий, переходы и ожидания пользователя до полноценной разработки. **Полный ответ** -Prototype - это интерактивная или частично интерактивная модель интерфейса. Он нужен, чтобы проверить сценарий, переходы -и ожидания пользователя до полноценной разработки. +Prototype имитирует взаимодействие с будущим продуктом. Он может быть простым clickable prototype в design tool или +почти рабочим техническим spike. + +Главная цель — проверить риск до production implementation: + +- понимает ли пользователь следующий шаг; +- хватает ли feedback; +- логична ли navigation; +- нужен ли дополнительный screen; +- как воспринимается сложная interaction. + +Важно не путать prototype с production-ready specification. В prototype часто отсутствуют accessibility, real network, +error handling, responsive behavior и настоящие data constraints. + +Есть и технические prototypes: разработчик может быстро проверить сложный drag-and-drop, virtual scroll или browser API, +чтобы понять feasibility. Такой prototype отвечает на технический вопрос, а не обязательно на UX-гипотезу. + +Перед разработкой полезно явно договориться, что именно prototype проверяет и что считается disposable. + +На интервью: **prototype снижает стоимость ошибки, потому что позволяет проверить interaction или feasibility до +полноценной реализации**. @@ -182,8 +342,22 @@ Layout отвечает за расположение элементов, иер **Полный ответ** -Layout отвечает за расположение элементов, иерархию и адаптивность. Visual design добавляет цвет, типографику, стиль, -иконки, иллюстрации и визуальный характер продукта. +Layout определяет spatial structure: какие блоки существуют, как они связаны, в каком порядке читаются, как распределяют +место и что происходит на разных размерах container. + +Visual design работает поверх этой структуры и формирует визуальный язык: colors, typography, elevation, icons, +illustrations, borders и brand expression. + +Например, две формы могут использовать одинаковый layout "label → field → helper text", но выглядеть совершенно +по-разному из-за typography и color system. + +Разделение полезно при разработке. Проблема responsive overflow — прежде всего layout issue. Низкий contrast текста — +visual/accessibility issue. Но слои связаны: visual weight влияет на hierarchy, а typography меняет реальные размеры. + +В design system layout primitives и visual tokens часто эволюционируют независимо, что уменьшает связанность решений. + +На интервью: **layout отвечает за структуру и пространственные отношения, visual design — за визуальное выражение этой +структуры; хороший UI требует согласованности обоих слоев**. @@ -199,8 +373,25 @@ Layout отвечает за расположение элементов, иер **Полный ответ** -Красивый экран может быть непонятным, медленным или плохо работать с ошибками. UX оценивается не только по внешнему -виду, а по тому, помогает ли интерфейс пользователю успешно выполнить задачу. +Visual quality влияет на доверие и восприятие продукта, но не гарантирует task success. + +Например, минималистичный form может выглядеть чисто, если labels заменены placeholders. После ввода пользователь теряет +контекст полей, а при validation становится сложнее понять ошибку. Визуально экран "легче", но usability хуже. + +Другие типичные ситуации: + +- animation выглядит эффектно, но задерживает frequent action; +- low-contrast typography выглядит "легко", но плохо читается; +- icon-only controls экономят место, но неочевидны; +- нестандартная navigation выглядит оригинально, но ломает ожидания пользователя. + +Хороший дизайн балансирует aesthetics с clarity, performance, accessibility и predictability. + +Это не означает, что visual polish неважен. Он помогает hierarchy, brand recognition и perceived quality. Проблема +возникает, когда декоративная цель начинает мешать пользовательской. + +На интервью: **красота — один из факторов UX, но она не должна подменять понятность, доступность и успешное выполнение +задачи**. @@ -216,8 +407,26 @@ Layout отвечает за расположение элементов, иер **Полный ответ** -Пользователи ошибаются, отвлекаются, вводят неполные данные и нажимают не туда. Хороший интерфейс предотвращает дорогие -ошибки, объясняет проблему и дает понятный следующий шаг. +Ошибки — нормальная часть interaction, а не исключительный случай. UX должен учитывать slips, misunderstanding, +incomplete input и неверные assumptions. + +Есть три уровня работы с ошибкой: + +1. предотвратить ее, если цена ошибки высока; +2. быстро обнаружить и понятно объяснить; +3. дать recovery path без потери лишней работы. + +Например, при удалении важной сущности можно показать конкретное название объекта и последствия. Для обратимого действия +лучше иногда дать undo, чем постоянно спрашивать confirmation. + +В формах полезно сохранять введенные данные после backend failure. В destructive flow важно не делать safe и dangerous +actions визуально неразличимыми. + +При этом чрезмерная защита тоже ухудшает UX: confirmation на каждое безопасное действие создает dialog fatigue, и +пользователь начинает подтверждать автоматически. + +На интервью: **хороший interface design не предполагает идеального пользователя; он снижает вероятность ошибки и +стоимость восстановления, не превращая продукт в цепочку лишних блокировок**. @@ -233,8 +442,29 @@ Layout отвечает за расположение элементов, иер **Полный ответ** -Разработчик решает, как работают loading, empty, error, focus, keyboard navigation, адаптивность и реальные данные. -Именно в коде часто появляются сценарии, которых не было в статичном макете. +Макет задает intent, но runtime behavior появляется только в implementation. + +Frontend принимает множество UX-решений: + +- когда начинается и заканчивается loading; +- сохраняются ли предыдущие данные при refresh; +- куда идет focus после navigation или dialog; +- как компонент работает с keyboard; +- что происходит на slow API и offline; +- как длинный текст влияет на layout; +- как UI реагирует на permissions и partial data. + +Например, два разработчика могут одинаково сверстать table из макета. Один при refresh заменит все spinner и сбросит +scroll position, второй сохранит rows и покажет unobtrusive progress. Визуальная specification одинаковая, опыт — +разный. + +Поэтому зрелый frontend review должен включать не только pixel matching, но и behavior, states и accessibility. + +Если решение влияет на product logic или заметно меняет сценарий, его лучше согласовать с designer/product, а не молча +додумывать. + +На интервью: **frontend влияет на UX через поведение во времени и в edge cases — то, чего статичная картинка часто не +описывает**. @@ -250,8 +480,26 @@ Layout отвечает за расположение элементов, иер **Полный ответ** -Без цели легко оптимизировать второстепенные детали и усложнить основной сценарий. Понимание цели помогает выбирать -правильные состояния, приоритеты и ограничения. +Экран — не цель сам по себе. Он существует, чтобы помочь пользователю выполнить задачу. + +Если команда не понимает эту задачу, она может улучшать локальные детали, которые не помогают результату. Например, +dashboard можно заполнить красивыми metrics, хотя основной пользователь заходит только проверить один критичный status и +быстро принять решение. + +Понимание цели помогает определить: + +- какое действие primary; +- какая информация нужна до решения; +- что можно скрыть как secondary; +- какие ошибки особенно опасны; +- какой feedback нужен после действия; +- что считать успешным UX. + +Это также помогает разрешать design/technical trade-offs. Если дорогая animation не влияет на user goal, ее проще +сократить. Если сложный validation предотвращает финансовую ошибку, дополнительная стоимость может быть оправдана. + +На интервью полезно показать product thinking: **сначала цель и критерий успеха, затем конкретный UI; иначе команда +легко оптимизирует экран вместо пользовательской задачи**. @@ -262,13 +510,32 @@ Layout отвечает за расположение элементов, иер **Короткий ответ** -Cognitive load - это умственное усилие, которое нужно пользователю для понимания интерфейса и принятия решения. Чем +Cognitive load — это умственное усилие, которое нужно пользователю для понимания интерфейса и принятия решения. Чем больше лишних вариантов, нестандартных паттернов и неясных текстов, тем выше нагрузка. **Полный ответ** -Cognitive load - это умственное усилие, которое нужно пользователю для понимания интерфейса и принятия решения. Чем -больше лишних вариантов, нестандартных паттернов и неясных текстов, тем выше нагрузка. +Cognitive load растет, когда пользователю приходится держать слишком много информации в памяти, разбираться в +непредсказуемых controls или выбирать между множеством похожих options. + +Примеры: + +- форма требует помнить формат значения с предыдущего экрана; +- одинаковое действие на разных страницах называется по-разному; +- dashboard одновременно показывает двадцать равнозначных metrics; +- navigation использует нестандартные icons без labels. + +Снижать нагрузку помогают familiar patterns, grouping, visual hierarchy, sensible defaults, progressive disclosure и +понятный microcopy. + +При этом минимальное количество элементов не всегда означает минимальную cognitive load. Если скрыть важные actions в +неочевидное меню, экран станет визуально чище, но пользователю придется больше искать и запоминать. + +Есть и domain complexity: сложную финансовую или инженерную задачу нельзя всегда "сделать простой", но можно не +добавлять к ней лишнюю interface complexity. + +На интервью: **цель не убрать всю сложность, а не заставлять пользователя тратить внимание на то, что интерфейс может +объяснить, запомнить или организовать сам**. @@ -284,8 +551,29 @@ Cognitive load - это умственное усилие, которое нуж **Полный ответ** -Нужно группировать связанные элементы, показывать главное первым, скрывать редкие настройки до момента необходимости и -использовать понятные подписи. Важно убрать дублирующиеся действия и визуальный шум. +Сначала нужно понять, какая информация и действия нужны для основной задачи. После этого интерфейс можно организовать по +приоритету, а не просто "уменьшать количество элементов". + +Рабочие приемы: + +- группировать поля и metrics по смыслу; +- использовать hierarchy и headings; +- давать sensible defaults; +- применять progressive disclosure для редких настроек; +- показывать contextual help рядом с местом решения; +- сохранять consistent terminology; +- не заставлять пользователя переносить данные между экранами вручную. + +Для dashboard полезно отделять overview от drill-down. Для формы — не спрашивать данные, которые система уже знает, и не +разбивать простой сценарий на лишние steps. + +Важно не спрятать essential information ради визуальной чистоты. Если пользователь постоянно открывает "advanced" +section, возможно, она не advanced для этой аудитории. + +Эффект лучше проверять через task completion, errors и наблюдение за пользователями. + +На интервью: **уменьшение cognitive load — это управление приоритетами и информационной архитектурой, а не механическое +сокращение числа controls**. @@ -301,8 +589,26 @@ Consistency снижает необходимость заново учитьс **Полный ответ** -Consistency снижает необходимость заново учиться каждому экрану. Если одинаковые действия выглядят и называются -одинаково, пользователь быстрее строит правильную модель продукта. +Consistency позволяет переносить уже выученные expectations между экранами. + +Если primary action имеет одинаковый visual role, формы одинаково показывают errors, а navigation следует знакомой +структуре, пользователю не нужно каждый раз заново разбираться в правилах. + +Consistency бывает нескольких типов: + +- visual: tokens, typography, spacing, states; +- behavioral: одинаковые controls ведут себя одинаково; +- terminology: одно понятие называется одинаково; +- platform consistency: продукт уважает browser/OS conventions. + +Нарушения особенно опасны, когда элементы выглядят одинаково, но ведут себя по-разному. Например, один и тот же icon в +разных местах не должен означать "закрыть" и "удалить". + +Но consistency не является абсолютной целью. Если context или risk существенно отличается, интерфейс может специально +выделять действие. + +На интервью: **consistency уменьшает learning cost и число surprises; design system помогает поддерживать ее на уровне +компонентов, но продуктовая семантика должна оставаться согласованной тоже**. @@ -318,8 +624,28 @@ Design system дает повторяемые компоненты, состоя **Полный ответ** -Design system дает повторяемые компоненты, состояния, правила контраста, отступы и тексты. Это ускоряет разработку и -делает интерфейс более предсказуемым для пользователя. +Design system превращает повторяющиеся UI-решения в общий contract между design и development. + +Если Button, Input, Dialog и Table уже имеют согласованные states, accessibility behavior и tokens, продуктовые команды +меньше изобретают локальные варианты. Пользователь получает более предсказуемый интерфейс. + +Для UX особенно важны не только компоненты, но и patterns: + +- validation и error presentation; +- loading/empty states; +- confirmation и destructive actions; +- focus management; +- responsive behavior; +- terminology и microcopy. + +Design system также уменьшает вероятность regressions: исправление focus style или contrast в базовом component может +улучшить сразу много screens. + +Но система может и навредить, если команда использует component только потому, что он существует. Product context важнее +слепого reuse. Иногда нужен новый pattern или изменение API системы. + +На интервью: **design system масштабирует проверенные UX-решения, но не заменяет product thinking; она должна давать +consistency и quality baseline, а не ограничивать любой новый сценарий**. @@ -335,8 +661,26 @@ Design system дает повторяемые компоненты, состоя **Полный ответ** -Когда сценарий действительно другой по риску, частоте или последствиям. Например, destructive action может отличаться -визуально, чтобы пользователь заметил опасное действие. +Consistency полезна, пока одинаковая форма означает одинаковую семантику. Если смысл или риск действия отличается, +визуальное и поведенческое отличие может быть правильным. + +Примеры: + +- irreversible delete можно визуально отделить от обычного primary action; +- критичный security warning требует более сильного attention pattern; +- редкий expert workflow может использовать более плотный UI, чем consumer flow; +- emergency action может быть доступнее, чем обычный secondary control. + +Главное — не нарушать consistency ради novelty. Новое поведение создает learning cost и требует объяснения. + +Хороший критерий: пользователь должен понимать, почему элемент отличается. Если различие существует только потому, что +"на этом экране дизайнер решил иначе", это скорее inconsistency debt. + +При изменении общего pattern полезно проверить, не стоит ли обновить design system для всех похожих случаев вместо +локального исключения. + +На интервью: **consistency можно нарушать осознанно, когда различается семантика или риск; отличие должно помогать +пониманию, а не быть декоративным исключением**. @@ -347,13 +691,31 @@ Design system дает повторяемые компоненты, состоя **Короткий ответ** -Появляется много пояснений, исключений, скрытых зависимостей и вопросов от пользователей. Еще один сигнал - команда не +Появляется много пояснений, исключений, скрытых зависимостей и вопросов от пользователей. Еще один сигнал — команда не может коротко объяснить основной сценарий. **Полный ответ** -Появляется много пояснений, исключений, скрытых зависимостей и вопросов от пользователей. Еще один сигнал - команда не -может коротко объяснить основной сценарий. +Избыточная сложность обычно проявляется не одним признаком, а набором симптомов. + +Например: + +- основной action трудно найти; +- один и тот же результат можно получить несколькими непонятно чем отличающимися путями; +- UI требует длинных инструкций; +- states зависят от скрытых условий; +- support постоянно объясняет одинаковые вещи; +- пользователи часто возвращаются назад или бросают flow; +- разработчики боятся менять компонент из-за большого числа special cases. + +Полезно отделять essential domain complexity от accidental UI complexity. Например, payroll calculation может быть +объективно сложным, но интерфейс не должен добавлять к нему неясную navigation или разные названия одной сущности. + +Проверять проблему можно через usability sessions, analytics, support tickets и code complexity вместе. Иногда сложный +UI отражается и в сложном state model frontend. + +На интервью хороший ответ: **если интерфейс трудно объяснить, трудно предсказать и пользователю постоянно нужна внешняя +помощь, стоит пересмотреть information architecture и сам сценарий, а не добавлять еще один tooltip**.