Прототипирование фронта в 2к26 от системного аналитика

Я системный аналитик с N лет опыта работы — сколько захотите, столько и придумайте. Расскажу, как раньше я проектировал интерфейсы, делал красивый фронт, которым пользовались и, наверное, продолжают пользоваться конечные потребители, и что я делаю сейчас.

Как все начиналось

В самом начале, когда я очень сильно грешил, где-то на первом курсе института, я прыгал с одной профессии на другую. Сегодня я хочу быть фронтендером, завтра — Java-разработчиком, потом — C++-разработчиком, затем писать бэк на Python, а в пятницу я хочу быть QA. Мой кореш, пусть это будет «Кот Борис», рассказал мне про такой прекрасный сайт, как Figma. Было прикольно набросать какой-нибудь дизайн, посмотреть работы в Community, взять оттуда красивый референс, набор готовых компонентов и так далее. Я даже начинал проходить курс по Figma: горячие клавиши, работа с компонентами и все такое. Прошел я урока три, но мне этого хватило на многие годы. Ну а в конце можно было что-нибудь сверстать и забыть про это. Этот навык потом не раз пригодился мне на работе.

Как я работал с Figma в проде

Расскажу, как я работал с Figma в так называемом проде, или продуктовой разработке. Были стейкхолдеры — заказчики, шефы и другие прекрасные люди. Были дизайнеры. И был я. Какие задачи передо мной стояли? Прилетает фича, например, нужно добавить новую страницу для вывода информации. Сначала мы собираем требования: что это за информация, какие у нее типы данных, откуда она берется, какие методы используются и так далее. В результате у нас появляется понимание того, что должно отображаться на странице. После этого я перехожу в Figma, беру готовые компоненты из дизайн-системы, чтобы все выглядело правдоподобнее, и натягиваю сову на глобус так, как я вижу будущее решение.

Затем описывал каждое поле:

• откуда оно берется;

• какой у него тип данных;

• является ли оно обязательным;

• какая у него минимальная и максимальная длина;

• какие есть ограничения;

• что должно происходить при ошибке.

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

— Блин, класс, как все красиво и аккуратно.

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

— Фига себе ты придумал. Я в Paint рисую.

Как говорил наш любимый шеф:

— Делаем как надо. Как не надо — не делаем.

Balsamiq — это отдельная глава

Другой программой для создания макетов был Balsamiq. Это отдельная глава. Я уже не помню, как мы к нему пришли и почему на какое-то время перешли с Figma. Не могу сказать, что Balsamiq мне совсем не нравился. У него была прикольная рисовка: интерфейс выглядел так, будто ты нарисовал его от руки. Но зачем этим заниматься, если у вас уже есть готовые компоненты? Зачем делать работу ради работы? Каждый раз нужно создавать новый файл и собирать макет практически с нуля. Мы все-таки аналитики. И не просто аналитики, а системные. Нам не нужно писать огромные тексты только ради того, чтобы их написать. Нам за это деньги не платят. Если вы хотите, чтобы вам платили за большое количество текста, то вам, возможно, лучше пойти в технические писатели. Не в оскорбление техническим писателям. Мы вас очень любим. Особенно за docs-as-code. Поэтому после небольшого всплеска интереса к чему-то новому я снова вернулся к Figma. Можно сказать, что до самого конца.

Что изменилось

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

• ИИ;

• LLM;

• генеративный искусственный интеллект;

• большая языковая модель;

• или просто Т9 — кому как нравится.

Из рилсов, статей и других видео мы знаем о таком «прекрасном» слове, как вайбкодинг.

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

Все, что нам для этого нужно:

• HTML;

• CSS;

• JavaScript;

• текст задачи;

• IDE;

• любимая ИИшка.

Зачем системному аналитику такой прототип

Прототип — это не попытка аналитика заменить дизайнера или фронтенд-разработчика. Это еще один способ сформулировать требования и проверить решение до начала полноценной разработки.

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

С ним легче:

• согласовывать решение с лпр;

• показывать пользовательские сценарии;

• быстрее вносить изменения;

• обсуждать спорные моменты;

• проверять, правильно ли вас поняли;

• обнаруживать ошибки до начала разработки.

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

• встроить решение в существующую архитектуру;

• использовать реальные компоненты;

• подключить API;

• реализовать состояния;

• обработать ошибки;

• добавить доступность;

• учесть адаптивность;

• написать тесты.

Но ему будет проще понять, что именно вы хотите получить.

Почему я использую HTML, CSS и JavaScript

Для своих прототипов я рекомендую использовать обычные HTML, CSS и JavaScript. Не потому, что React, Vue или другие фреймворки плохие. Просто наша задача — выбрать самый простой стек, который позволит быстро показать решение и который не будет жалко выбросить после согласования. Нам не нужно поднимать полноценный сервер, проектировать архитектуру приложения, настраивать сборку и создавать продовую инфраструктуру.

МЫ НЕ РАЗРАБОТЧИКИ.

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

• переходить между страницами;

• открывать модальные окна;

• нажимать кнопки;

• использовать тестовые данные;

• показывать фильтры;

• имитировать загрузку;

• выводить ошибки;

• демонстрировать валидации;

• переключать состояния.

И все это — без бэка.

Как сделать прототип через ИИ

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

Вариант 1. В компании разрешены внешние ИИ

У некоторых компаний есть разрешение на использование сторонних ИИ-сервисов. В таком случае вы можете передать модели:

• скриншот существующей системы;

• примеры компонентов;

• цветовую палитру;

• расположение элементов;

• описание задачи;

• пользовательские сценарии.

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

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

Как по мне, это самый удобный вариант. Можно попробовать передавать HTML, CSS и JavaScript, полученные через инструменты разработчика браузера. Но я так никогда не делал и ручаться за этот подход не могу.

Вариант 2. В компании есть внутренняя LLM

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

Пожалуйста, пожалуйста, пожалуйста, не отправляйте сообщения из корпоративной почты непонятно куда. Отправляйте их хотя бы в наш внутренний контур.

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

Вариант 3. Внешние ИИ запрещены

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

• какие элементы находятся на странице;

• где они расположены;

• какие есть поля;

• какие используются цвета;

• как ведут себя кнопки;

• какие открываются окна;

• какие данные можно использовать;

• какие состояния нужно показать.

Через несколько итераций результат будет нормальным. Да, этот вариант займет больше времени, но зато мы ничего не слили.

Как я делаю прототип

Первым делом я создаю статичный макет. Он нужен мне для того, чтобы самому посмотреть на будущий интерфейс и понять: идея вообще жива или нет? Иногда решение красиво выглядит в тексте, но разваливается, как только появляется на экране. После этого я добавляю JavaScript, чтобы можно было:

• нажимать кнопки;

• открывать окна;

• переключать вкладки;

• переходить между страницами;

• выбирать значения;

• имитировать простые действия.

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

• валидацию;

• сообщения об ошибках;

• фильтры;

• сортировку;

• пагинацию;

• загрузку;

• пустые состояния;

• имитацию API-вызовов;

• разные роли пользователей;

• успешные и неуспешные сценарии.

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

Когда прототип делать не нужно

Здесь должен быть небольшой дисклеймер. Если вам требуется добавить одно поле для ввода или отображения, то никакой отдельный прототип, скорее всего, не нужен. Это будет просто трата вашего времени и ресурсов ИИ. Прототип также может быть лишним, если:

• используется уже существующий и понятный компонент;

• сценарий полностью стандартный;

• у команды есть готовый паттерн;

• задача не вызывает вопросов у бизнеса и разработки;

• создание прототипа займёт больше времени, чем обсуждение самой задачи.

Прототипирование не должно становиться работой ради работы. Иначе мы незаметно вернемся к Figma.

Что в итоге

Поэтому в 2к26 прототипирование для системного аналитика уже может выглядеть как создание свёрстанного фронта. Но это все равно быстрее, нагляднее и зачастую красивее, чем было раньше. Главное — не путать такой макет с продовой разработкой. Это не готовый продукт, а способ точно сформулировать требования, показать предполагаемое поведение системы и обнаружить ошибки до того, как они станут дорогими. В результате:

• бизнес видит не абстрактное описание, а будущий интерфейс;

• фронтендер получает наглядный референс;

• аналитик раньше замечает пробелы в требованиях;

• команда быстрее приходит к общему пониманию.