App icons and interface components

Answered 5 October 2026: both recommendations accepted. An app's identifying icon, the symbols inside its interface and its buttons are all useful research subjects. The old App Icon Suite entry combined them. These choices make their scope clear without turning every interface fragment into a new content type.

The recommendations below are the accepted meanings. Examples and alternatives remain as the review record; these choices need no further answer.

Choice	Recommendation
App Icon Suite	Use App Icon for the identity description; distinguish interface icon sets.
Buttons, forms and navigation	Make Interface Components searchable by component kind, keeping supported guidance and observed examples distinct.

What is already settled

Icon System is already an approved whole-piece type name. Your original approval and the list you reviewed have been recovered. This page does not ask you to approve it again or claim its detailed definition and storage are finished.

Useful parts may be independently browsable with a link to their source. A captured screen remains distinct from the product it depicts. A documented rule remains distinct from our interpretation. Those relationships carry forward.

The design-system review is answered: Digital Design System has supported platform scope, and Responsive Layout Rules remains searchable. The two icon and component choices below are now also answered.

1. Separate the app's identity from symbols inside it

Recommendation: replace the mixed App Icon Suite description with App Icon. It describes the artwork used to identify an application, including supported platform and appearance variants. Keep interface icon sets distinguishable: their symbols identify actions, objects or modes within an interface. A set may be a piece of Icon System work; a screen that contains some icons is not automatically that whole piece.

Checked example: Apple's App icons guidance concerns recognizable app identity. Its separate Icons guidance concerns symbols used within an interface. The former also describes different platform masks and appearances. That supports keeping the purpose and platform context rather than assuming one universal shape.

Counterexample: a search symbol inside a phone screen is not the app's identifying icon. An app icon shown inside an advertisement can be described as a visible element without making the whole advertisement an Icon System. A similar-looking mark does not prove that two applications share one identity system.

Alternative: use a broader Digital Iconography description and narrow it by intended use. This keeps fewer top-level words but makes the distinction less visible. I recommend App Icon because people may specifically want to compare how applications identify themselves.

What changes downstream: retain which application the icon identifies when supported, the source, and any documented variant relationship. Collection can link an original asset, its guideline and a screenshot showing it. Analysis must distinguish visible presence from the work of designing an icon family. Search can then find app identities or interface icon work without copying the same piece. Favicon and Avatar are not silently made synonyms; their remaining definitions stay open.

2. Make components findable without losing their context

Recommendation: keep Interface Components as a searchable description, with component kinds such as Button, Form and Navigation. It can describe a useful component example or documented component guidance. Preserve which of those the source supports. Do not automatically create a whole-piece content type for every button or interaction state.

Checked example: Carbon's Button guidance documents variants, labels and interaction behavior for a named component. A researcher could find the button guidance directly, then return to the wider system. The page also distinguishes some proposed examples from production availability; documentation alone does not prove that a particular product implements every example.

Counterexample: one screenshot containing a button does not establish its hover state, keyboard behavior or membership in a named design system. A rounded rectangle printed on packaging is not an interface button merely because it looks like one.

Alternative: keep component details only in descriptions attached to broader web or app design systems. That is a smaller maintained vocabulary, but makes focused searches across button or navigation examples less reliable. I recommend searchable component kinds, with their exact vocabulary reviewed before implementation.

What changes downstream: preserve a component's documented definition, an observed instance and the piece containing it as different facts. The existing useful-part rule allows a relevant excerpt to be found independently without duplicating its parent. Source evidence must support any system, product, version or state relationship. Search and tracker rules should use the same meanings. A cited answer about behavior must point to the relevant guidance or observed interaction, not infer behavior from a still image.

What happens next

Both descriptions and their boundaries are approved in the decision record. It does not approve the complete component vocabulary, a mandatory hierarchy, database changes or a completed pipeline.

The evidence note records the recovered approval, selected system checks and a confirmed guideline-text mismatch that needs an engineering investigation. The review desk holds the other independent packets. Existing pending questions remain answerable without being sent again.

Prepared 5 October 2026.

Last reviewed 5 October 2026.