# UX Requirements

## Design direction

Clean, minimal, catalog-focused, and responsive.

The homepage is intentionally search-first and visually similar in simplicity to a search engine landing page.

## Public information hierarchy

For cards:
1. Primary image
2. Product/item name
3. Market value
4. Asking price

The asking price is the primary seller decision value; market value provides context.

## Product grouping

Multiple physical copies of one Product are grouped together.

Example:

```text
Charizard ex #199/165
  Near Mint    $115 asking    $120 market
  Lightly Played $95 asking    $90 market
  + 1 More Available
```

Copies are sorted by condition quality, best first.

Selecting the group can reveal all copies.

Do not create separate Product groups solely because condition differs.

## Inventory management

Admin uses search plus filters and saved views.

Recommended saved views:
- Needs Attention
- Recently Added
- High Value
- Sold This Month

Bulk selection should be available where safe.

## Guided creation

`Find/Create Product → Link Market Sources → Inventory Details → Images → Pricing → Review → List`

The workflow should make it clear whether the user is editing the Product or the physical Inventory Item.

## Locked states

Pending and Sold items are visibly locked against ordinary edits. Controlled actions such as correcting a sale remain available through explicit workflows.

## Public sold items

Sold items show Sold status and no asking price.

## Responsive behavior

Support desktop, tablet, and mobile. Layouts should adapt rather than simply shrink desktop controls.

## Feedback

Dynamic actions must provide accessible status feedback, including:
- loading
- success
- validation error
- provider failure
- image processing
- background job progress

Avoid relying on color alone.

## Settings recovery

Do not show editable defaults until Settings has loaded successfully. A failed
load offers a keyboard-accessible retry and announces the error. After retry,
focus moves to the first form field on success or back to Retry on failure.
Saving announces progress and temporarily disables the form to prevent duplicate
submissions and edits being overwritten by the save response. A failed save
keeps entered values available for correction or retry.

## Saved Views recovery

Show the create form and saved-view list only after a successful load. Failed
reads show an error and Retry, not an empty-list message. Keyboard retry returns
focus to Name on success or Retry on repeated failure. Failed creation retains
the draft; failed deletion retains the view and returns focus to its Delete
button. Successful deletion announces completion and focuses the list heading.
Mutations announce progress, disable conflicting actions while pending, and clear
stale errors/success messages before a new attempt.