Как я проектирую UI/UX (с и без ИИ) 0. Не проектируй интерфейс раньше, чем язык и слова, которыми он будет описан 1. Всегда учитывай Целое Процесс дизайна состоит из трёх шагов: 1) Перечислить все ограничения, под которые проектируется диз; 2) Рассмотреть множество решений, удовлетворяющих этим ограничениям; 3) Если понимаешь, что нужно добавить ограничение или одно можно убрать, вернуться к шагу 1.

ИИ хорошо генерирует варианты, но плохо держит ограничения, поэтому дизайни ограничения раньше, чем экраны

2. Убирай лишнее Убирай ненужное, что все (ты сам, коллеги, ИИ) так любят добавлять. Простой вопрос: "Юзер сможет без этого решить свою задачу?". Ответ в 80%: "да"

Проверяй дизайн на скорость понимания, а не на красоту

3. Дизайни только с живыми данными, ибо они отображают реальность в которой ваш красивый дизайн будет ломаться об длинные тексты. 4. Используйте компоненты, библиотеки и переиспользуемые компоненты. Унификация позволяет систематизировать интерфейс для вас, для пользоателя и для ИИ (помни про ограничения для ИИ).

Проектируй UI для повторного использования UX Гибкость системы = гибкость интерфейса. И наоборот

А если решение работает только для одного экрана, то скорее всего, оно временное. Ищи где UI/UX должен(!) всплывать ещё 5. Заимствовать чужие дизайн-решения не глупо, глупо их не заимствовать, потому что большинство UX-проблем и паттернов уже давно решены. Всё что нужно это опознать ваши, найти подходящее решение и собрать всё вместе. Собранные вначале работы удачные скриншоты от конкурентов/смежных проектов дают более чистое видение проблем и вам и снова полезны для ИИ. 6. Исследуй вкус Предпочтение = это «мне нравится» Вкус = это понимание, почему нравится

Вкус – это рефлексия над собственной реакцией на что-то

7. Никогда не торопись c дизайном 😌

Часто в искусстве используют оч сложные технологические решения, забывая, что главное - это не перезадротить всех задротов, а ✨ эмоции зрителя ✨ Зритель либо испытывает что-то, либо ему скучно. В последнее время у меня вообще появился любимый вопрос ко всем проектам, которые я делаю или консультирую: "почему людям на это не будет похуй?" Неважно, это арт проект, игра, да даже пост в телеге. Оч полезный и очень емкий вопрос, всем советую! Часто кучу эмоций у аудитории вызывают какие-то простые вещи. Как тут. Ну магия же! А на самом деле это просто трекеры (крепко подозреваю, что виар трекеры от Vive), которые приспособили управлять прожекторами.

Иногда ставят такую цепочку тумблеров проверки на важных ответственных пультах управления. Ты должен повернуть каждый из них, как чек-лист, обдумывая каждый пункт: так, тип снаряда правильный, ага, азимут мы поставили, возвышение тоже - и когда ты замкнёшь последний, тебе открывается возможность совершить необратимое действие (в данном случае, выстрел). И вроде идея правильная, но с первого же раза ты просто воспринимаешь это, как цепочку действий, которые нужно выполнить перед выстрелом и просто не думая, пробегаешься по ним, как пилот включает все тумблеры перед взлётом. Только потеря времени. Небольшим улучшением контроля оператора было бы введение пауз между тумблерами, но они ещё больше бы увеличили время выполнения ключевого действия (выстрела). А вот хорошей идеей было бы поставить простейший автомат верификации: Допустим, на пункте управления башней оператор выставил наклонение 32.3 градуса и азимут 177.4, а заряжающий на своём посту уложил в лоток фугасный снаряд. Теперь оператор конечного пункта должен ввести эти же ключевые параметры у себя на пульте - когда они все совпали с теми, что сейчас реально выставлены на остальных пунктах, открывается возможность произвести выстрел. Это гарантирует стабильно высокое внимание оператора и исключает ошибки по невнимательности. Слава Кастилии! Министерство Эргономики

Проектирование дизайна как создание объяснения Прошу своих студентов придумать, как должна выглядеть и работать следующая версия их продукта. Они пишут, мол, там будет то и сё, и надо будет учесть это и это. Кажется, они думают, что они всё понимают, а я всё никак не удовлетворюсь их ответами. Периодически даже звучат слова вроде «давай мы сделаем прототип или даже навайбкодим тебе». А я говорю, да погодите, вы мне объясните сперва! Я верю в идею «кто ясно мыслит, тот ясно излагает», поэтому если вы правда способны сделать прототип, то значит вы понимаете, как всё должно работать, и можете это рассказать. По моему опыту, многие дизайнеры даже не осознают того, что у них в голове нет целостной картины продукта. При этом иногда чтобы что-то придумать, нужно какое-то время порисовать или попрограммировать, как бы пощупать задачу разными способами — это я понимаю. Я не против никаких промежуточных прототипов, если так удобнее думать, но в качестве результата я хочу описание системы. В общем, наша переписка продолжается какое-то время. Они уже пишут подробный текст, но им всё ещё моя просьба кажется удивительной: «Неужели тебе правда это удобнее, чем макет или прототип? На макете же сразу видно, где что!» Да, но не видно, почему! Какой толк от прототипа? Ведь из я прототипа ничего не пойму. Я буду видеть, что что-то как-то сработало, но я не увижу внутренних причин. У меня всю жизнь так было, я терпеть не мог прототипы, потому что я с ними как слепой. Как мне увидеть и осмыслить саму систему, а не отдельные её случайные проявления, до которых я докликал? За прототипом очень легко спрятать, что у вас ничего не продумано. После прочтения Дойча я понимаю, почему так: прототип — не объяснение. Что толку физику от результатов опыта, если у него нет объяснительной теории, которую эти опыты подтверждают или опровергают? Это же просто рандомные факты, вызывающие лишь недоумение. Чтобы понимать, почему они такие, мне нужно открыть, то есть придумать закон, который бы их объяснил. Но если мне самому нужно придумывать закон, глядя на эффекты его воплощения в прототипе, то в чём тогда была работа дизайнеров? Я ж как раз изначально попросил их придумать этот закон! А в итоге вынужден его придумывать я. Если вы его реально придумали, так просто расскажите. А если у вас только прототип, то вы его, скорее всего, просто не придумали. Это всё снова показывает, насколько качественное проектирование близко к придумываю законов физики.

Где возникают ошибки Можно предложить следующую модель получения результата: цель → намерение → действие → система → результат Все это находится в окружении, которое влияет на наши действия. 1. Намерение Насколько намерение помогает достичь цели, или насколько у меня правильный образ действия, того, что я хочу сделать. Дон Норман называл эту стадию понимание «концептуальной модели системы». В ряде случаев концептуальная модель простая: если нажать на педаль тормоза, то машина остановиться. Но в ряде случаев концептуальная модель может быть запутанной: чтобы открыть дверь — её надо толкнуть или потянуть на себя? Я уже не говорю про более сложные системы. Насколько система представляет собой ясную схему, что и как надо сделать, чтобы получить желаемый результат? 2. Действие Несовпадение намерения и действия — действительно ошибка человека. Я хотел повернуть налево, но повернул направо. Я хотел нажать на тормоз, а нажал на газ. Насколько система позволяет сделать неправильное действие. Кроме этого важную роль начинают играть другие факторы: усталость исполнителя, отвлекали ли исполнителя во время важных действий и т.д. 3. Система или черный ящик. Сама система может работать с ошибками. Люди могут неправильно понять, то что мы им говорим, информация передается с ошибками. Механизмы могут быть спроектированы с ошибками, софт ошибается. 4. Окружение Это та обстановка, в которой мы действуем. Либо это культура организации, это социоэкономические факторы и т.д. Окружение может влиять на ошибки, которые возникают в процессе. Есть ли давление, чтобы добиться хороших результатов. Насколько система требует не ошибаться или система требует достичь цели любой ценой. Это культура компании, тон сверху, психологическая безопасность и все подобные вещи. Сюда же относятся ошибки, которые можно называть «внешними событиями». Мы ехали по правилам, в нас врезалась машина. Но мы же все сделали правильно. ;) Как видно, отклонения или ошибки могут возникать на любом уровне в этой модели. Но на каждом уровне ошибки возникают по разными причинами и требуют разных методов для предотвращения. #ЧФ #ошибки

Программирование с явно выделенным состоянием Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть. Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию. Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью. В общем не полагайтесь на то как заполнены поля, вводите нужные статусы, которые явно будут говорить о том что происходит. Заодно это дает более удобную аналитику и выборки Telegram | YouTube | AI Клуб

Отношения между сценарием и навигацией в интерфейсе При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации. Что будет, если просто положить сценарии в основу навигации? Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»: https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/ Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему: https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/ Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например: Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение. Ну и что, как построить навигационную модель вокруг этого сценария? Да никак. Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль. Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда. Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми. Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.

Архитектурные практики Прошло чуть больше полугода, как я перестал писать код руками, за редкими исключениями. Но несмотря на это, я просматриваю его глазами. Где-то внимательнее, где то по диагонали, в зависимости от степени влияния на структуру кода и логику. И каждый раз спрашиваю себя, а какими принципами я руководствуюсь? Пишу этот пост, чтобы порефлексировать с одной стороны и заложить на будущее темы, которые буду разбирать. ИИ это хорошо для кодинга, но инженерия никуда не девается. Все происходит над подсознательном уровне, я работаю в давно знакомом мне проекте и хотя бы примерно понимаю что и где происходит, задачи которые я делаю тоже понятны, все таки и в разработке давно и сам проект не гугл. Но он достаточно большой и сложный, чтобы можно было просто забить на архитектуру и делать как придется. Наверное главное, за чем я слежу и что прорабатываю глубоко это онтология проекта: сущности, свяжи между ними и границы ответственности. Причем речь не идет о том, чтобы попытаться полностью повторить реальный мир, наоборот, идет попытка создать систему, с одной стороны, простой, с другой нужно учесть все необходимые требования от нормализации до поддержки историчности при изменениях (там где это надо). Связь m2m сложнее o2m, это будет проявляться и в запросах и в коде. Можно ли не усложнять? А если мы работаем с иерархией сущностей, надо ли делать одну таблицу с полями сразу для всего, но чтобы каждый тип использовал свое подмножество или нам надо создавать разные таблицы? А как потом их объединять? Денормализация или внешний поиск? И обязательно инварианты. Какие состояния в системе вообще допустимы? Что не должно происходить никогда? Какие связи обязательны, какие опциональны. Здесь мы имеем дело и со смыслами и с технической имплементацией на уровне хранилища и, в моем случае, ORM. Можно ли в этом случае довериться ии? Обсуждать, спрашивать совет и просить рассказать плюсы и минусы разных вариантов это прямо хорошо, но принимать решение точно надо самому, потому что слишком дорого потом придется платить за неудачно принятые решения. А они точно будут. Примерно такая же история с api. Если внешние ручки спроектированы плохо, потом мы обалдеем тащить это легаси через года и пространство. Между первым (моделями) и вторым (api) собственно и лежит большая часть кода в типовых веб-приложениях. Да ее пишет ИИ, но на базе заложенной архитектуры. Причем она достаточно стандартна. У нас есть слой сервисов, где выполняются бизнес-операции и проверяются инварианты. Рядом находится слой авторизации и события. К этому примыкает инфраструктурный слой с асинхронными джобами, очередями, мидлварами и тому подобным. Я отдельно выношу обработчики http, dto и валидациями данных запроса и ответа. Все это вообще не надо писать самостоятельно, сейчас, когда легко доступен design-first, лучше пользоваться генераторами типа openapi-generator, которые создают все автоматом на базе openapi. Все что остается, это вписать в нужные места вызовы своих сервисов и правильно сформировать ответ. Даже если обходиться без генерации, ии отлично справится опираясь на существующий код, если он написан нормально. Отдельный большой блок связан с микросервисной архитектурой, но я пишу про нее редко, потому что живу в монолите (хотя и с кучей сервисов, асинхронных джоб и обвязок вокруг). Оставляю эту тему другим блогерам 🙂 Ну и фронтенд, с ним ситуация явно проще, особенно если использовать готовые библиотеки компонентов и сгенерированные sdk для api (если у нас есть openapi). Да, во фронте есть свои заморочки связанные с безопасностью, отсутствием коннекта, локальным стейтом, ошибками, идемпотентностью и другими интересными темами. И конечно без понимания базы, сделать что-то серьезное будет сложно. Все? Нет конечно, самое интересное начинается когда надо думать об обратной совместимости, следить за транзакционными границами, идемпотентностью и конкурентностью. И тесты, которые ии по дефолту пишет плохо. Вот это все не будет происходить само по себе и хорошо бы знать, как оно устроено под капотом. Что еще упустил?

Threat Modeling - это систематический процесс, при котором мы заранее думаем: «Как нашу систему могут взломать или причинить ей вред?» Это как "мозговой штурм по безопасности" еще до того, как написали большую часть кода. Мы пытаемся поставить себя на место атакующего и найти слабые места, пока их ещё можно легко исправить. Зачем это нужно? (Почему это важно) - Большинство уязвимостей появляется не из-за "сложных хаков", а из-за неправильных решений на этапе дизайна. - Исправить проблему на этапе проектирования в 10–100 раз дешевле, чем после запуска в продакшен. - Это помогает принимать осознанные решения: где нужно усилить защиту, а где можно сэкономить. И вот вам data flow диаграмма, составлял сам на примере сервиса доставки еды

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:

Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.

Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп:

Ну тут сделаем абстрактно, чтобы другие системы, вдруг, взяли и переиспользовали эту логику.

Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх:

Пока система или её часть не переиспользуется как минимум в трёх независимых местах — ничего общего выделять не нужно.

А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect