98 lines
2.8 KiB
Markdown
98 lines
2.8 KiB
Markdown
# 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.
|