How these interface studies work

Three ways to write an observation#

• Source review: explain papers, vendor research or firsthand accounts, with original figures, attribution and links.
• Interface reading: analyse a sourced screen, separating observation from interpretation.
• Our own observation: add actual tasks, screenshots or participant records and report what was tested.

Each can stand on its own. An experiment is one route, not a prerequisite for every article. Five illustrated readings show how others construct an argument.

The unit of analysis#

Give each product its own article. Separate web, desktop and mobile surfaces when their workflows differ. Study a defined flow inside the product: for example, inspecting an AI-generated change, comparing two source pages, or recovering from an accidental gesture.

Codex desktop is not the Codex CLI. Claude Chat, Artifacts, Cowork and Claude Code are different study scopes. iPhone, iPad and Vision Pro should each have a defined task and input method. Brand recognition alone does not provide a useful comparison.

What every article records#

• Person and goal: who is trying to achieve what, and in which context?
• Platform and version: operating system, web/desktop/mobile surface, application build if verified, relevant feature rollout and account conditions.
• Evidence dates: screenshot capture date when known, source publication date, research retrieval date and article revision.
• Task path: entry, action, feedback, result, correction and exit.
• Findings: helpful design decisions, friction, affected users and a proposed improvement.
• Validation: what observation or experiment could support or overturn the judgement?

If an app build is not disclosed, write unknown. A model name, API version or announcement date must not be substituted for the client build.

Six lenses for the critique#

1. Discoverability: can a person find the action needed for this task?
2. Mental model: do labels and controls explain where work happens and what an action means?
3. Feedback: can a person distinguish running, waiting, failure and completion?
4. User control and recovery: can they correct, stop or reverse the relevant operation?
5. Information structure: can they find a source or artifact without remembering a long path?
6. Accessibility and input: can the task be completed with the relevant keyboard, touch, assistive technology or spatial input?

These lenses adapt Jakob Nielsen’s usability heuristics to the task. For web accessibility, consult W3C’s WCAG 2.2 reference. A screenshot is useful for visual analysis but cannot prove semantic markup, focus behavior or screen-reader support.

For the planned spatial study, Apple’s visionOS design guidance provides a platform reference. Evaluate selection, sustained text entry and recovery separately rather than assuming that a novel input method improves every task.

Keep observation and interpretation distinct#

Observed: describe what is directly visible or what a specified hands-on task revealed. A screenshot of an address bar supports a statement about that screen; it does not prove every screen has the same affordance.

Documented: cite the official page that describes a feature or behavior. Record when it was read. Documentation may change or describe a rollout that is not available to every account.

Interpretation: explain how a design decision might help or hinder a particular user. Name the principle and the task consequence. Do not turn a plausible concern into an observed failure rate.

Proposed test: state how the interpretation could be checked. Report actual participants, tasks and measurements only after the work is done. Do not invent an overall score such as “9/10” without a defined rubric and evidence.

Pictures should carry evidence#

Use an official product image, an attributed public demonstration, or a personally captured screen with permission. Keep the original alongside any markup. Every figure needs descriptive alternative text and a caption identifying owner, source, relevant date, platform and known version limits.

Numbered overlays in the first two articles are editorial annotations placed over the original image. Their redesign panels are proposals, clearly labelled. A generated mockup must never be presented as a real client screenshot. The theme’s MIT licence does not relicense third-party product images.

In revision 1, the first two critiques each used one verified desktop demonstration. Auxiliary files retained with the research include a Codex CLI log and a Claude example report; these are not labelled as desktop interface screenshots. The image source register records source URLs, retrieval date and checksums.

Compare products fairly#

Finish individual articles before a cross-product comparison. Give the products the same goal, content, starting state and success criteria. Record account access and platform differences. A coding environment and a media feed have different goals, so a common leaderboard would conceal more than it explains.

Useful measures include task completion, time in seconds, wrong turns, errors, assistance and successful recovery. Define each measure in advance. Keep samples and uncertainty visible. Check whether a proposed simplification improves review and control, not merely the number of clicks.

Reviewing other people’s evidence#

Record authors, date, method, sample and product scope. Distinguish published papers, preprints, vendor logs and personal accounts. Attribute their tests to them and separate our questions.

Revision 2 adds a reviewer’s Codex screenshot and a Claude Code chart. The illustrated readings include five original examples, with a research image register. Keep original annotations and licences, and link to full texts rather than reproducing entire articles.

Update without erasing the past#

Keep a dated interface baseline. A minor correction can add an article revision note. A substantial interface change deserves a new observation section or a separate follow-up with before/after evidence. Preserve the old screenshot and identify which conclusions still apply.

Website releases are a separate record: a site revision describes navigation or language changes, while an article revision describes research evidence. Site updates · Study plan.