UI + UX Input And Data Entry established

Input prefix/suffix

Show a fixed prefix or suffix outside the editable value, describe its meaning in the label or hint, normalize duplicate typed affixes, validate the clean value, and store a predictable canonical payload.

Decision first

Choose this pattern when the problem matches

Use when

  • The value has a fixed currency, unit, percentage, domain, or commonly understood icon.
  • Users should enter only the clean value while the UI clarifies what that value means.
  • The affix reduces mental load without replacing the label or hint.
  • The product can normalize duplicate typed affixes and store a consistent payload.

Avoid when

  • The answer is open-ended or may not use the shown unit.
  • The unit or currency is user-selectable and needs its own control.
  • The affix needs a long explanation or is not commonly understood.
  • The implementation cannot communicate the affix meaning to assistive technology users.
  • The backend cannot distinguish clean value, unit, and formatted display value.

Problem it prevents

Users can misunderstand whether a value needs a currency symbol, unit, percentage sign, icon meaning, or domain, while systems often need the stored value without that repeated affix.

Pattern anatomy

What a strong implementation has to make clear

User need

The field asks for a value with a fixed unit, symbol, abbreviation, or icon meaning.

Pattern promise

Show a fixed prefix or suffix outside the editable value, describe its meaning in the label or hint, normalize duplicate typed affixes, validate the clean value, and store a predictable canonical payload.

Required state

Empty state with descriptive label and visible prefix or suffix.

Recovery path

Screen reader users hear only Amount while sighted users see a dollar prefix.

Access contract

Do not rely on the visual affix alone; include the unit or symbol meaning in the label or hint.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A Cost, in dollars field shows a dollar prefix outside the input, uses numeric input, and stores only the numeric amount.
  • A Weight, in pounds field shows lbs. as a suffix while the label names pounds for people who do not perceive the suffix.
  • A user types $1,250 into a field with a dollar prefix and the form normalizes it to 1250 with a clear status message.
  • A user switches from dollars to percent and the suffix, label, input mode, validation message, and submitted unit update together.
Weak implementation

Vague, hidden, hard to recover from

  • A field labeled Amount shows a hidden dollar prefix but the label never says dollars.
  • A suffix contains a long phrase that wraps into the input and looks like typed text.
  • A user types lbs after a weight value because they missed the suffix, then gets an error instead of normalization.
  • A user enters a non-monetary answer in a dispute-resolution field because the dollar prefix wrongly implied all answers are amounts.
UI guidance
  • Render the prefix before the input or suffix after the input as a non-editable visual affix, with a persistent label or hint that names the unit or symbol in text.
  • Style the input and affix as one field group for focus, error, disabled, and success states while keeping the user's editable value separate from the affix.
UX guidance
  • Use a prefix or suffix to reduce ambiguity when users must enter only the value and the unit, currency, percentage, or domain is fixed.
  • Tolerate users typing the visible affix into the field by normalizing duplicate symbols or units instead of producing an avoidable error.
Implementation contract

What the implementation must handle

States

  • Empty state with descriptive label and visible prefix or suffix.
  • Focused state where the input and affix read as one field group.
  • Filled state with the user's clean value and visible affix.
  • Duplicate affix typed state normalized without an unnecessary error.

Interaction

  • The affix is visible near the input but not editable as part of the field value.
  • Typing, paste, selection, undo, and deletion affect only the user's value, not the affix.
  • If the user types the same affix, the system normalizes it or preserves the value with a clear, fixable message.
  • Submitting validates the canonical value and unit together.

Accessibility

  • Do not rely on the visual affix alone; include the unit or symbol meaning in the label or hint.
  • If affixes are hidden from screen readers, ensure the accessible name and description remain complete.
  • Keep the affix visually grouped with the input at high zoom and in forced colors.
  • Use text labels for ambiguous icon affixes or avoid the icon.

Review

  • Is the affix a fixed, common symbol or unit that users will understand?
  • Does the label or hint communicate the same meaning without relying on the visible affix?
  • What happens when users type or paste the affix into the value?
  • What exact value and unit does the backend receive?
Interactive lab

Inspect the states before you copy the pattern

Keep a fixed unit outside the typed value

Switch between prefix and suffix modes, type values with and without the visible affix, inspect canonical payload, and trigger missing-value validation.

Input prefix/suffix
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Empty state with descriptive label and visible prefix or suffix.

Keyboard / Access

Tab focuses the input, not the static prefix or suffix.

Avoid Generating

Relying on a visually hidden or decorative affix as the only way users know the unit.

Evidence trail

Source-backed claims behind this guidance

U.S. Web Design System: Input prefix/suffix

U.S. Web Design System - checked

USWDS supports affixes for common symbols, units, abbreviations, and icons, with descriptive labels because affixes are hidden from screen readers.

Material Design: Text fields

Google Material Design - checked

Material Design supports prefixes and suffixes as formatted text-field elements for units, currency, domains, and time zones.

Maersk Design System: Input masks

Maersk Design System - checked

Maersk supports the boundary that prefix/suffix is preferred over a mask when a constant value is grouped with the typed value.

Full agent/debug reference

Problem Context

  • The field asks for a value with a fixed unit, symbol, abbreviation, or icon meaning.
  • The affix is common enough to clarify the value without a long explanation.
  • The user should enter only the value, not the unit or symbol.
  • The backend expects a canonical value and unit rather than an arbitrary combined string.
  • Screen reader and voice users still need the unit or symbol in the label or hint because the visual affix may be hidden.

Selection Rules

  • Choose input prefix/suffix when a common fixed symbol, unit, abbreviation, domain, or icon clarifies what the text input accepts.
  • Use ordinary text input when the answer is open-ended or the affix would over-constrain legitimate responses.
  • Use input mask when the value itself needs live character grouping, inserted literals, or fixed slots.
  • Use inline validation when the field can accept normal text first and only needs a correction message after interaction.
  • Use select, radio group, or segmented control when users must choose between multiple units or currencies.
  • Use hint text instead of an affix when the explanation requires more than a short, common symbol or abbreviation.
  • Keep the affix outside the submitted editable value unless the product explicitly stores a formatted display string.
  • Name the unit or symbol in the label or hint because assistive technologies may not announce decorative affixes.
  • Allow users to type the visible prefix or suffix and normalize it when unambiguous.
  • Place validation state on the whole input group so the affix and text field read as one field.

Required States

  • Empty state with descriptive label and visible prefix or suffix.
  • Focused state where the input and affix read as one field group.
  • Filled state with the user's clean value and visible affix.
  • Duplicate affix typed state normalized without an unnecessary error.
  • Invalid numeric or missing value state with group-level error styling.
  • Success state showing accepted canonical value and unit.
  • Disabled or readonly state where the affix remains visually associated with the value.
  • Changed-unit state when another control changes which affix is active.
  • Mobile state with correct keyboard for the clean value.
  • Assistive state where the label or hint communicates the affix meaning.

Interaction Contract

  • The affix is visible near the input but not editable as part of the field value.
  • Typing, paste, selection, undo, and deletion affect only the user's value, not the affix.
  • If the user types the same affix, the system normalizes it or preserves the value with a clear, fixable message.
  • Submitting validates the canonical value and unit together.
  • Errors and success states apply to the input group, not only the inner input border.
  • Changing unit mode updates the label, hint, affix, validation, and payload together.
  • Copying the field value has a documented behavior: clean value only or formatted value, but not inconsistent by field.

Implementation Checklist

  • Define the clean value, affix text or icon, unit metadata, submitted payload, accepted duplicate-affix forms, and copy behavior.
  • Put the affix outside the input element and keep it visually grouped with the control.
  • Use a visible label or hint that names the unit, currency, percentage, or icon meaning in text.
  • Set inputmode, type, pattern, width, autocomplete, and validation for the clean value without the affix.
  • Normalize common duplicate inputs such as $1200, 1200 dollars, 12%, or 12 percent when the affix already represents that unit.
  • Apply error, success, disabled, readonly, and focus styles to the whole input group.
  • Test screen readers, voice input, paste, browser autofill, mobile keyboards, forced colors, zoom, RTL layouts, and backend parsing.

Common Generated-UI Mistakes

  • Relying on a visually hidden or decorative affix as the only way users know the unit.
  • Rejecting values that include the same prefix or suffix users saw next to the field.
  • Using a prefix or suffix for an open-ended answer that may not use that unit.
  • Putting long explanatory copy in the affix instead of the hint.
  • Storing the affix in one payload but stripping it in another.
  • Using a static suffix when users can change the unit elsewhere.
  • Making an icon affix ambiguous without a text label or hint.

Critique Questions

  • Is the affix a fixed, common symbol or unit that users will understand?
  • Does the label or hint communicate the same meaning without relying on the visible affix?
  • What happens when users type or paste the affix into the value?
  • What exact value and unit does the backend receive?
  • Would a mask, picker, unit select, hint, or ordinary text input be less ambiguous?
  • Do error and disabled states visually include the affix?
Accessibility
  • Do not rely on the visual affix alone; include the unit or symbol meaning in the label or hint.
  • If affixes are hidden from screen readers, ensure the accessible name and description remain complete.
  • Keep the affix visually grouped with the input at high zoom and in forced colors.
  • Use text labels for ambiguous icon affixes or avoid the icon.
  • Associate errors and hints with the input and style the whole group for invalid state.
  • Ensure voice input users can dictate values without needing to speak hidden decoration.
Keyboard Behavior
  • Tab focuses the input, not the static prefix or suffix.
  • Typing, deleting, selection, paste, undo, and redo affect only the editable value.
  • Arrow keys do not move focus into the affix.
  • Submit with an invalid value moves focus to the error summary or the affixed input without losing the typed value.
  • If the suffix includes an action, such as password visibility, it must be a separate reachable control with a clear label.
  • Unit-changing controls before or after the field must have predictable tab order and update the affix without moving focus unexpectedly.
Variants
  • Currency prefix
  • Percentage suffix
  • Weight suffix
  • Length suffix
  • Email domain suffix
  • Icon prefix
  • Password visibility suffix
  • Error state affixed input
  • Success state affixed input
  • Unit-switching affixed input

Verification

Last verified: