> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vibely.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Design guidance

> Pick from three design directions rendered for your product before Vibely builds, and steer color, type, and layout when you want a specific look.

**Design guidance** helps you settle the look of your app before Vibely starts building. Depending on your first prompt, Vibely either:

* shows three **design directions**, rendered as mockups of your product, for you to pick from,
* asks a short **design question** about one aspect of the look, such as a palette or a font pairing, or
* **builds directly** when your prompt already pins down the look.

Both help you land closer to what you want on the first build, with fewer rounds of revisions.

<Frame>
  <img src="https://cdn.vibely.sh/doc/v1/design-guidance.webp" alt="Design guidance" width="1200" height="675" />
</Frame>

## Key benefits

* **See before you build.** Compare three rendered mockups of your own product before committing to one.
* **Directions written for your brief.** A bakery, a finance dashboard, and a kids' learning app get different directions, not the same three templates.
* **The build matches what you picked.** Vibely reads the colors and fonts off the mockup you chose and builds with them.
* **Works for web and mobile.** Web projects get page mockups. Mobile projects get phone screens.

## Design directions

Design directions show three different visual approaches for your project before the full build starts.

For each direction, Vibely writes a short art-direction brief for the product you described, naming the feeling, the palette, the type, the layout, and one signature detail, often with a real brand or publication as a reference. It then renders each brief as a mockup of your product, so you compare real layouts, typography, and color side by side.

### When design directions appear

Design directions appear on a first build when the look is open, meaning your prompt describes what to build but not how it should look. They're most common for projects with a strong visual surface, such as:

* Landing pages and marketing sites
* Storefronts
* Portfolios and blogs
* The first screens of a mobile app

Example prompts that lead to design directions:

```text wrap theme={"system"}
Build a landing page for a coffee subscription
Make an online bookstore for a small independent press
Create a portfolio site for a wedding photographer
A habit-tracking app for students
```

Vibely may ask other questions at the same time, such as who the app is for or what it needs to do. The card walks you through them one at a time.

### How to use design directions

<Steps>
  <Step title="Describe your project">
    Write a prompt for what you want to build. Keep it high-level about the look if you want a wider range of directions.
  </Step>

  <Step title="Compare the three directions">
    The directions appear in the question card in the project chat. Scroll through them, or click the expand button on a direction to see its mockup full size.
  </Step>

  <Step title="Pick one">
    Click a direction, or click **Select** in the full-size view. To describe a look of your own instead, choose **Something else** and type it. To let Vibely decide, choose **Skip**.
  </Step>

  <Step title="Vibely builds with it">
    Vibely takes the palette and fonts from the mockup you picked, and the brief behind it, and uses them for the full build.
  </Step>
</Steps>

<Tip>
  If none of the directions is right, pick the closest one and refine it after the first build, for example "keep the layout but use a warmer palette".
</Tip>

### Mobile projects

In mobile projects, each direction is rendered as a phone screen, with a status bar, a real first screen of your app, and a tab bar, so you judge the look at the size it will actually be used.

The chosen colors are written into your app's light and dark themes, and the chosen typeface is installed and loaded for you. See [A worked mobile example](#a-worked-mobile-example).

## Design questions

When only one part of the look is open, or you ask about one part, Vibely asks a single design question with visual options instead of three full mockups:

* **Color palette**: swatch strips of the colors each option would use
* **Typography**: each font pairing previewed in its own typeface, heading and body
* **Layout**: simple wireframe thumbnails of each layout option

You can trigger these directly:

```text wrap theme={"system"}
What fonts could work for this?
Show me three hero layouts
Give me a few palette options for the dashboard
```

## When Vibely skips design guidance

Vibely builds directly when the look is already decided. This includes prompts that:

* name colors, fonts, or a brand,
* reference another product or style directly,
* include a URL to [build from](/features/design/build-from-url),
* attach a mockup, screenshot, or other reference image.

Projects started from a [workspace template](/features/design/workspace-templates) or with a [design system](/features/design/design-systems) attached also skip it, because the look is already set. So do changes to an existing project whose look is established.

Functional requests with little or no visual work, such as authentication, database changes, or bug fixes, also skip it.

To skip design guidance on purpose, put a specific visual brief in your prompt:

```text wrap theme={"system"}
Build a landing page for a coffee subscription. Cream background, dark roast brown text, one terracotta accent. Serif headings, sans-serif body. Large photography, lots of whitespace.
```

## Steer the design after the first build

| Method | Scope | Use it for |
| - | - | - |
| A prompt | The whole app | "Make it feel more editorial", a new palette, a new type scale |
| [Edit from the preview](/features/design/visual-edits) | The elements you select | Copy, spacing, one color, one size |

Selecting elements keeps a change focused. It doesn't rethink the app's overall design.

For a rule that should hold on every later message, add it to [knowledge](/features/context/knowledge), for example "Never use purple. The brand accent is #1F7A5C."

## A worked mobile example

A direction lands in different places on a phone than on the web:

<Steps>
  <Step title="The palette lands in the theme, not CSS">
    React Native has no CSS. The direction's colors are written into both the light and dark themes in `src/constants/theme.ts`, restyling the existing color tokens rather than adding new ones. Screens read the theme, so they update together.
  </Step>

  <Step title="The color reaches the app icon and splash screen">
    The splash screen and Android adaptive icon background use the direction's color, alongside a real app icon.
  </Step>

  <Step title="The typeface is installed and registered">
    Vibely installs the font family and registers each weight the design uses. The splash screen stays up until the fonts load, so there's no flash of the wrong font.
  </Step>
</Steps>

<Warning>
  React Native doesn't fake bold. If a font has no bold weight registered, bold text renders as regular on iOS and as a smeared bold on Android. If you change fonts yourself, ask Vibely to register every weight you use, and stick to at most two families.
</Warning>

## Limitations

* **Mockups use placeholder content.** They show the look, not your final copy. The build writes content for your app.
* **Generating directions takes a little time** before the build starts, usually well under a minute.
* **Directions are for the first build.** Later changes to the look happen through prompts and [Edit from the preview](/features/design/visual-edits).

## FAQ

<AccordionGroup>
  <Accordion title="What if I don't like any of the three directions?">
    Choose **Something else** and describe the look you want, or pick the closest direction and refine it after the first build.
  </Accordion>

  <Accordion title="Can I combine elements from different directions?">
    Pick the closest direction, then ask for the change after the first build, for example "Use this layout with the warmer palette from the second option."
  </Accordion>

  <Accordion title="Can I bring my own fonts and colors?">
    Yes. Name them in your prompt and Vibely skips the directions and uses them. For rules you want applied to every project, add them to [workspace knowledge](/features/context/knowledge).
  </Accordion>

  <Accordion title="Does this work for dashboards and internal tools?">
    Design directions focus on surfaces where the look matters most, such as landing pages, storefronts, and portfolios. Dashboards and internal tools usually go straight to the build, though Vibely may ask a single question about the palette or layout.
  </Accordion>
</AccordionGroup>

## Related topics

<CardGroup cols={2}>
  <Card title="Edit from the preview" icon="arrow-pointer" href="/features/design/visual-edits">
    Point at what to change on the page.
  </Card>

  <Card title="Design systems" icon="swatchbook" href="/features/design/design-systems">
    Reusable design rules for your workspace.
  </Card>

  <Card title="Build from a URL" icon="link" href="/features/design/build-from-url">
    Use an existing site as a design reference.
  </Card>

  <Card title="Prompt library" icon="book-open" href="/prompting/library">
    Prompts for common design styles.
  </Card>
</CardGroup>


## Related topics

- [Design systems](/features/design/design-systems.md)
- [Bring Figma designs into Vibely](/integrations/figma.md)
- [Workspace templates](/features/design/workspace-templates.md)
- [Build from an existing website](/features/design/build-from-url.md)
- [Edit from the preview](/features/design/visual-edits.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.