# Сначала возможности действия, затем экраны, выверенные до пикселя

Канонический адрес: https://producthub.live/shape-up/snachala-vozmozhnosti-deystviya-zatem-ekrany-vyverennye
Автор публикации: Product Hub (https://producthub.ru). Опубликовано: 2026-10-13. Обновлено: 2026-10-13.
Книга: Ryan Singer (Райан Сингер), «Shape Up: Stop Running in Circles and Ship Work that Matters», Basecamp, 2019. Оригинал: https://basecamp.com/shapeup

Перевод на русский, часть 2 «Получить работающий результат», глава 5 «Собрать первый рабочий фрагмент». Оглавление: https://producthub.live/shape-up

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

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

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

![Простой HTML-интерфейс регистрации на многодневные курсы](https://producthub.live/assets/books/shape-up/light/p076-01.webp)

Это скриншот приложения для регистрации на многодневные курсы. Дизайнер вручную написала для него HTML. Оформления почти нет — лишь визуальная иерархия, достаточная, чтобы убедиться: компоновка удобна и поверх неё можно будет добавить оформление.

Хотя дизайн выглядит простым, в нём отражено множество решений.

- Решение спрашивать время прибытия, но не время отъезда возникло из подробных обсуждений бизнес-логики и модели ценообразования.
- Конкретные варианты в выпадающем списке времени прибытия соответствуют правилам оплаты питания и ночёвок, которые пришлось выработать.
- В первых эскизах дизайнер использовала календарный элемент выбора дат прибытия и отъезда. Но это создало проблемы с удобством использования. Некоторые курсы были длинными — по несколько недель — и состояли из разных этапов. В стандартном календаре выбора даты не хватало места в ячейках дней для подписей этапов. В выпадающем списке она могла при необходимости группировать даты и подписывать группы. Так пользователям не нужно было сверяться с расписанием где-то ещё, чтобы убедиться, что они выбирают нужные даты.

Вот ещё один пример. Это первая работающая часть приложения для записи данных клиентских интервью.

![Первый рабочий интерфейс приложения для записи данных интервью](https://producthub.live/assets/books/shape-up/light/p077-01.webp)

На этом раннем этапе название проекта (Basecamp) и имя участника интервью (Jan) были жёстко заданы в коде, а большинство ссылок никуда не вели.

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

![Черновой экран добавления и редактирования притягивающих факторов](https://producthub.live/assets/books/shape-up/light/p078-01.webp)

Это первый дизайн для добавления и редактирования *pulls* — притягивающих факторов, одного из типов данных в этой технике интервью. Снова обратите внимание, насколько он черновой. Дизайна ровно столько, чтобы быстро подключить код и проверить решение. Команда может пройти по экранам и оценить, приемлем ли переход на отдельный экран для записи данных. Если всё работает, дополнительное оформление можно добавить позже. Если нет, команда не потратила много времени на реализацию дизайна, выверенного до пикселя.

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

Далее: [Пишите ровно столько кода, сколько нужно для следующего шага](https://producthub.live/shape-up/pishite-rovno-stolko-koda-skolko-nuzhno)