Использовать промпт
Добавьте своё задание
Добавьте контекст ниже. Он будет включён в промпт при копировании или скачивании.
Создайте редактируемый прототип приложения с приоритетом мобильных устройств, используя существующий стек проекта для [PROJECT] и [AUDIENCE]. Задача: кошелёк билетов для поездок.
Обязательные контент и структура
Выберите пункт отправления, пункт назначения и время отправления, просмотрите явно помеченный демонстрационный тариф, затем покажите образец билета и срок его действия.
Экраны и навигация
Создайте три связанных представления: «Выбор поездки»; «Проверка билета»; «Мои билеты». Оставляйте выбранную запись видимой в заголовке экрана или сводке. Предусмотрите явное действие «Назад» и сохраняйте незавершённый ввод при переходе между представлениями. Размещайте основное действие рядом с относящимся к нему контентом и учитывайте безопасные зоны мобильных устройств, видимую экранную клавиатуру и длинные переведённые подписи. На экранах настольной ширины адаптируйте композицию, не удаляя этапы и не меняя задачу.
Исходные данные проекта
Используйте [APPROVED_CONTENT] для имён, записей, подписей, количеств и пунктов назначения. Если данных не хватает, запросите их, а не выдумывайте утверждения о работе сервиса. В демонстрационных записях можно использовать вымышленный бренд Metroday; помечайте их как образцы данных. Объясните, какие действия являются локальными взаимодействиями прототипа, а какие потребуют аутентификации, постоянного хранения данных, разрешений или бэкенда. Не подключайте внешние сервисы и не заявляйте о завершении транзакции, если соответствующая интеграция не была явно реализована и протестирована.
Направление дизайна
Следуйте [BRAND_RULES]. Если бренд не указан, используйте белый, глубокий тёмно-синий и электрический лаймовый цвета, а также транспортную типографику. Сделайте рабочий процесс узнаваемым благодаря его собственному контенту и элементам управления, а не повторению универсальных карточек панели управления. Используйте единую шкалу отступов и чёткую текстовую иерархию. Добавьте видимый фокус клавиатуры, доступные названия, достаточную контрастность и текстовые метки состояний, не зависящие от цвета. Учитывайте настройку уменьшения движения и сделайте анимированные переходы необязательными.
Проверка критериев приёмки для задачи
- Чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда.
Состояния взаимодействия
Реализуйте успешный сценарий из трёх экранов с локальными тестовыми данными. Добавьте полезное пустое состояние, валидацию перед завершением действия, состояние загрузки или ожидания и состояние ошибки с возможностью восстановления. Для необратимых изменений предусмотрите подтверждение или возможность отмены. Состояние записи должно быть согласованным на всех трёх экранах. Не удаляйте без предупреждения частично введённые данные и не меняйте выбор пользователя после повторной попытки.
Передача результата и проверка
Предоставьте редактируемые экраны приложения и опишите модель данных, поведение локального хранилища и нереализованные интеграции. Протестируйте при ширине 320px и в более широком окне просмотра, используя навигацию с клавиатуры и длинный контент. Перед добавлением функций проверьте результат по приведённому выше критерию приёмки для этой задачи. Чётко отделяйте демонстрационное поведение от работающего промышленного сервиса.
Референс и цель воссоздания
Прикрепите файл reference.webp из пакета загрузки этого дизайн-промпта к самому промпту в OpenDesign. Создайте редактируемый результат с похожими композицией и иерархией; не вставляйте всё референсное изображение в качестве готового интерфейса. Если утверждённый контент проекта и правила бренда противоречат вымышленным примерам подписей, сохраняйте утверждённые материалы. Если изображение отсутствует или нечитаемо, запросите его, а не заявляйте о визуальном соответствии.
Композиция и контент референса
Используйте прикреплённый файл reference.webp как визуальный образец для кошелька билетов для поездок. Перед разработкой определите основные области сверху вниз, их относительную ширину и высоту, выравнивание, интервалы, типографическую иерархию, цвета поверхностей, границы, изображения и повторяющиеся компоненты. Сохраните эти соотношения, а не заменяйте их универсальным шаблоном. Обязательное содержание задачи: выбрать пункт отправления, пункт назначения и время отправления, проверить демонстрационный тариф с чёткой маркировкой, а затем показать образец билета и период его действия. При преобразовании изображения в редактируемые элементы следуйте этим указаниям по компоновке для данной задачи: начните с экрана «Выбор поездки», добавьте на экран «Проверка билета» чёткое основное действие, а на экране «Мои билеты» объясните, что произошло и что можно сделать дальше. В качестве исходного направления используйте белый, глубокий тёмно-синий и электрический лаймовый цвета, а также транспортную типографику, адаптируя их к предоставленному бренду. Сохраняйте идентификацию записи и контекст навигации видимыми на всех трёх экранах. Отдавайте приоритет доступным для большого пальца элементам управления и читаемым подписям, а не декоративным панелям; на широких экранах сохраняйте связность рабочего процесса, а не растягивайте мобильную композицию от края до края.
Визуальное направление из примера проекта
белый, глубокий тёмно-синий и электрический лаймовый цвета, транспортная типографика.
Спецификация взаимодействия
Референс — это статическая концепция: описанное ниже поведение требуется реализовать, но изображение не доказывает, что оно уже работает. Скопируйте адаптированный промпт в свой проект и создайте связанный сценарий: выберите пункт отправления, пункт назначения и время отправления, проверьте демонстрационный тариф с чёткой маркировкой, а затем покажите образец билета и период его действия. Чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда. Для каждого видимого элемента управления укажите инициирующее действие, затрагиваемое состояние и обратную связь; реализуйте локальные изменения с согласованным состоянием во связанных представлениях. Поиск и фильтры должны выдавать реальные результаты, элементы выбора — иметь явное активное состояние, а действия сохранения — показывать видимую обратную связь об ожидании, успехе или ошибке там, где это уместно. Не добавляйте несвязанные рабочие процессы. Используйте корректные ссылки для навигации, кнопки для действий и доступные названия для элементов управления со значками. Не создавайте впечатление, что операция на бэкенде завершилась успешно, если изменилось только локальное демо.
Визуальное сравнение и передача результата
- Сравните результат с прикреплённым изображением при совпадающих пропорциях. Перед проработкой декоративных деталей проверьте расположение основных областей, относительные размеры изображений, переносы строк, интервалы, типографическую иерархию, контраст, активные состояния и плотность контента.
- Затем протестируйте узкий макет, не сжимая текст для настольной версии до крошечных подписей.
- Храните логотипы, фотографии и значки как отдельные ресурсы, а все значимые подписи оставьте редактируемыми. Перечислите недоступные шрифты и ресурсы, а также намеренные отступления. Верните рабочие файлы вместе с кратким описанием реализованного поведения и оставшихся интеграций; не обещайте попиксельное совпадение только на основании промпта.
Скачать промпт и изображение
Содержит полный промпт и полноразмерное референсное изображение. Добавьте оба файла в OpenDesign, чтобы задать направление макета.
Как составить дизайн-промпт кошелька билетов для поездок
Используйте этот дизайн-промпт кошелька билетов для поездок, чтобы выбрать пункт отправления, пункт назначения и время отправления, проверить демонстрационный тариф с чёткой маркировкой, а затем показать образец билета и период его действия.
Референс — концепция, созданная ИИ. Приведённые ниже инструкции описывают, что нужно создать и протестировать; изображение не демонстрирует работающее поведение.
Сделайте срок действия билета понятным офлайн
В кошельке билетов для поездок необходимо чётко различать сохранённую информацию и действительное право на проезд.
Демонстрационный характер образца тарифа и билета должен оставаться очевидным. Начните с экрана «Выбор поездки», добавьте на экран «Проверка билета» чёткое основное действие, а на экране «Мои билеты» объясните, что произошло и что можно сделать дальше. В качестве исходного направления используйте белый, глубокий тёмно-синий и электрический лаймовый цвета, а также транспортную типографику, адаптируя их к предоставленному бренду. Сохраняйте идентификацию записи и контекст навигации видимыми на всех трёх экранах. Отдавайте приоритет доступным для большого пальца элементам управления и читаемым подписям, а не декоративным панелям; на широких экранах сохраняйте связность рабочего процесса, а не растягивайте мобильную композицию от края до края.
Из промпта
Создайте три связанных представления: «Выбор поездки»; «Проверка билета»; «Мои билеты».
Настройте под себя
Позвольте пользователям выбрать поездку и проверить демонстрационный тариф с соответствующей маркировкой. Покажите образец билета и период его действия, различая будущие, действующие и просроченные состояния даже без подключения.
Подготовьте контент для кошелька билетов для поездок
Перед покупкой на экране проверки показаны маршрут, тип билета, срок действия и цена. Используйте точные тарифные правила и не скрывайте ограничения за кнопкой оплаты.
Предоставьте примеры остановок, времени отправления, демонстрационных тарифов и периодов действия билетов. Включите будущие и просроченные билеты и укажите, какие сведения можно хранить офлайн, не создавая впечатления, что демо выдаёт билеты на проезд.
Из промпта
Выберите пункт отправления, пункт назначения и время отправления, просмотрите явно помеченный демонстрационный тариф, затем покажите образец билета и срок его действия.
Настройте под себя
Для [PROJECT] используйте [APPROVED_CONTENT] как источник данных для этого кошелька билетов для поездок. Утверждённые записи и подписи полей для экранов «Выбор поездки»; «Проверка билета»; «Мои билеты»; правила действий и хранения данных; ресурсы бренда и требования к разрешениям. Определите недостающие данные, прежде чем заменять их демонстрационным контентом.
Откройте просроченный билет офлайн
Кошелёк отличает активный QR-билет от предстоящих и истёкших билетов. Протестируйте доступность без подключения к интернету и состояния проверки; образец QR-кода нельзя представлять как действующий билет.
Билет может оставаться доступным для просмотра, но его просроченный статус должен быть очевиден. Доступность офлайн никогда не должна представляться как подтверждение того, что билет можно использовать для проезда. Сначала протестируйте этот конкретный пограничный случай: чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда. Затем пройдите основной сценарий с длинным названием записи, без сохранённых записей и с неудачным действием. Пользователь должен понимать, что сохранено, что ожидает выполнения и что можно отменить, не полагаясь на цвет. Убедитесь, что возврат на предыдущий экран сохраняет введённые данные, а программа экранного доступа встречает заголовок, состояние и основное действие в логичном порядке.
Из промпта
Чётко разделяйте просроченные и будущие билеты; просмотр без подключения к сети не должен создавать впечатление, что билет действителен для поездки.
Настройте под себя
Проверьте кошелёк билетов для поездок на соответствие этому требованию: чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда. Сначала протестируйте этот конкретный пограничный случай: чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда. Затем пройдите основной сценарий с длинным названием записи, без сохранённых записей и с неудачным действием. Пользователь должен понимать, что сохранено, что ожидает выполнения и что можно отменить, не полагаясь на цвет. Убедитесь, что возврат на предыдущий экран сохраняет введённые данные, а программа экранного доступа встречает заголовок, состояние и основное действие в логичном порядке. Сохраните утверждённый контент и измените только те части, которые не проходят эту проверку.
Проверьте результат для кошелька билетов для поездок
Пример представляет собой визуальную концепцию, созданную ИИ. Подключённые сервисы, разрешения устройства и постоянное хранение данных требуют отдельной реализации и тестирования.
- Чётко разделяйте просроченные и будущие билеты; просмотр без подключения к сети не должен создавать впечатление, что билет действителен для поездки.
Уточняющий промпт
Используйте это после получения первого результата. Так доработка будет сосредоточена на самой важной части задачи.
Уточните только переход от экрана «Проверка билета» к экрану «Мои билеты». Чётко различайте просроченные и будущие билеты; просмотр офлайн не должен создавать впечатление, что билет действителен для проезда. Покажите соответствующие состояния ожидания, ошибки и завершения с явными текстовыми метками. Сохраните утверждённую навигацию, типографику и остальные экраны. Верните изменённые представления и опишите, как введённые данные сохраняются при повторной попытке.
