You design products continuously for the same user. These are preferences confirmed through multiple rounds of actual interface feedback, not a general aesthetics ranking. First use the confirmed taste to produce a usable interface, then improve it based on specific feedback; do not repeatedly ask about a style that has already been made clear.
Taste also includes "how information is organized and how operations fit the purpose." First let the interface answer the user's questions, then decide on appearance; do not just add a layer of theme after the functionality is done.
Usage and Reading
- Read this file first each time: it is the entry point for general preferences and the scenario index; for specific scenarios, load only the corresponding rules.
- When multi-series charts or tooltips are involved, must-read patterns.md §1's focus linkage and acceptance requirements; for filtering, state history, responsiveness, etc., read the corresponding sections as needed.
- When it involves who used what resources, consumption attribution, joint rankings, or multi-dimensional investigation, read S04 Analysis and Investigation Workbench. When metric aggregation, snapshot collection, history retention, or restart recovery needs to be handled, read as needed Data and Runtime Conventions。
- When the user gives new aesthetic feedback, approves a new solution, or asks you to remember it, read evolution.md, and update the actual loaded copy of this skill.
- For installation, explicit invocation, and cross-server migration, see README.md. All design knowledge is carried along with the directory.
- The explicit requirements of the current task take precedence over the default taste; brand requirements, accessibility, and local project constraints need to be satisfied at the same time.
Quick Index of User Questions
When the user reports a problem, first go directly to the corresponding pattern by symptom, reproduce their actual data density, then choose the smallest fix. Do not require predicting all problems in advance, and do not force every local solution to apply to all pages.
| Symptom described by the user | Consult directly |
|---|---|
| Legend button lit/unlit does not match curve visibility; some are grayed out but still visible | patterns.md §1: Legend toggle selects by name; duplicate series names cause disconnection |
| The baseline/starting point is drawn as a lone dot and does not participate in the curve | S03 §2: Scalar fixed values are drawn as a water-level reference line; first determine mutual exclusivity, then choose pagination or overlay |
| The bar chart shows nothing useful / want to remove it; want to see a line chart | S03 §1.6 / §3: The line chart is the main view; put the metric selector in the header of the line chart |
| Datasets/methods are made select-one-only; want to view both at once but be able to hide them | S03 §1.3 / §2: One chart per dataset + visibility toggle; only experimental batches are mutually exclusive |
| The curve is highlighted, but the info box does not highlight the corresponding entry; other entries are not dimmed | patterns.md §1: Unified focus and real-hit acceptance |
| The tooltip blocks the line chart and other lines cannot be clicked; too much information to see fully and cannot scroll; the canvas is too small when two charts are side by side | patterns.md §2.1: Detail occlusion in dense charts |
| Information is moved below the chart, requiring the user to look down, losing the intuition of viewing on hover | patterns.md §2.1: Restore the floating layer near the target, prioritizing enlarging the canvas, automatic avoidance, and height-limited scrolling |
| The rightmost info box is squeezed narrow, names wrap, and it exceeds the boundary | patterns.md §2: Natural width and positioning flip |
| Filters require repeatedly scrolling to the top of the page | patterns.md §3: Filters stay close |
| There are separate object/resource/service rankings, yet it's still impossible to find out who did what through what | S04 §1–§2: Deriving joint rankings and combined detail from relationship questions |
| Want to merge a distinction while also expanding layer by layer to find the cause | S04 §3: Different semantics of dimension aggregation and collapsible drill-down |
| Status/action also appear in the resource list, filters contradict each other | S04 §4: Semantic deduplication and dependency filtering |
| After expanding or paginating, subtotals don't add up, and filters are lost after going back | S04 §5–§6: Complete subtotals, state continuity, and troubleshooting path acceptance |
| Aggregated ratios, peaks, deduplicated counts, or direct sums don't add up | Data and operational conventions §1: Metric merge conditions |
| Snapshot polling, missing measurements, rolling windows, and historical figures after restart are untrustworthy | Data and operational conventions §2–§3: Collection deltas, time boundaries, and quality states |
| The page is done, but historical retention, process restart, or upgrade recovery hasn't been verified | Data and operational conventions §4–§5: Persistence and operating modes |
First determine what the interface should help accomplish
- From the user's goal, write an operational path of "compare what → how to locate → what evidence to view."
- Check whether the data contains the required relationships; multiple independent totals do not equal one combined detail view.
- Choose tables, grouped trees, trends, or states according to the task, and read the applicable scenarios. Don't just pile up total cards and charts first because it's called a dashboard.
- Distinguish filtering, aggregation, collapsing, and legend visibility toggling; control names should match actual effects.
- Complete the entire operation with one real problem, then check the visual, keyboard, and narrow-screen behavior.
Currently confirmed design preferences
| ID | Scope | Users like | Users dislike |
|---|---|---|---|
| T01 | Work-oriented interfaces, admin consoles | Compact, layered light white/gray interfaces, small controls, vertical lists and tables; moderate blue accents; use S02 card layout when content is mainly images/previews | Stacking large cards for a small amount of text, excessive whitespace, attention-grabbing everywhere |
| T02 | All product controls | Proportional sans-serif UI fonts; fields, item names, and attribute key-values also presented naturally | Monospace fonts + square outlines + dense hard frames creating a Markdown code block/terminal feel |
| T03 | Forms, filters, buttons | Soft gray backgrounds, subtle borders, moderate rounded corners, light shadows, clear hover/focus/selected states | Every element looks like an independent code box; high-contrast thick outlines, heavy shadows |
| T04 | Overall consistency | Navigation, overview, lists, details, settings, and statistics share a visual language | Beautifying only one page while other pages retain the old code-box style |
| T05 | Multi-series charts (bars, lines, data points, including dense curves without dots) | When hovering over or selecting a target, the graphic, the corresponding tooltip entry, and the legend highlight in sync, while the rest fade in sync; clicking can lock it. For specific states and acceptance, see patterns.md §1 | Only graphics highlighted while tip entries have the same weight; axis hover highlights all series together; excessive animation |
| T06 | Information readability | Latest data on the right is prioritized and easy to read; chart details float nearby, automatically avoid collisions, and can scroll when there are many entries, see patterns.md §2.1 | Being flush against the edge squeezes names into multiple lines and splits words; moving floating details below the chart without permission to avoid occlusion forces the gaze away from the data point |
| T07 | Operation distance | Filters stay close to the chart they control; when necessary, provide local filters synchronized with the top | Repeatedly scrolling up and down across two charts for filtering; the two filters each hold a conflicting state |
| T08 | Ordered lists, dense status history | Direct drag-and-drop sorting; for dense states use a thin rectangular red-yellow-green history light strip, a sufficiently long time axis, and hover explanations; for sparse and jumpable states use S02 | Only buttons can adjust sorting; dense history is shortened by thick light blocks; colors have no explanation |
| T09 | Preview-style workbench, cards and theme | Cool gray-blue canvas, white panels, blue-purple accents; large rounded rectangles with soft thin borders; proportional fonts, restrained buttons and light overlays, see S02 | Compressing all content cards into dense tables; making large rectangles into pills; heavy strokes/heavy shadows |
| T10 | Daily time point selection | Explicit 24-hour format 00–23; default minutes for newly added times 00, allowing other minutes to be actively selected |
AM/PM toggle; after an empty value pops up, minutes follow the current time; default values are mistakenly added as time points when saving |
| T11 | Research metrics and curves dashboard | The left filter bar and top server switcher are approved; charts prefer bright blue-purple, cyan, and green, with clear line charts; line charts are the main view for metric comparison; visual acceptance is independent of functional acceptance | Reject the "plastic feel" of layer upon layer of cards and stacked pills, and also reject dark, heavy chart color schemes; reject horizontal bar charts for multi-run metrics; do not mistake rejecting container styles for rejecting bright chart colors |
| T12 | Multidimensional analysis and troubleshooting workbench | Organize joint rankings from the relationships to be investigated; when needed, support both dimension merging and hierarchical collapsing, inheriting filters to view combined trends/details | Each dimension is ranked separately but cannot be correlated; columns are only hidden rather than aggregated; actions and resources are mixed in the same filter; the interface is not derived by function |
Scenario index
| Scenario ID | Confirmed scenario | Rule location | Scope of use |
|---|---|---|---|
| S01 | Light information-dense interface: forms, lists, tables, data charts, status timelines | Visual baseline of this document + patterns.md | read selectively according to the required components, not requiring all components to be included at the same time |
| S02 | Cool gray-blue preview-style workbench: theme, card gallery, sparse jumpable states | preview-workbench.md | Theme and basic elements can be reused across scenarios; card/status block density is chosen according to content and coexists with S01 |
| S03 | Scientific research metric plotting: data shape→graphic mapping, family overlay vs pagination mutual exclusivity, reference lines | research-charts.md | Experiment metric dashboards, training curves, method comparison charts; used together with S01 chart rules |
| S04 | Analysis and troubleshooting workbench: relationship question→joint ranking→aggregation/hierarchy→details | analytical-workbench.md; data and runtime conventions are read selectively according to S04 §6 | Multi-dimensional investigation such as usage, resources, cost, and runtime attribution; not a fixed template for all dashboards |
After a new scenario has gone through actual design and feedback, incrementally add index entries. When there is little content, add a subsection within the existing pattern; when an independent style or more rules emerge, then create scenarios/<scene-name>.md, record the applicable scope, confirmed preferences, counterexamples, and interaction points, and link here. Do not create empty scenarios in advance, and do not automatically promote new scenario rules to global defaults.
Reference examples
| Example | Location | Content |
|---|---|---|
| Experiment metrics dashboard (desensitized) | research-dashboard.md | Complete implementation example of S03: data model, page structure, form→drawing method comparison table, pitfall checklist. Dataset/method/platform names have all been generalized |
Examples only carry structure and decisions; do not copy the style values of a specific project. Put new examples in examples/, remove local project information, and keep them readable by anyone.
How to use visual references
- The user explicitly mentioned NewAPI、Firecrawl、Mixedbreadand likes its modern, lightweight, natural product UI feel.
- Take its sans-serif typography, grayscale surfaces, restrained borders, selection feedback, and information organization, but do not copy the brand colors, marketing homepage layout, or specific components.
- Compact navigation + list/table is the baseline for information-dense interfaces, but it does not mean every product should adopt this layout.
- Existing UIs already approved by the user should be distilled from the real frontend source code first: theme tokens, font inheritance, border radius, borders, button states, and component structure; the browser is used for interaction and presentation verification, not as a replacement for source code analysis.
- When a new page needs reference, actual pages can be searched; do not claim to have researched if you have not visited. Internet access is not a prerequisite for using this skill.
Visual implementation baseline
Below arestarting reference values for interfaces already approved, not hard rules that every scenario must copy.
| Item | Starting point | Adjustment principle |
|---|---|---|
| Font | System UI font:-apple-system, BlinkMacSystemFont, "Segoe UI", "Noto Sans", sans-serif |
Prefer a suitable font already used in the project; no need to download a new font |
| Surfaces | canvas #f7f8fa；panel #fff；control #f3f4f6 |
Hierarchy comes from slight grayscale differences; do not put a frame around every cell |
| Text | primary #252b35；secondary #626c7b |
Auxiliary text still needs to be readable; do not use low contrast to create a "premium feel" |
| Borders/emphasis | border #e9ecf1；accent #3b63dc；selected #edf2ff |
Blue is used for primary actions/selection; status colors only carry status |
| Border radius | Controls about 8–10px, panels about 10–14px, short status labels can use pills | Restrained and consistent; do not make all large containers pill-shaped |
| Density | Compact form text about 12–14px, control height about 32–36px; body text scales up by scenario | Increase hit areas for small screens/touch targets; making text smaller is not what makes something compact |
| Motion | hover/focus about 120–180ms, chart bars slightly scale about 1.02–1.07 | No layout shift; follow prefers-reduced-motion |
| Numbers | UI font + font-variant-numeric: tabular-nums |
Number alignment does not require the whole page to be monospaced |
Specific controls
- Input/selector: soft gray background, thin or transparent border, non-monospaced font; focus can become white background with a clear focus ring. Selectors have a natural small arrow.
- Segmented control: gray track + light/white active item, subtle shadow; selection conveyed by background/text color, not a thick border.
- Multi-select menu: light overlay, rounded search box, full-row hover, clear checkbox selected state and selected count; native semantics preferred.
- Table: light header, thin row dividers, subtle row hover; property names displayed directly, no code font/code background needed.
- Ordered list: compact rows, ordinal numbers, primary name + secondary info, discoverable drag handle; also provide keyboard sorting or a button alternative.
- Status label: soft colored background + readable text, with a dot or icon; do not let color be the sole source of information.
- Daily time points: use T10; prefer reusing existing controls, and when native time cannot reliably display 24-hour format, native hour/minute selects may be used. The default minute does not mean the user has selected an hour; for specific behavior see patterns.md。
- Cross-page: modify in the shared tokens/components/style layer, then handle dedicated overrides; don't pile up a global
!importantoverride to mask conflicts. - Real code editors, raw log text, etc. may still use monospace; "disliking the code-block feel" does not equal altering the presentation requirements of real code.
Working approach
- Understand the current state: first clarify the judgment and actions the user needs to complete, then read the actual pages, data relationships, shared styles and interaction flows. Investigate information organization, filtering meaning, inherited font, hit layers or overlay positioning according to the problem, not just the appearance.
- Minimal implementation: reuse the existing tech stack, native controls, CSS/SVG or installed chart libraries. Do not build a separate component system, switch frameworks, or add dependencies just for appearance.
- Complete experience: consider loading/empty data/failure/disabled/selected/hover/focus/small screens together; keep graphical display and real data meaning separate.
- Browser-based verification: use an available browser to inspect the real pages, prioritizing the paths users use most, such as the rightmost latest bar, long names, menus flush to the edge, and returning to the original position after filtering. Check the console and layout, not just whether the code compiles.
- Interactive preview: use local drafts or independent demo data to check editing, dragging and state changes, clearly distinguishing preview from formal submission.
- Re-verification scope: changes to shared CSS require checking all consuming pages, including pages that are already satisfactory; run the checks required by the codebase you are in. No need to create a new test framework just to change colors.
- Delivery and learning: briefly explain the changes and the evidence. When clear preference feedback is encountered, update according to the evolution protocol; "technical verification passed" is not "the user has approved the aesthetics".
Scope boundaries
- Record only visual preferences, information organization, component interaction and accessibility; always express cases in general UI language.
- Choose components according to requirements; do not create dashboards, status timelines or trend curves by default.
- The current default baseline comes from light-colored data/configuration products; S02 provides a same-style dark pairing reference, which does not mean all dark scenarios have been approved. New scenarios such as native mobile, editors and marketing pages need to form their own branch rules, and should not be arbitrarily applied.
- New user feedback can change these default values; supports querying, adding, modifying, and deleting by scenario. The main file stays concise and presents only valid rules, managed and updated by evolution.md .