# Ux Interaction Design

> >

- **Type:** Skill
- **Install:** `agentstack add skill-mahirautela2020-design-claude-skills-ux-ux-interaction-design`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [mahirautela2020-design](https://agentstack.voostack.com/s/mahirautela2020-design)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [mahirautela2020-design](https://github.com/mahirautela2020-design)
- **Source:** https://github.com/mahirautela2020-design/claude-skills-ux/tree/main/ux-interaction-design

## Install

```sh
agentstack add skill-mahirautela2020-design-claude-skills-ux-ux-interaction-design
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# UX Interaction Design & Behavior

## Purpose

This skill helps define how users and the system interact over time: what happens on each step, how controls behave, how states change, and how feedback is communicated.[web:240][web:243] It focuses on task-centric interaction design, including states, edge cases, errors, and patterns that match user expectations while keeping complexity manageable, and leverages `ux-design-principles` for heuristics, laws, and platform guidance plus `ux-product-design-metrics` when interaction changes need to be measured.[web:260][web:303]

Use this skill when you need to design or refine flows and screens beyond static layouts: deciding interactions, handling edge cases, and specifying detailed behaviour for implementation.

---

## Instructions

### Step 1: Clarify the core task and context

Before specifying interactions, clarify the **task**, **context**, and **constraints**.

Ask:

- "What is the primary task or set of tasks this flow must support?"
- "Who is the user in this scenario (persona/segment) and what are they trying to achieve?"
- "On which platforms/devices will this interaction run (web, mobile, desktop)?"

Summarize:

- Core task(s) and success criteria
- Target users and context (frequency, urgency, risk)
- Platforms and any major technical or policy constraints

This anchors interaction decisions in actual user goals and environment, and sets up later metric choices from `ux-product-design-metrics` (e.g., task success, time on task, error rate).[web:288][web:303]

---

### Step 2: Identify key steps and decision points

Outline the **logical steps** and decisions in the flow (building on IA and user flows if available).[web:110]

For the chosen task:

- List steps from start to completion.
- Note decision points (e.g., “user chooses plan type”, “system validates payment”).
- Mark where user input is required vs where the system acts automatically.

Represent it as a simple sequence, for example:

- Step 1: User lands on [entry screen]
- Step 2: User chooses [option A/B/C]
- Step 3: System [validates / fetches / calculates]
- Step 4: User confirms / edits
- Step 5: System finalizes and shows result

This will guide which interactions need detailed behaviour and states and can later be tied to metrics like completion rate and drop-off as defined in `ux-product-design-metrics`.[web:303][web:308]

---

### Step 3: Define control types and interaction patterns

Choose interaction patterns and controls that are appropriate for the task, platform, and mental model.[web:240][web:243]

For each step or decision:

- Decide how users will act:
  - Click/tap vs drag-and-drop vs keyboard input vs gestures
  - Single primary action vs multiple secondary actions
- Choose control types:
  - Buttons vs links vs icons (and when each is appropriate)
  - Radio buttons vs checkboxes vs dropdowns vs segmented controls
  - Steppers, sliders, toggles, date pickers, etc.

Apply guidelines (drawing from `ux-design-principles`):

- Prefer simple, well-known patterns and platform conventions before inventing custom interactions (Jakob’s Law, consistency).[web:260][web:288]
- Avoid overloading a single control with many meanings.
- Ensure there is a clear primary action on each screen and that destructive or risky actions are clearly differentiated (e.g., styling, confirmation, Von Restorff effect).[web:260]

Document for each control:

- Purpose (what it does)
- Type and label
- When it is enabled/disabled
- Any shortcuts or accelerators (e.g., keyboard, bulk actions) if relevant

---

### Step 4: Specify states for key components and screens

Interaction design requires clear handling of **states**.[web:240]

For important components and screens, define:

- **Idle / default** – initial state before user interaction
- **Hover / focus / active** (where applicable)
- **Loading / in-progress**
- **Success / done**
- **Empty states** – when there is no data yet
- **Error states** – when something goes wrong
- **Disabled / unavailable**

For each state:

- Describe what the user sees (visual cues, text, icons).
- Describe what the user can and cannot do.
- Note transitions: what triggers entry and exit from the state.

Example:

- Button “Submit”:
  - Default: enabled, label “Submit”.
  - Loading: disabled, spinner shown, label “Submitting…”.
  - Success: reverts to default or navigates to confirmation view.
  - Error: remains visible; error message shown near field or at top.

Ensure states respect accessibility and inclusive design guidance from `ux-design-principles` (e.g., clear focus states, non-color-only cues).[web:293][web:280]

---

### Step 5: Design error handling and recovery flows

Define how the system handles **errors and failures**, not just the happy path.[web:288]

Consider:

- **Validation errors** (user input issues):
  - What is validated on change vs on submit.
  - How errors are surfaced (inline messages, summaries, field highlights).
  - How to phrase messages (clear, specific, actionable).
- **System errors** (network, server, unknown):
  - What users see if a request fails or times out.
  - Whether and how they can retry.
  - Fallback behaviour if data is partially available.

For each likely error scenario:

- Describe the error condition.
- Describe what the user sees (message, visual cues).
- Describe how they recover:
  - Fix input and retry
  - Try again later
  - Contact support / follow alternative path

Follow heuristics from `ux-design-principles` around error prevention, error messages, and help & documentation.[web:288]

Make sure error handling doesn’t trap users; there should be clear paths back to safety or alternatives.

---

### Step 6: Account for edge cases and constraints

Consider **edge cases** and less common scenarios that might break the experience.[web:243]

Ask:

- "What happens if there is no data yet?"
- "What if there is a very large amount of data?"
- "What if the user loses connectivity mid-flow?"
- "What if the user has partial permissions or restricted access?"

For each edge case:

- Define what is shown (e.g., empty state with guidance, truncated lists with “show more”, permission messages).
- Specify which actions are hidden vs shown but disabled, and why.
- Ensure that the interaction remains understandable and doesn’t leak technical complexity unnecessarily.

Balance simplicity with control:

- Hide complexity by default but provide advanced options where needed for power users, clearly separated and explained (Tesler’s Law).[web:260]
- Avoid forcing all users into complex flows just to support rare edge cases.

---

### Step 7: Define system feedback and microinteractions

Specify how the system **responds** to user actions to communicate status and outcomes.[web:240][web:295]

For each key interaction (submit, save, upload, navigation change, destructive action):

- Define feedback type:
  - Immediate inline feedback (e.g., field turns valid/invalid).
  - Toasters/snackbars or banners for transient messages.
  - Dialogs for confirmations or critical errors.
  - Progress indicators (spinners, skeletons, progress bars).
- Define timing:
  - How quickly feedback appears after an action (consider the Doherty Threshold).[web:260]
  - How long transient messages remain visible.
- Define motion/animation (if any):
  - Simple, purposeful transitions (e.g., expanding/collapsing sections, sliding panels).
  - Avoid overly flashy or long animations that slow down tasks or conflict with reduced-motion preferences (see `ux-design-principles` motion and accessibility sections).[web:295][web:293]

Ensure feedback answers the user’s key questions:

- Did my action work?
- What is happening now?
- What should I do next?

---

### Step 8: Pattern selection and consistency

Choose and document patterns so similar problems are solved in similar ways.[web:243]

For recurring needs:

- Selection patterns (radio vs checkbox vs dropdown).
- Navigation patterns (tabs vs side nav vs breadcrumbs).
- Data manipulation patterns (inline edit vs edit forms vs modals).
- Confirmation patterns (inline messages vs dialogs vs undo).

For each pattern, note:

- When to use it.
- When **not** to use it.
- How it behaves across breakpoints or platforms.

Aim to reuse patterns from your design system and the platform guidelines captured in `ux-design-principles` (web, iOS, Android) before inventing new ones.[web:236][web:260] Only introduce new patterns when they provide clear, user-centred benefits and can be explained simply.

---

### Step 9: Create interaction specs for delivery

Produce clear interaction specifications that development and QA can use.

For each key flow or screen:

- Provide:
  - Step-by-step description of interactions (what user does, what system does).
  - State definitions for important components.
  - Error and edge-case handling.
  - Feedback and transitions.

You can express this as:

- Annotated screenshots or wireframes.
- A table listing:
  - Trigger (user/system action)
  - Condition (if any)
  - Result (state change, navigation, feedback)
- References to reusable patterns or components in your design system.

Where interaction changes are tied to outcomes, reference `ux-product-design-metrics` for relevant measures (e.g., task success rate, time on task, error rate, CES, engagement).[web:288][web:303]

Ensure that specs are easy to scan and update; avoid burying critical behaviour in long paragraphs.

---

## Examples

### Example 1: Form submission flow

- Core task: submit a multi-step application form.
- Interaction design:
  - Progressive disclosure: show sections step by step to reduce cognitive load.
  - Inline validation: validate required fields on blur and show errors with actionable messages.
  - States:
    - Draft, In progress, Submitted, Needs attention (if partial data).
    - Button states: Default, Loading, Disabled (when invalid).
  - Errors:
    - Network failure: non-blocking banner with retry.
    - Validation errors: field-level messages plus summary at top.
  - Feedback:
    - Success screen summarizing submitted data and next steps.
    - Email confirmation sent asynchronously.

### Example 2: Table with bulk actions

- Core task: manage many items at once (e.g., select and archive multiple records).
- Interaction design:
  - Pattern: checkbox selection column with “select all” and bulk action bar appearing when items selected.
  - States:
    - No selection: bulk bar hidden.
    - Some selected: bulk bar visible, actions enabled.
    - All selected: “select all” reflects state.
  - Edge cases:
    - Large datasets: selection persists across pages with clear messaging.
    - Limited permissions: some bulk actions disabled with explanations.
  - Feedback:
    - After actions, show status message (e.g., “12 items archived”) with an optional undo.

---

## Troubleshooting

### Interaction is too complex

- Identify unnecessary steps or controls and remove them (Occam’s Razor).[web:260]
- Group related actions into simple flows.
- Defer advanced options behind clear affordances (“Advanced settings”).

### Users miss key actions

- Check visual hierarchy and placement of primary actions (coordinate with layout skill and `ux-design-principles` on hierarchy and contrast).[web:230]
- Improve affordances (button styling, labels, icon + text).
- Consider progressive disclosure: only show some actions when relevant.

### Inconsistent behaviour across screens

- Audit flows for similar interactions implemented differently.
- Choose a single pattern and update specs to align.
- Link interaction decisions to design system components and platform guidelines where possible.[web:236]

---

## Notes for use with other skills

- Use this skill in combination with:
  - `ux-information-architecture` to ensure interactions align with structure and navigation.
  - `ux-design-principles` to ground decisions in laws of UX, heuristics, inclusive design, motion, and platform patterns.[web:260][web:272]
  - UI and design system skills to ensure visual treatments support the intended interactions.
  - `ux-product-design-metrics` and product experimentation skills when interaction changes are tested for impact on key metrics (e.g., task success, conversion, retention, satisfaction).[web:303][web:313]

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [mahirautela2020-design](https://github.com/mahirautela2020-design)
- **Source:** [mahirautela2020-design/claude-skills-ux](https://github.com/mahirautela2020-design/claude-skills-ux)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-mahirautela2020-design-claude-skills-ux-ux-interaction-design
- Seller: https://agentstack.voostack.com/s/mahirautela2020-design
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.