Use case guide

This guide shows how to write clear use cases for Lucide icons.

Write from the interface's perspective

Describe what the interface tells the user. Do not write from the contributor's point of view.

Indicating a device is offline or unreachable

Do

This describes the role the icon plays in an interface.

I need an icon for my offline device screen

Don't

This explains the contributor's situation, not the icon's purpose.

Describe real usage, not the icon name

A use case should explain what the icon means in context. Do not repeat the icon name or only describe the drawing.

Representing processors, chips, or embedded hardware

Do

This explains microchip without repeating the name.

it's a microchip icon

Don't

This duplicates the icon name and does not explain where the icon would be used.

Add context when it clarifies meaning

Some icons have broad meanings. Add context when it makes the use case clearer.

Applying a level-2 heading in text editors

Do

The phrase explains both the action and the product area.

Applying a heading

Don't

This is less useful because it omits the level and context.

Keep each use case focused

Each entry should cover one clear idea. Split different meanings into separate entries.

Marking parking locations on maps

Do

This is short, clear, and focused on one interface function.

Marking parking, transport, maps, cars, garages, and places

Don't

This reads like a tag list and mixes several ideas.

Write variant-specific use cases

For related icons, describe what makes each variant different.

Indicating a low battery charge level

Do

This is specific to battery-low and sets it apart from other battery icons.

Representing battery status

Don't

This is too generic and could apply to every battery variant.

Avoid pull request references

Use cases should make sense after the pull request is merged.

Signifying a deal, agreement, or partnership

Do

This keeps the useful meaning without depending on outside context.

Same as above in #1234

Don't

This depends on a discussion readers may never see.

Keep entries concise

Use cases should usually be 4 to 12 words. Prefer a short phrase over a long explanation.

Searching files by name or content

Do

This is short enough to scan and specific enough to understand.

This icon can be used when users want to search through all of their files and folders to find something

Don't

This is too long and reads like product copy instead of metadata.

Do not end with punctuation

Use cases are metadata phrases, not full sentences.

Confirming a successful payment

Do

This matches the phrase style used across icon metadata.

Confirming a successful payment.

Don't

The period adds unnecessary punctuation and makes entries inconsistent.

Avoid markdown and emoji

Use plain text only. Formatting belongs in documentation, not metadata values.

Warning users about a destructive action

Do

This works in search, generated pages, and other places that use metadata.

Warning users about a destructive action ⚠️

Don't

Markdown and emoji can show up in generated UI and make metadata harder to reuse.

Avoid implementation details

Use cases should describe meaning, not how the SVG was made.

Representing cropped or trimmed content

Do

This explains the icon's interface meaning.

Showing a rectangle with two path cuts and adjusted Bezier handles

Don't

This describes construction details that do not help people find or understand the icon.