# Design a UI prototype (/use-cases/design/ui-interaction-design)



Copy this prompt to start your first task:

<Prompt>
  I need a UI for [feature]. Start with the information architecture and user flow, not visuals, so I can review the structure first. Once I approve it, build a prototype and write up interaction notes for every screen.
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;I need a UI for [feature]. Start with the information architecture and user flow, not visuals, so I can review the structure first. Once I approve it, build a prototype and write up interaction notes for every screen.&#x22; }" />

## What is this workflow? [#what-is-this-workflow]

"Design a UI prototype" turns a feature brief into something engineering can build from, in a fixed order: information architecture — screen and flow structure — comes first, before any visual design starts. Once that structure is confirmed, a low-fidelity prototype gets raised to high fidelity, and interaction notes get written out screen by screen: click/tap behavior, hover, and every state transition, including empty, loading, error, and permission-denied states, so engineering isn't left to guess.

## How to use this workflow [#how-to-use-this-workflow]

<Steps>
  <Step>
    ### Hire a designer [#hire-a-designer]

    Open **AI Teammates** in the sidebar, click **Hire AI Teammate**, and pick the **Designer** template, built to turn product intent into coherent flows, surfaces, and states. The default bio is generic interaction design work. Replace it on the Profile step so it knows this job starts with structure, not visuals:

    <Prompt>
      You turn a feature brief into information architecture before any visual design starts: screen and flow structure first, for review. Once that structure is confirmed, you raise it to a high-fidelity prototype. You also write the interaction notes engineering does not have to guess at: click and tap behavior, hover, and every state transition, including empty, loading, error, and permission-denied states, spelled out screen by screen.
    </Prompt>

    Confirm the name and click **Create teammate**. They land in their own channel, which is where you'll send everything below. [More on hiring →](/ai-teammates/hire-an-ai-teammate)

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/designer&#x22;, name: &#x22;Designer&#x22;, bio: &#x22;You turn a feature brief into information architecture before any visual design starts: screen and flow structure first, for review. Once that structure is confirmed, you raise it to a high-fidelity prototype. You also write the interaction notes engineering does not have to guess at: click and tap behavior, hover, and every state transition, including empty, loading, error, and permission-denied states, spelled out screen by screen.&#x22; } }" />
  </Step>

  <Step>
    ### Connect Notion [#connect-notion]

    Interaction specs and design decisions get documented here as a living reference engineering can check against. [Connect Notion →](/connect/connect-tools-to-ai-teammates)

    <LivePreview component="AssistantIntegrations" />
  </Step>

  <Step>
    ### Give it the brief [#give-it-the-brief]

    <Prompt>
      We need a UI for [feature]: [what it does, in one line]. Target users are [who they are and how they'll use it]. Reference style: [an existing UI to model after]. Start with information architecture, not visuals. I want to review the structure before you polish anything.
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Designer&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;We need a UI for saved searches: users can save a filtered view and get notified when new results match it. Target users are recruiters scanning candidate lists daily. Reference style: our existing filters panel. Start with information architecture, not visuals. I want to review the structure before you polish anything.&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;Starting with structure, not visuals, like you said. I'll map the save-search → notify → review-matches flow against your existing filters panel, then hand that back before touching any visuals.&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### Confirm structure, then ask for the interaction notes [#confirm-structure-then-ask-for-the-interaction-notes]

    Once the low-fidelity structure is approved:

    <Prompt>
      Raise this to high fidelity, then walk every screen and document what happens on click, hover, and each state transition, including empty, loading, error, and permission-denied states.
    </Prompt>
  </Step>
</Steps>

<Callout type="info">
  If you don't have a design system yet, give it your reference styles and it proposes one, then applies it consistently across every screen it designs afterward.
</Callout>

## Tips for Better Results [#tips-for-better-results]

| Tip                                   | Description                                                                                                                                                                                        |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Structure before visuals              | Confirm the information architecture — screens and flows — before any visual design starts. Reacting to structure is faster than reacting to a polished prototype.                                 |
| Give it a reference style             | If you have existing UI to model after, name it up front. Without a design system, the teammate proposes one from your reference styles and applies it consistently across every screen afterward. |
| Ask for interaction notes explicitly  | Click/tap behavior, hover, and state transitions (empty, loading, error, permission-denied) get documented screen by screen once you ask for them, after structure is confirmed.                   |
| Connect Notion for a living reference | Interaction specs and design decisions get written there so engineering has something to check against, not just a chat thread to scroll back through.                                             |

## Common Questions [#common-questions]

<Accordions type="single">
  <Accordion title="Does this start with visual design?">
    No. It starts with information architecture — screen and flow structure — for review, before any visuals get touched.
  </Accordion>

  <Accordion title="What if we don't have a design system yet?">
    Give it your reference styles and it proposes one, then applies it consistently across every screen it designs afterward.
  </Accordion>

  <Accordion title="What does it document for engineering?">
    Interaction notes screen by screen: click/tap behavior, hover, and every state transition, including empty, loading, error, and permission-denied states.
  </Accordion>

  <Accordion title="Which teammate can do this?">
    The Designer template is the default starting point — built to turn product intent into coherent flows, surfaces, and states.
  </Accordion>

  <Accordion title="Why connect Notion?">
    So interaction specs and design decisions get documented as a living reference engineering can check against, instead of scattered across chat.
  </Accordion>
</Accordions>

<Cards>
  <Card title="Design" href="/use-cases/design" description="Back to the design use case overview." />

  <Card title="Catch UI feedback and ship the fix" href="/use-cases/design/usability-review" description="A daily digest triages feedback into a same-day PR or a designer's queue." />
</Cards>