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

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

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

Такая проверка тоже требует квалификации и даёт профессиональную практику.

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

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

При использовании ИИ состав профессиональной практики меняется. Если всё большая часть работы начинается с готового варианта, специалист получает больше опыта проверки и корректировки. Если меньше, то больше самостоятельного поиска, сравнения и выбора решений.

Дизайнер на всю голову

Традиционно из искры возгорелось пламя. То есть из поста родилась статья на Dsgners о том, как ИИ портит жизнь и клиентам и нам в процессе написания технической документации и что с этим безобразием делать
#статья #ИИ

Дизайнер на всю голову

Что вы хотите знать про user flow? Я бы хотела обойти вниманием то, что по теме описано везде. Может быть есть какие-то узкие точечные вопросы? #userflow

Разговор с Сашей Лагутой (дай бог ему сил и миллион клиентов на миллиард) натолкнул меня на размышления об очередном витке естественного отбора. Если Homo sapiens — человек разумный, то ИИ меняет саму единицу измерения: разум теперь всё меньше находится только внутри черепа. Человек может думать, искать, моделировать, вспоминать и создавать через внешний когнитивный слой (простите меня за это уже ИИшное слово, но иначе не скажешь).

Итак, варианты:

— Homo sapiens augmentatus — человек разумный дополненный. Тут все понятно
— Homo symbioticus — человек симбиотический. Человек + искусственный интеллект образуют интеллектуальную систему, где один компонент задаёт цели, ценности, контекст и принимает решения, а другой резко расширяет память, поиск, анализ.
— Homo sapiens exocorticalis — условно человек с внешней корой мозга. Уже не нужно знать ответ. Важнее уметь сформулировать проблему, отличить хорошее решение от плохого и правильно использовать внешний интеллект.
— Homo promptus — человек формулирующий. Немного иронично, но очень правдиво. В эпоху ИИ преимуществом становится уметь правильно ставить вопросы и задачи.
Выбираем!

Дизайнер на всю голову

Обновление списка. Добавлен Дизайн кабак

Обновлено 17 августа 2026г.

Где можно подписаться на меня и мои посты

Соц. сети (посты)
Телеграм https://t.me/rwh_blog — Основной канал
Threads — https://www.threads.com/@elenapliner (в очень краткой форме с учетом формата)
Вк — https://vk.com/lenapliner (периодически забываю писать сюда, простите)
Тенчат — https://tenchat.ru/elenapliner
Дзен — https://dzen.ru/lenapliner

Площадки, статьи
Dsgners — https://dsgners.ru/elenapliner
Дизайн кабак — https://elenapliner.designpub.ru/
Хабр — https://habr.com/ru/users/epliner/
VC — https://vc.ru/id87295

Возможно, появятся еще какие-то варианты и я буду добавлять информацию в этот пост

В этом посте хочу показать, как у меня сейчас устроен процесс написания статей с ИИ: где я подключаюсь сама, что делает Claude и что полностью автоматизировано через n8n.

И немного про то, как я постепенно дорабатываю этот пайплайн по мере работы с реальными статьями.

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

Сначала я даю Claude исходный контекст: о чём хочу написать, зачем мне эта статья, что именно хочу в ней раскрыть и какие мысли уже есть. Это может быть несколько тезисов, черновые заметки или надиктованный текст.

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

У меня есть база проектов в Notion, размеченная тегами. В процессе интервью Claude может подобрать конкретные проекты, которые подходят к теме статьи. Например, для статьи про дашборды он сначала найдёт проекты, где был такой функционал, и покажет мне список. Я выбираю несколько действительно подходящих, и только после этого Claude открывает их в Figma и смотрит макеты. Это нужно чтобы задавать мне более предметные вопросы: почему здесь было принято такое решение, какую задачу оно решало, что было важно именно в этом проекте.

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

Дальше начинается автоматическая часть процесса. Вся оркестрация собрана в n8n на моём сервере: там лежат промпты для каждого этапа, настроены переходы между статусами и вызовы Claude через API.

Сначала n8n собирает из моего архива посты, кейсы и заметки по совпадающим тегам. Потом Claude отдельно ищет внешние источники по теме и сохраняет их как материал для исследования и последующего фактчекинга. Из темы, интервью, моего архива, внешних источников и документа «Tone of Voice» собирается структура статьи.

Вот здесь я подключаюсь второй раз. Структура приходит в Notion, я её читаю и либо утверждаю статусом, либо оставляю правки. Если отправляю на доработку, n8n сам запускает новый проход и возвращает мне следующую версию.

После утверждения структуры Claude пишет черновик. Дальше его проверяет отдельный агент аудитор, который не видел процесс написания и получает только готовый текст. Он проверяет тезис, логику, факты, примеры, повторы, пользу и соответствие правилам из документа «Tone of Voice». Сам текст аудитор не переписывает, он выдаёт список замечаний.

Далее к работе приступает агент редактор. Он работает со списком замечаний от агента аудитора и исправляет только найденные проблемы. Если замечаний нет, редактура вообще пропускается.

После этого я подключаюсь третий раз и читаю уже саму статью в Notion. Могу исправить что-то прямо в тексте, оставить комментарий или отправить статью ещё на один проход. Claude каждый раз начинает с актуальной версии, поэтому мои ручные изменения не теряются.

Есть ещё отдельный механизм, который постепенно накапливает мои стилевые правила. Если моя правка относится не к конкретной статье, а вообще к стилю, например «не упрощай до примитива», Claude отделяет её от смысловых замечаний и добавляет как новое правило в документ «Tone of Voice».

В итоге схема в n8n получается довольно большой, но этапов с моим участием в ней фактически три: исходный контекст и интервью → проверка структуры → проверка готового текста. Всё, что происходит между ними, от поиска материалов и исследования темы до аудита и редактуры, выполняется автоматически.

После публикации из готовой статьи Claude автоматически собирает короткие анонсы для соцсетей с учётом формата конкретной площадки. #n8n #ai #ии #claude

Дизайнер на всю голову

Свежий отзыв о работе над образовательным порталом #отзыв

Хочу рассказать о том, чем занимаюсь сейчас. Я снова вернулась к нескольким задачам в проекте Star Smile, о котором писала ранее.

Star Smile — сервис для врачей-ортодонтов, где они работают с заказами пациентов, планами лечения и связанными с ними данными.

Сейчас я работаю над вьювером, средой, в которой врач просматривает 3D-модель челюсти, работает с виртуальным планом лечения и анализирует изменения по ходу лечения.

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

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

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

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

Дизайнер на всю голову

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

В новой статье User flow. Как проектировать и зачем я разбираю на реальных проектах, как строю такие схемы, когда выбираю wireflow, где заканчивается один flow и начинается другой и какие ошибки делают схему бесполезной.
#статья #userflow

Дизайнер на всю голову

Напомню о том где еще можно прочитать мои посты и статьи

Обновлено 17 августа 2026г.

Где можно подписаться на меня и мои посты

Соц. сети (посты)
Телеграм https://t.me/rwh_blog — Основной канал
Threads — https://www.threads.com/@elenapliner (в очень краткой форме с учетом формата)
Вк — https://vk.com/lenapliner (периодически забываю писать сюда, простите)
Тенчат — https://tenchat.ru/elenapliner
Сетка — https://setka.ru/users/019afe74-bff0-7de0-9fa7-0a72f7e3891b
Дзен — https://dzen.ru/lenapliner

Площадки, статьи
Dsgners — https://dsgners.ru/elenapliner
Дизайн кабак — https://elenapliner.designpub.ru/
Хабр — https://habr.com/ru/users/epliner/
VC — https://vc.ru/id87295

Возможно, появятся еще какие-то варианты и я буду добавлять информацию в этот пост

8 сентября вышли результаты PISA 2025, международного исследования знаний и навыков 15-летних школьников. Средний результат по чтению в странах OECD оказался самым низким за всё время наблюдений, а особенно заметны трудности в заданиях с длинными текстами, где нужно удерживать несколько фрагментов информации и связывать их между собой.

Я смотрю на эти данные и думаю о том, что они могут означать для интерфейсов через несколько лет.

Если нынешним школьникам действительно всё сложнее работать с большим объёмом связанной информации, то изменения могут затронуть не только тексты в интерфейсе, но и саму его архитектуру.

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

Возможно, именно такая модель постепенно станет менее устойчивой.

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

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

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

Дизайнер на всю голову

Как подступиться к большому незнакомому интерфейсу, если его нужно практически полностью пересобрать? Часть 1.

Сейчас у меня как раз такой проект.

Контекст
«Медоед» — система в области IT и информационной безопасности, которая помогает компаниям работать с требованиями законодательства и регуляторов.

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

Нового функционала на этом этапе не добавляем. Задача — полностью пересобрать UX существующей системы и затем перезапустить UI.

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

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

Поэтому здесь нужно пересматривать и устройство системы, и общие механики, и отдельные страницы внутри пользовательских сценариев.

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

1. Разбираю модули и собираю общую картину
Для каждого модуля фиксирую его цель, начало и результат работы, основные сущности, справочники, сценарии, состояния, связи и используемые механики. Получается паспорт модуля.

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

На этом этапе я ещё ничего не унифицирую. Матрица показывает, где стоит искать потенциальные сквозные решения.

2. Разбираю пользовательские сценарии
Дальше основные сценарии из паспортов раскладываю подробно в Task Analysis:
— цель пользователя;
— последовательность шагов;
— зависимости;
— точки принятия решений;
— взаимодействие с сущностями;
— смену контекста;
— результат сценария.

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

3. Проверяю сквозные UX-паттерны
Теперь можно сопоставить найденные в матрице повторения с реальными сценариями.

Например, в разных модулях могут повторяться:
— создание сущности;
— работа с таблицей и фильтрами;
— выбор объекта из справочника;
— изменение статуса;
— назначение ответственного;
— прикрепление документа.

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

Так появляется библиотека UX-паттернов: общие правила для повторяющихся пользовательских операций, которые дальше не придётся проектировать отдельно для каждого модуля. #проект #uxаудит #предпроектныйанализ

Дизайнер на всю голову

Как подступиться к большому незнакомому интерфейсу, если его нужно практически полностью пересобрать? Часть 2.

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

Например:
форма создания → карточка объекта → таблица или список

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

Здесь нет правила «поле есть в форме, значит оно должно быть в таблице».

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

5. Проверяю архитектуру и навигацию
Task Analysis показывает, между какими сущностями, модулями и разделами пользователю приходится переходить.

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

Результат — карта архитектуры, связей и навигации, которая показывает проблемы уже на уровне всей системы. UX-аудит идёт всё это время

Документ с находками создаю сразу, как только начинаю знакомиться с продуктом, и пополняю на каждом этапе.

Часть анализа делаю вручную, часть дополнительно прохожу с Claude по эвристикам Нильсена. Фиксирую и проблемы, и удачные решения, которые стоит сохранить.

В результате получается связанная модель продукта:
паспорта и матрица → сценарии → сквозные паттерны → данные

Параллельно сценарии дают основу для проверки архитектуры и навигации.

И уже на этой модели можно собирать новый UX, понимая, что должно работать по общим правилам, где нужны различия и как отдельные решения связаны между собой. #проект #uxаудит #предпроектныйанализ

Дизайнер на всю голову

Продолжаю пересобирать UX «Медоеда» — системы для работы с требованиями в области IT и информационной безопасности.

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

Есть и другое пересечение: drag (перетаскивание) используется и для порядка колонок и для порядка группировки. Но это разные операции. В одном случае пользователь меняет представление таблицы, в другом — иерархию данных.

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

Если поле добавлено в группировку, соответствующая колонка остаётся видимой, и отдельно отключить её уже нельзя. Таким образом, в интерфейсе не возникнет конфликтующего состояния «данные сгруппированы по колонке, которой в таблице нет».

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

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

Дальше продолжаю разбирать и пересобирать остальные части системы: таблицы, фильтры, формы, карточки и отдельные сценарии. По мере работы буду показывать здесь отдельные решения и рассказывать, почему они устроены именно так. #проект #ux

Дизайнер на всю голову

Немного о происходящем и перспективах )

Дизайнер на всю голову

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

Показала с реальными примерами как выстраиваю анализ: что изучаю, в какой последовательности, какие вопросы решаю и как результаты одного этапа помогают двигаться дальше. #статья #проект #ux

Читать:
Dsgners
Habr
Дизайн-кабак

Дизайнер на всю голову

Ко мне обратился клиент с задачей разработать интерфейс для оператора конвейерной линии. Существующий интерфейс был собран на скорую руку, не устраивал клиента, и недостатков в нём хватало. Расскажу об одном из них.

Товар идёт по конвейеру, система отсеивает брак: неправильные этикетки, криво поставленные крышки. На мониторе у оператора среди прочего есть индикатор уровня брака в партии — круговая диаграмма. Зелёный сектор показывает годный товар, красный — брак.

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

На маленьких партиях получалось наоборот: прошли две бутылки, одна бракованная, круг показывает 50% красного. Читается как критическая ситуация, хотя данных пока слишком мало, чтобы судить о партии.

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

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

На старте партии, когда изделий ещё мало, шкала не решает проблему. Здесь уже важна логика расчёта. Можно опереться на принцип: порог тревоги зависит от количества прошедших изделий, и одна бракованная бутылка из двух ещё не считается сигналом.

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

Дизайнер на всю голову

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

Дизайнер на всю голову