Требования ACID на простом языке
Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.
Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.
Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?
Давайте пройдемся по каждой букве ACID и посмотрим на примерах, чем архив лучше 10 разных файлов. И чем транзакция лучше 10 отдельных запросов.
Atomicity — Атомарность
Атомарность гарантирует, что каждая транзакция будет выполнена полностью или не будет выполнена совсем. Не допускаются промежуточные состояния.
Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.
Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:
У вас деньги списались
И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:
1. У вас на балансе нет нужной суммы — система вывела сообщение об ошибке, но катастрофы не произошло, атомарность тут не нужна.
2. У мамы заблокирована карточка, истек срок годности — деньги ей не поступили. Запрос отменен. Но минуточку. У вас то они уже списались!
Ошибка на первом этапе никаких проблем в себе не таит. А вот ошибка на втором. Приводит к потере денег, что явно недопустимо.
Если мы отправляем отдельные запросы, система не может связать их между собой. Запрос упал с ошибкой? Система его отменяет. Но только его, ведь она не знает о том, что запрос «у меня деньги спиши» связан с упавшим «сюда положи»!
Транзакция же позволяет сгруппировать запросы, то есть фактически показывает базе на взаимосвязи между ними. База сама о связях ничего не знает! Это знаете только вы =)
И если падает запрос внутри транзакции, база откатывает всю транзакцию. И приходит в состояние «как было до начала транзакции». Даже если там внутри было 10 запросов, вы можете спать спокойно — сломался один, откатятся все.
Consistency — Согласованность
Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты wikipedia
Это свойство вытекает из предыдущего. Благодаря тому, что транзакция не допускает промежуточных результатов, база остается консистентной. Есть такое определение транзакции: «Упорядоченное множество операций, переводящих базу данных из одного согласованного состояния в другое». То есть до выполнения операции и после база остается консистентной (в переводе на русский — согласованной).
Например, пользователь в системе заполняет карточку:
Телефон — отдельно код страны, города и номер
Консистентность и ACID-гарантии в распределенных системах хранения данных
Распределенные системы используют, когда возникает необходимость в горизонтальном масштабировании, чтобы обеспечить повышенные показатели производительности, которые не способна обеспечить за адекватные деньги вертикально масштабированная система.
Как и переход с однопоточной парадигмы на многопоточную, миграция на распределенную систему требует своего рода погружения и понимания того, как это работает внутри, на что нужно обращать внимание.
Одна из проблем, которая встает перед человеком, который хочет мигрировать проект на распределенную систему или начать на ней проект, — какой продукт выбрать.
Мы, как компания, которая «собаку сьела» в разработке систем такого рода, помогаем нашим клиентам взвешенно принимать такие решения применительно к распределенным системам хранения. Также мы выпускаем серию вебинаров для более широкой аудитории, которые посвящены базовым принципам, рассказанным простым языком, и безотносительно каких-то конкретных продуктовых предпочтений помогают составить карту значимых характеристик, чтобы облегчить выбор.
Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.
Что это такое и зачем это нужно?
«Согласованность данных (иногда консистентность данных, англ. data consistency) — согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.» (Wikipedia)
Согласованность подразумевает, что в любой момент времени приложения могут быть уверены, что работают с корректной, технически актуальной версией данных, и могут расчитывать на нее при принятии решений.
В распределенных системах обеспечивать согласованность становится сложнее и дороже, потому что появляется целый ряд новых вызовов, связанных с сетевым обменом между различными узлами, возможностью отказа отдельных узлов и — зачастую — отсутствием единой памяти, которая может служить для верификации.
Например, если у меня есть система из 4 узлов: A, B, C и D, которая обслуживает банковские транзакции, и узлы C и D отделились от A и B (скажем, из-за сетевых проблем), вполне возможно, я теперь не имею доступа к части транзакций. Как мне действовать в этой ситуации? Разные системы принимают разные подходы.
На верхнем уровне есть 2 ключевых направления, которые выражены в CAP-теореме.
«Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:
Когда CAP-теорема говорит о консистентности, она подразумевает достаточно строгое определение, включающее линеаризацию записей и чтений, и оговаривает только консистетность при записи отдельных значений. (Martin Kleppman)
CAP-теорема говорит о том, что если мы хотим быть устойчивы к сетевым проблемам, то мы в целом должны выбрать, чем жертвовать: консистентностью или доступностью. Есть также расширенная версия этой теоремы — PACELC (Wikipedia), которая дополнительно рассказывает о том, что даже в отсутствии сетевых проблем мы должны выбирать между скоростью отклика и консистетностью.
И хотя, на первый взгляд выходца из мира классических СУБД, кажется, что выбор очевиден, и консистетность — самое главное, что у нас есть, это далеко не всегда так, что ярко иллюстрирует взрывной рост целого ряда NoSQL СУБД, которые сделали другой выбор и, несмотря на это, получили огромную пользовательскую базу. Apache Cassandra с ее знаменитой eventual consistency является хорошим примером.
Все из-за того, что это выбор, который подразумевает, что мы чем-то жертвуем, и далеко не всегда мы этим жертвовать готовы.
Часто проблема консистентности в распределенных системах решается просто отказом от этой консистентности.
Но нужно и важно понимать, когда отказ от этой консистентности допустим, а когда она является бизнес-критичным требованием.
Например, если я проектирую компонент, который отвечает за хранение пользовательских сессий, здесь мне, скорее всего, консистентность не так важна, да и потеря данных некритична, если она происходит только в проблемных случаях — очень редко. Худшее, что случится, — пользователю нужно будет перелогиниться, и для многих бизнесов это практически никак не повлияет на их финансовые показатели.
Если я делаю аналитику на потоке данных с датчиков, во многих случаях мне совсем некритично потерять часть данных и получить на небольшом промежутке времени пониженную дискретизацию, особенно, если «eventually» данные я все-таки увижу.
Но если я делаю банковскую систему, консистентность денежных проводок критична для моего бизнеса. Если я начислил пеню на кредит клиента из-за того, что просто не увидел в срок внесенный платеж, хотя он был в системе — это очень-очень плохо. Как и если клиент может несколько раз снять все деньги с моей кредитной карты, потому что у меня в момент проведения транзакции возникли сетевые проблемы, и на часть моего кластера информация о снятии не дошла.
Если вы оформляете дорогостоящую покупку в интернет-магазине, вы не хотите, чтобы о вашем заказе забыли, несмотря на рапортующую об успехе веб-страницу.
Но если вы делаете выбор в пользу консистентности, вы жертвуете доступностью. И зачастую это ожидается, скорее всего, вы не раз сталкивались с этим лично.
Лучше, если корзина интернет-магазина скажет «попробуйте позднее, распределенная СУБД недоступна», чем если отрапортует об успехе и забудет заказ. Лучше получить отказ в транзакции из-за недоступности сервисов банка, чем отбивку об успехе и потом разбирательства с банком из-за того, что он забыл, что вы внесли платеж по кредиту.
Наконец, если мы смотрим на расширенную, PACELC теорему, то мы понимаем, что даже в случае штатной работы системы, выбирая консистентность, мы можем жертвовать низкими задержками, получая потенциально более низкий уровень максимальной производительности.
Поэтому, отвечая на вопрос «зачем это нужно?»: это нужно, если для вашей задачи критично иметь актуальные, целостные данные, и альтернатива принесет вам существенные потери, большие, чем временная недоступность сервиса на период инцидента или его более низкая производительность.
Как это обеспечить?
Соответственно, первое решение, которое вам нужно принять — где вы находитесь в CAP-теореме, вы хотите консистентность или доступность в случае инцидента.
Далее нужно понять, на каком уровне вы хотите проводить изменения. Возможно, вам хватит обычных атомарных записей, затрагивающих единственный объект, как умела и умеет MongoDB (сейчас она расширяет это дополнительно поддержкой полноценных транзакций). Напомню, что CAP-теорема ничего не говорит о консистентности операций записи, затрагивающих множественные объекты: система вполне может быть CP (т.е. предпочитать консистентность доступности) и при этом предоставлять только атомарные одиночные записи.
Если вам этого не хватает, мы начинаем подходить к концепции полноценных распределенных ACID-транзакций.
Замечу, что даже переходя в дивный новый мир распределенных ACID-транзакций, мы зачастую вынуждены чем-то жертвовать. Так например, ряд распределенных систем хранения имеет распределенные транзакции, но только в рамках одной партиции. Или, например, система может не поддерживать «I»-часть на нужном вам уровне, не имея изоляции, либо имея недостаточное количество уровней изоляции.
Эти ограничения зачастую были сделаны по какой-то причине: либо для упрощения реализации, либо, например, для повышения производительности, либо для чего-то еще. Они достаточны для большого количества кейсов, поэтому не стоит рассматривать их как минусы сами по себе.
Нужно понять, являются ли эти ограничения проблемой для вашего конкретного сценария. Если нет, — у вас есть более широкий выбор, и вы можете больший вес дать, например, показателям производительности или способности системы обеспечивать катастрофоустойчивость и т.д. Наконец, нужно не забывать, что у ряда систем эти параметры могут настраиваться вплоть до того, что система может быть CP или AP в зависимости от конфигурации.
Если наш продукт стремится быть CP, то обычно у него есть либо кворумный подход к выбору данных, либо выделенные узлы, которые являются основными владельцами записей, через них проходят все изменения данных, и в случае сетевых проблем, если эти мастер-узлы не могут дать ответ, считается, что данные в принципе, невозможно получить, либо арбитраж, когда внешний высокодоступный компонент (например, кластер ZooKeeper) может говорить, какой из сегментов кластера является основным, содержит актуальную версию данных и может эффективно обслуживать запросы.
Наконец, если нас интересует не просто CP, но поддержка полноценных распределенных ACID-транзакций, то зачастую или используется все же единый источник истины, например, централизованное дисковое хранилище, где наши узлы, по сути, выступают лишь кешами к нему, которые можно инвалидировать в момент коммита, или применяется протокол многофазового коммита.
Первый подход с единым диском также упрощает реализацию, дает низкие задержки на распределенных транзакциях, но торгует взамен очень ограниченной масштабируемостью на нагрузках с большими объемами записи.
Второй подход дает намного больше свободы в масштабировании, и, в свою очередь, делится на двухфазный (Wikipedia) и трехфазный (Wikipedia) протоколы коммита.
Рассмотрим на примере двухфазного коммита, который использует, например, Apache Ignite.

Процедура коммита делится на 2 фазы: prepare и commit.
На фазе prepare рассылается сообщение о подготовке к коммиту, и каждый участник при необходимости делает блокировку, выполняет все операции вплоть до фактического commit не включительно, рассылает prepare на свои реплики, если это предполагается продуктом. Если хотя бы один из участников ответил по какой-то причине отказом или оказался недоступен — данные фактически не поменялись, коммита не было. Участники откатывают изменения, снимают блокировки и возвращаются на исходное состояние.
На фазе commit отправляется фактическое выполнение commit на узлах кластера. Если по какой-то причине часть узлов была недоступна или ответила ошибкой, то к этому времени данные занесены в их redo-лог (поскольку prepare был выполнен успешно), и коммит в любом случае может быть завершен хотя бы в отложенном состоянии.
Наконец, если отказывает координатор, то на prepare-этапе коммит будет отменен, на commit-этапе может быть выбран новый координатор, и, если все узлы выполнили prepare, он может проверить и обеспечить выполнение этапа commit.
Разные продукты имеют свои особенности реализации и оптимизации. Так, например, некоторые продукты умеют в отдельных случаях сводить 2-х фазный коммит к 1-фазному, значительно выигрывая по производительности.
Выводы
Ключевой вывод: распределенные системы хранения данных — это достаточно развитый рынок, и продукты на нем могут обеспечивать высокую консистентность данных.
При этом продукты этой категории находятся на разных точках шкалы консистентности, от полностью AP-продуктов без какой-либо транзкционности, до CP-продуктов, которые дополнительно дают еще и полноценные ACID-транзакции. Часть продуктов может быть настроена в одну или в другую сторону.
Когда вы выбираете, что нужно вам, нужно учитывать потребности вашего кейса и хорошо понимать, на какие жертвы и компромиссы вы готовы пойти, потому что ничего не бывает бесплатно, и выбирая одно, вы, скорее всего, откажетесь от чего-то другого.
Оценивая продукты с этой стороны, стоит обращать внимание на то:
Консистентность в дизайне
Пользовательский опыт: понимание единообразия дизайна
Приглашаем вас прочитать, что такое консистентность дизайна, почему это важно, какие типы согласованности существуют и как ее достичь в разрабатываемом вами приложении или веб-сайте.
Ошеломленные суетой современного мира и невероятным количеством информации вокруг, люди склонны выбирать простоту, иногда даже не задумываясь об этом выборе. Чтобы снизить когнитивную нагрузку, пользователи ищут ярлыки, шаблоны и модели, которые делают взаимодействие с цифровым миром и многочисленными каналами коммуникации простым и легким. В дизайне одним из факторов, поддерживающих эту цель, является консистентность, и это тема, которую мы обсудим в нашей сегодняшней статье и продемонстрируем на проектах, которые мы реализовали здесь, в Tubik.
Что такое консистентность
Одно из определений, которое Кембриджский словарь английского языка дает термину «консистентность», — это качество всегда вести себя или действовать одинаково, то есть «быть одинаковым, последовательным, согласованным». И это, пожалуй, самое простое определение. Это означает, что продукт общается с пользователем одинаковым или похожим образом, независимо от точки или канала связи. С точки зрения пользовательского опыта это означает, что похожие элементы выглядят и функционируют одинаково, что снижает когнитивную нагрузку и делает взаимодействие интуитивно понятным.
Учитывая то, что сегодня люди перегружены информацией, они склонны выбирать продукты, которые легко понять и с которыми легко взаимодействовать. Более того, последовательность создает надежную основу для ощущения гармонии как во внешнем виде продукта, так и в том, как он работает. А гармония – всегда желанная часть любого опыта, который у нас есть. Последовательность делает пользовательские интерфейсы предсказуемыми и обучаемыми, в то время как бренды получают за счет этого солидную и единую презентацию и производительность.
Консистентность — это одна из 10 фундаментальных эвристик юзабилити, которые являются основными принципами проектирования взаимодействия, определенными Якобом Нильсеном еще в 1994 году. Консистентность в этом списке основана на том принципе, что пользователям не нужно задаваться вопросом, означают ли разные слова, ситуации или действия то же самое.
Почему важна консистентность дизайна
Короче говоря, последовательный подход к дизайну пользовательского опыта дает следующие преимущества:
Таким образом, согласованность объединяет различные элементы пользовательского интерфейса в систему предсказуемых и понятных взаимодействий. Собственно, это то, что мы делаем и в физическом мире, чтобы упростить нашу повседневную жизнь и избежать необходимости снова и снова сосредотачиваться на одних и тех же операциях. Например, все мы храним посуду на кухне, поэтому, даже придя к кому-то в первый раз, вы не будете пытаться искать чашку и ложку в ванной, потому что это известная закономерность, которой следует большинство людей.
Типы консистентности
С точки зрения факторов воздействия консистентность может быть визуальной и функциональной.
Визуальная консистентность основана на том, чтобы похожие объекты или элементы выглядели одинаково. Очень важно сделать четкие связи между элементами и построить прочную визуальную иерархию. Речь идет о значках, шрифтах, размерах изображений, кнопках, ярлыках и других важных вещах. Например, когда вы систематизируете статью, все типы текстовых элементов (заголовок, подзаголовки, основная часть текста, цитаты и т. д.) должны использовать одну и ту же систему типографского представления, чтобы их можно было визуально сканировать. Если вы создаете блог или медиа с несколькими типами сообщений, они должны придерживаться одинаковой системы визуального представления, чтобы их можно было воспринимать как одну целую публикацию, а не как беспорядок из случайных сообщений.
Функциональная консистентность означает, что похожие объекты ведут себя одинаково. Например, большинство веб-сайтов используют логотип или название публикации в верхнем левом углу заголовка веб-сайта, и, щелкнув его, пользователи вернутся на главную страницу или обновят ее. Большинство пользователей привыкли к этому шаблону и ожидают, что он будет работать именно так, даже на веб-сайтах, которые они посещают впервые.
С точки зрения связей и масштаба консистентность может быть внутренней и внешней.
Внутренняя консистентность — это разные части вашего интерфейса или бренда, которые выглядят и ведут себя как одна четкая система. Например, если вы сделаете все кнопки CTA на разных страницах или экранах вашего продукта окрашенными и оформленными одинаково, пользователи смогут быстро различать их на любом этапе своего пользовательского пути.
Внешняя консистентность — это части вашего интерфейса, которые выглядят и ведут себя как типичные шаблоны для большинства продуктов такого типа. Это, например, когда вы используете корзину покупок даже на веб-сайте, где продаются нематериальные товары, или подчеркиваете текстовые ссылки, чтобы дать пользователям понять, что на них можно нажать.
Как сделать дизайн консистентным
Вот список из 7 пунктов, которые вам лучше рассмотреть, если вы стремитесь достичь единообразия в дизайне своего веб-сайта или мобильного приложения.
1. Реализуйте узнаваемые шаблоны.
Существует множество моделей поведения и привычек, которые у пользователей уже есть до того, как они увидят ваше приложение или сайт. Этот набор знаний основан на их предыдущем опыте и, в зависимости от подхода дизайнеров, может помочь или испортить пользовательский опыт.
Например, еще до появления популярности цифровых продуктов для статистики и графиков большинство пользователей ассоциировали красный цвет с отрицательным балансом или уменьшением, а зеленый – с положительным балансом или увеличением. Используя этот шаблон, известный миллионам людей разных возрастов и национальностей, вы поддерживаете внешнюю согласованность продукта и упрощаете понимание визуализации данных. Кроме того, окрашивание кнопки принятия входящего вызова в зеленый цвет и отклонение вызова в красный снижает когнитивную нагрузку на пользователей, поскольку они привыкли к такой модели и им не нужно думать, какую кнопку нажать.
Кроме того, этот момент может иметь дело с внутренней согласованностью, и это особенно важно для сложных продуктов с большим количеством экранов и взаимодействий. Когда вы привлекаете пользователей, обучаете их работе с интерфейсом и используете однообразный набор взаимодействий с одной страницы на другую, им не нужно думать о том, как работать с каждой новой страницей, поэтому они воспринимают интерфейс интуитивно понятным. Но если вы нарушите эту последовательность, пользователям потребуется время и усилия, чтобы понять, что происходит.
Например, когда вы используете галереи изображений с вертикальной прокруткой на большинстве страниц, а затем используете не столь очевидный горизонтальный ползунок на другой, это может заставить пользователей бороться с контентом или вообще пропустить его. Или, представим, что вы долгое время использовали кнопку с плюсом в нижней части экранов, и пользователи привыкли находить ее там, но потом вы переместили ее в верхнюю часть и спрятали в гамбургер-меню. Или, скажем, вы делаете телефонный номер интерактивным на одних экранах и неинтерактивным на других, хотя везде он выглядит одинаково. Это непоследовательно. Конечно, в этом случае пользователям потребуется некоторое время, чтобы переключиться с одного шаблона на другой. Этот опыт может сильно раздражать, поэтому постарайтесь сгладить его с помощью всплывающих подсказок или других методов.
Конечно, это не означает, что вы должны придерживаться только известных шаблонов. Всегда есть место для творческих и нестандартных решений; просто не забывайте об их связи с тем, что целевые пользователи уже знают и используют, и, если эта связь слабая, подумайте о том, как поддержать пользователей, а не сводить творческий подход к раздражению пользователя. Более того, стремитесь к логике и сходству интерактивных шаблонов – даже если они не являются общими, но единообразными на всех экранах продукта, процесс привыкания к ним будет быстрым и легким.
2. Будьте осторожны с экспериментами над компонентами пользовательского интерфейса.
Исходя из предыдущего пункта, легко увидеть, что любые эксперименты с элементами пользовательского интерфейса должны быть дважды продуманы ради единообразия. Это особенно важно в отношении основных элементов, используемых в тысячах приложений и веб-сайтов. Люди знают их настолько хорошо, что в большинстве случаев им даже не нужно много думать.
Например, с чем бы ни работали пользователи веб-сайта или приложения, когда им нужно что-то найти, они будут искать значок лупы, отмечающий кнопку или поле поиска. Если вы скроете функцию поиска за другим изображением или значком, это может испортить впечатление и запутать пользователя. Вместо того, чтобы взаимодействовать с контентом, они будут пытаться найти поле для его поиска. Или, пытаясь найти способ связи, большинство посетителей веб-сайта будут искать ссылку на страницу или форму «Связаться с нами» в заголовке или контактные данные в нижнем колонтитуле страницы; Имея это в виду, вы можете сократить путь к конверсии и довольным клиентам. То же самое относится к другим основным и широко распространенным функциям, таким как закладки, тележки для покупок, чаты и мессенджеры, сохранение элементов в списках желаний, выполнение звонков, добавление новых элементов и тд. Если вы решили поэкспериментировать с их внешним видом, размещением и производительностью, хорошо их протестируйте и убедитесь, что пользователи смогут с ними успешно взаимодействовать.
3. Умная типографика и цветовое сходство.
Среди наиболее важных факторов визуальной согласованности дизайнеры UX часто упоминают цвет и типографику. Не секрет, что они оба могут влиять на визуальный стиль, эмоциональный фон и поведение пользователей. Поскольку оба продукта имеют решающее значение для визуального восприятия, они позволяют пользователям ощущать целостность продукта при последовательном использовании. Вот почему должна быть хорошо продуманная система дизайна с использованием определенных шрифтов и цветов для текстового контента и элементов макета. Таким образом веб-сайт или приложение будут выглядеть понятными, и пользователям не нужно будет привыкать к новому оформлению и сочетаниям при переходе с одного экрана на другой.
Как уже было сказано выше, цвета также могут быть фактором внешней консистентности. В подавляющем большинстве случаев цвет воспринимается человеческим глазом до того, как мозг декодирует значки, изображения или текст, поэтому лучше проанализировать этот фактор и сделать его полезным для создания интуитивно понятной навигации и создания положительного пользовательского опыта. Помните пример с цветами кнопок приема или отклонения вызова? Если вы хотите испортить этот опыт, просто поменяйте их цветом и сделайте кнопку приема вызова красной, например, оправдывая это тем, что красный очень заметен. Это может закончиться своего рода фиаско: даже если значок выглядит абсолютно четким, большинство пользователей ошибочно принимают его за кнопку отказа только потому, что они видят и декодируют цвет намного быстрее, чем значок или текст, особенно для такой базовой операции.
4. Создайте систему с визуальными эффектами.
Изображения играют огромную роль не только в добавлении красоты и стиля интерфейсу; воспринимаясь быстрее и проще, чем текст, они также поддерживают удобство использования, усиливают сообщение и создают необходимое настроение и атмосферу. Однако, это не означает, что дизайнеры просто берут разные понравившиеся изображения и вставляют их в интерфейс. Как и типографика, изображения должны представлять систему, а не просто случайный набор. В этом случае они становятся еще одним фактором обеспечения единообразия взаимодействия с пользователем.
5. Правильно структурируйте контент.
Помните классическую картинку, объясняющую визуализацию данных с помощью Lego Blocks?
С любыми данными всегда проще работать, если они структурированы. Даже художественные книги представляют собой организованную систему глав, так как же интерфейсы любого вида могут избегать этого? Создание хорошо структурированного контента позволяет пользователю сосредоточиться на информации без предварительных усилий по ее систематизации и пониманию взаимосвязей. И это следует делать не для отдельных экранов или страниц, а для веб-сайта или приложения в целом, чтобы оно было простым и последовательным в любой точке взаимодействия.
Например, используя согласованную систему визуального представления различных элементов статьи (заголовок, подзаголовки, маркеры, цитаты, изображения и галереи изображений, текстовые ссылки и т. Д.), Вы упрощаете взаимодействие с блогом или новостными СМИ, так как пользователи могут быстро понять, как это работает, сканировать страницы и находить то, что им нужно. Кроме того, используя статистику и инфографику, сделайте так, чтобы они выглядели и работали одинаково в приложении или на веб-сайте, чтобы снизить когнитивную нагрузку.
6. Следуйте одной идентичности по нескольким каналам.
Бренд с солидной идентичностью должен демонстрировать постоянную связь своего присутствия в Интернете по разным каналам: веб-сайт, приложение, социальные сети, презентации, корпоративная документация и переписка должны быть объединены в одну систему, в первую очередь, из-за консистентного использования фирменных цветов и шрифтов.
7. Работайте над эффективным UX-письмом
Как мы упоминали в статье о создании хороших текстов для интерфейсов, есть 4 фундаментальных требования, по которым тексты должны быть:
Написание UX определяет, как интерфейс взаимодействует с пользователем, тон и голос бренда, и это еще один фактор, требующий последовательного подхода. Помимо общения с людьми с помощью цифровых продуктов, пользователи ожидают дружелюбного и в чем-то предсказуемого поведения. Даже непоследовательное использование регистров в заголовках и предложениях в приложении может вызвать некоторый дискомфорт.
