How do you audit your existing web interface?
Record the styles, parts, and states that actually exist before deciding what to align.
An interface audit records the pages, parts, and interaction states that actually exist. It shows where problems occur so the team can decide what to improve using evidence.
Keep these basics in mind
- An interface is what users see and operate. A state is how it behaves in a situation, such as invalid input or loading.
- Collect representative pages around user tasks. Check wide and narrow windows and keyboard use.
- Record differences in appearance, behaviour, and context, rather than only collecting screenshots.
- Group items with the same meaning and behaviour, while preserving differences that serve a real need.
The Figma website team’s audit shows how headings, buttons, and repeated page-building problems can identify a starting point.
An audit process
An illustrative audit record
The pages and decisions below are hypothetical.
| Location | Observation | Decision |
|---|---|---|
| Profile page | No feedback after saving | Add a completion message |
| Invite member page | The same save action says Confirm | Check the meaning and align the wording |
| Delete member dialog | Deletion looks like an ordinary action | Preserve a distinction for the destructive action |
Walk through an example
The team follows Invite a member through the list, form, and completion message. A designer records button and field styles while a developer checks behaviour. They group equivalent save actions and record deletion separately. After changes, they repeat the invitation task to check whether the problems are resolved.
Limits and common misunderstandings
A screenshot captures appearance at one moment. It does not prove that loading, errors, or keyboard use work. Differences are not always mistakes: primary and destructive actions may need different expressions. Record facts and reasons before deciding what to change.