DEV Community: 杨宗历

Designing a Political Quiz UI That Shows Its Assumptions

杨宗历 — Wed, 14 Oct 2026 08:21:08 +0000

Scope of this review

This is a black-box review of the public interface. It does not describe source code, a private scoring algorithm, or a verified psychometric model. The visible page presents 48 statements on a five-point scale, grouped by axis, and describes a 12-axis result. It also says that answers are calculated in the browser. These are public interface claims, not independently audited implementation facts.

That distinction matters for political self-assessment. A polished chart can look more authoritative than the questions behind it. The interface should make its model and limits easy to inspect.

Keep three states visible

A useful questionnaire UI needs to communicate at least three different things:

Answer state: which items the person has answered, skipped, or changed.

Interpretation state: how answers relate to each displayed axis.

Context state: which parts of the result depend on a country-specific reference.

If the interface compresses all three into one label, users cannot tell whether a result reflects their answers, the test’s categories, or a localized comparison. A map with separate axes is easier to question than a single unexplained badge.

Treat political labels as interpretations

The page includes comparisons with PSOE, PP, VOX, and Sumar, described as editorial references for Spain. A test result should distinguish this kind of comparison from a poll, endorsement, or recommendation. The UI should also make it possible to read the underlying positions before displaying a party match.

For a design review, ask whether users can answer these questions without leaving the result screen: What does each axis mean? Which end of the scale is represented? Is a percentage a similarity score or a vote prediction? Which country and reference date does a party comparison assume?

A compact acceptance matrix

Area

Example check

Expected behavior

Completion

One answer is skipped

The result does not silently present an incomplete profile as complete

Revision

An answer changes

The displayed axes update or explain when recalculation occurs

Interpretation

A party match is visible

The page labels it as an editorial comparison, not advice

Context

A reader is outside Spain

The geographic scope remains clear

Privacy

The page claims local calculation

The actual network behavior should be checked separately

The last row is intentionally a test question. A visible privacy statement is useful, but an interface inspection alone cannot prove network behavior. If privacy is a release requirement, verify it with a network-level test and document the result.

A useful public example

12ejes organizes its explanation around 12 axes, including economy, rights, borders, ecology, taxation, Europe, work, digital policy, housing, and security. That breadth can help readers notice that two positions may point in different directions.

The Test Ideologia Politica also illustrates a key UX boundary: its party comparison is explicitly framed as indicative, and the page tells readers to consult official proposals before deciding. That boundary belongs close to the result, where people are most likely to overread a score.

Questions to carry into implementation

Before building a similar product, define how incomplete answers work, how uncertainty is communicated, how country references are updated, and how a user can inspect the scoring model. Then test the language with people who hold mixed views, not only with people who already identify with a familiar label.

The interface is not neutral merely because it uses numbers. Its question wording, axes, examples, and defaults all shape what users see. Make those choices inspectable, and treat every result as a conversation starter rather than an identity assignment.

Designing a Scenario-Driven Tier List UI Without Pretending It Is a Meta Engine

杨宗历 — Tue, 18 Aug 2026 08:29:48 +0000

The interface contract

An editable tier list looks simple until the user tries to answer a real question. “Rank these characters” is underspecified. A useful interface must let the user define the scenario, narrow the pool, place items, revise decisions, and export a readable result.

The public HSR editor is a useful black-box example. Its visible contract includes a title field, a prepared pool of 95 character portraits, search/filter affordances, tier rows, local-save status, undo/redo, share-link and preview controls, and PNG export choices. That is an interface observation, not a claim about the private framework or data model.

Model the states before the components

The core state is not “a list of cards.” It is a relationship between a scenario, a pool, ordered tiers, and export state:

type RankingState = {

title: string;

pool: { id: string; label: string; included: boolean }[];

tiers: { id: string; label: string; itemIds: string[] }[];

history: { past: unknown[]; future: unknown[] };

save: 'idle' | 'saved' | 'dirty';

};

The type above is a design proposal. It is not an extraction of source code. The important behavior is that moving an item updates one tier without duplicating it, reset is distinguishable from undo, and an export preview does not silently mutate the ranking.

Interaction questions worth testing

Can a keyboard or touch user identify where an item will land?

Does filtering hide items in a way that is reversible and obvious?

Does a share link preserve title, labels, colors, and positions?

Can a user recover from an accidental move without losing later work?

Does the exported image preserve hierarchy at square, landscape, and portrait sizes?

These are testable contracts even when implementation details are unavailable. They also reveal why “drag and drop” alone is not a sufficient feature specification.

A small test matrix

For a practical starting point, Rankly shows how a focused ranking surface can keep prepared content and editing controls together. The relevant page is the HSR Tier List Maker, which frames the board as a personal ranking rather than an official meta verdict.

Scope is part of quality

The page explicitly focuses on HSR character portraits. W Engines, Bangboo, builds, and equipment advice are outside the visible scope. A trustworthy product does not need to imply that every adjacent problem is solved; it needs to make the supported state machine understandable.

Designing a Pokémon Tier List UI: States, Filters, and Honest Scope

杨宗历 — Mon, 17 Aug 2026 08:48:07 +0000

A tier-list editor looks simple until the user has more than a few cards. The engineering problem is keeping the user’s question, pool, and output understandable.

Model visible states

The interface needs an unranked pool, ranked tiers, an empty state, and a saved/exportable state. Rankly visibly includes an unranked library, S–D tiers, local saving, undo/redo, sharing, and PNG export. These are interface observations, not claims about private architecture.

Treat filtering as first-class

For a 1,025-entry roster, search alone is not enough. Combine generation, type, category, and final-evolution filters, and show what pool is currently visible.

Make ranking semantics explicit

“S tier” is a display label, not a definition. A title field and custom tiers let users state “Gen 1 favorites” or “Nuzlocke viability.”

Test the transitions

Move a filtered result into and out of a tier.

Clear filters and verify the expected pool.

Add or rename a tier without losing placements.

Verify undo and redo cover advertised actions.

Verify save, share, and export feedback.

Check the primary actions on small screens.

The Pokemon Tier List Maker is a context-specific visual ranking tool, not automatically a competitive database. Expose the state, expose the scope, and test the transitions users can see.