building-ui-ux

$npx mdskill add microsoft/FluidFramework/building-ui-ux

<required> *CRITICAL* Add the following steps to your Todo list using TodoWrite:

SKILL.md

.github/skills/building-ui-uxView on GitHub ↗
---
name: building-ui-ux
description: Use when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
---

<required>
*CRITICAL* Add the following steps to your Todo list using TodoWrite:

1. Ask user if they want to experiment with multiple UI variations or see a single design
2. If user wants multiple variations, ask what kinds of variations to try
3. If building a web frontend and it's not running, start the dev server and note the localhost URL
4. Implement the UI/UX design(s)
5. Ask user for feedback on the design
6. Iterate based on feedback
7. Ensure the new UI is properly wired up and integrated
</required>

# Building UI/UX

## Overview

This skill guides you through implementing user interfaces and experiences with an emphasis on exploration, feedback, and proper integration.

**Core principle:** Explore variations, iterate with feedback, ensure proper integration.

**Announce at start:** "I'm using the Nori Building UI/UX skill to implement your interface."

## The Process

### Phase 1: Scope & Variation Planning

**Ask the user:**

"Would you like to:
- See multiple UI variations to choose from?
- Go with a single design approach?"

**If multiple variations:**
- Ask what kinds of variations they want (e.g., minimalist vs rich, card-based vs list-based, light vs dark)
- Aim for 2-4 distinct approaches
- Plan to implement all variations in a way that allows easy comparison

### Phase 2: Frontend Environment Setup

**For web projects:**

Check if the dev server is running:
- If not, identify the start command (e.g., `npm run dev`, `npm start`)
- Start the dev server
- Note the localhost URL (typically `http://localhost:3000` or similar)
- Inform user: "Starting dev server at [URL]"

**For other UI types:**
- Identify appropriate preview/testing mechanism
- Set up accordingly

### Phase 3: Implementation

**When implementing multiple variations:**

Stack variations in a way that makes comparison easy. For web UIs, this typically means:
- Render all variations on a single page, stacked vertically
- Add clear section dividers/headings for each variation
- Use consistent spacing between variations
- Ensure each variation is self-contained and functional

**Example for React:**
```tsx
export default function UIExploration() {
  return (
    <div className="ui-exploration">
      <section className="variation">
        <h2>Variation 1: Minimalist</h2>
        <MinimalistLogin />
      </section>

      <section className="variation">
        <h2>Variation 2: Modern Gradient</h2>
        <ModernLogin />
      </section>

      <section className="variation">
        <h2>Variation 3: Classic Corporate</h2>
        <ClassicLogin />
      </section>
    </div>
  );
}
```

**When implementing a single design:**
- Focus on clean, production-ready implementation
- Follow project conventions and style guides
- Ensure responsive design if applicable

### Phase 4: Feedback & Iteration

**Present to user:**
- Share the localhost URL or preview mechanism
- Briefly describe each variation (if multiple)
- Ask: "What do you think? Any changes you'd like to see?"

**Iterate based on feedback:**
- Make requested changes
- Continue asking for feedback until satisfied
- Be ready to combine elements from different variations

### Phase 5: Integration & Wiring

**Ensure proper integration:**

- Remove exploration scaffolding (if used)
- Wire up to actual data sources/APIs
- Connect to routing/navigation
- Add proper state management
- Implement error handling
- Add loading states if applicable
- Test all interactive elements
- Verify accessibility basics

**Common integration points to check:**
- Form submissions → backend endpoints
- Navigation → routing system
- Authentication → auth context/store
- Data fetching → API layer
- Error boundaries → error handling
- Responsive behavior → breakpoints

More from microsoft/FluidFramework

SkillDescription
api-changesUse when customer-facing API changes were made — i.e., API report .md files differ from main. Guides through release tag assignment, API Council review requirements, breaking change classification, deprecation process, and changeset guidance. Triggered automatically by ci-readiness-check when api-report diffs are detected.
brainstormingIMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
ci-readiness-checkUse when the user explicitly asks for a CI check or to push their branch — e.g. "ci readiness", "check ci", "pre-push check", "ready for CI", "ci check", "ready to push", "push my changes", "push the branch", "let's push". Catches common CI failures before pushing — formatting, stale API reports, missing changesets, policy violations.
creating-debug-tests-and-iteratingUse this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
creating-skillsUse when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
ff-oce-dashboardGenerate the OCE shift status dashboard. Triggers on: 'generate shift dashboard', 'show dashboard', 'shift status', 'status dashboard', 'what's going on', or any request for a NON-SPECIFIC overview of current OCE status (incidents, pipelines, errors).
ff-oce-kustoUse this skill for any Kusto query or telemetry investigation specifically related to Fluid Framework or its partners. Triggers include: writing or running a Kusto query against the Office Fluid database, investigating Fluid Framework telemetry or error rates, querying Office_Fluid_FluidRuntime_* tables, looking up a Fluid session by Session_Id or docId, investigating a Fluid-related error in Loop or Whiteboard telemetry, monitoring an FF bump or partner ring deployment, checking Fluid render reliability or Scriptor errors, or when the user mentions Fluid-specific tables (Office_Fluid_FluidRuntime_*, OwhLoads, HostTracker, Scriptor) or Fluid-specific error types (dataCorruptionError, dataProcessingError, DeltaConnectionFailureToConnect, ICE, ACE). Do NOT trigger for general Kusto questions that are not related to Fluid Framework.
finishing-a-development-branchUse this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR.
fluid-prUse when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on "create a PR", "make a PR", "open a PR", "submit a PR", or "push and create a PR".
fluid-pr-guideUse when composing, writing, drafting, or reviewing a PR title, PR description, or PR body in Fluid Framework — provides title style, body template, and section guidance.