When running an interface inventory of a course-registration portal, what does a screenshot audit catch that a code audit misses, and vice versa?
answer
- what users see vs what exists
- rendered result vs declared values
- states hidden behind interactions
- dead code inflates counts
- run both, reconcile
basics
~20 sA screenshot audit captures what users actually see — visual inconsistency, combinations, platform differences — but misses exact values and hard-to-reach states. A code audit finds declared values and near-duplicates, including unused ones, but cannot show how they combine on screen.
solid answer
~50 sA **screenshot audit** walks the product as a user would — course search, section detail, the registration cart, the timetable, on web and mobile — and captures every element into grouped collections. It catches what users experience: visual inconsistency, how elements combine, and differences between platforms. It misses exact values (two grays that look alike), states that are hard to reach (errors, full sections, waitlists) and anything behind permissions. A **code audit** searches the source for declared colors, type sizes, spacing values, icons and component definitions. It gives precise counts, finds near-duplicates and reaches states defined in code, but it includes dead code and cannot show how things render together or which variant appears where. So I run both and reconcile them: the code audit sizes the problem, and the screenshots show which inconsistencies users actually feel.
go deeper
Recall the two ways to gather an inventory: capturing the rendered screens and searching the code for declared values and components.
Explain each lens's blind spots — screenshots miss exact values and unvisited states, code misses rendering and inflates counts with dead code — and why you reconcile them.
Show how you would plan the audit across web and native mobile: seeded edge states, normalised values, filtered dead code, and results annotated by traffic.
Weigh audit depth against cost: a large product can be sampled per category, as long as the sample is honest about which states and platforms it left out.
## Two lenses on the same product An **interface inventory** catalogues the colors, type styles, spacing values, icons and components a product really uses, before a **design system** is built. There are two main ways to collect it, and each sees things the other cannot: - A **screenshot audit** captures the rendered interface, screen by screen, and sorts the captures into category collections. - A **code audit** searches the source code of each app for declared values and component definitions and counts them. ## Side by side | Aspect | Screenshot audit | Code audit | |---|---|---| | Sees | What users actually see | What developers declared | | Exact values | No — similar colors look identical | Yes — every declared value | | Combinations and layout | Yes — elements in context | Poorly — values in isolation | | Hard-to-reach states | Only if someone triggers them | Yes, where styles for them are defined | | Dead or unused code | Never shown | Counted unless filtered out | | Content problems | Yes — truncation, wording, overflow | Rarely visible | | Platform differences | Yes — web and native mobile side by side | Only by comparing separate codebases | | Effort | Manual, slow for large products | Faster once searches are written | ## What each one misses The **screenshot audit's** blind spots: - **Precision** — two grays that differ slightly look the same, so the audit undercounts near-duplicates. - **Unvisited states** — error messages, full or cancelled sections, waitlist positions, holds on a student record and permission-gated screens appear only if someone deliberately triggers them. - **Why** — it shows the symptom, not which component or value produced it. The **code audit's** blind spots: - **Dead code** — retired screens, experiments and values that never render inflate the counts. - **Equivalent spellings** — the same value written several ways looks like several values until normalised. - **Rendering** — it cannot show which variants users actually encounter, or that a correct component looks broken because of its surroundings. - **One-off local styling** — overrides applied inline or per screen can be scattered and easy to miss in searches. ## Combining them 1. **Run the code audit first** to get precise counts and a list of candidate duplicates per category. 2. **Walk the main user paths** for the screenshot audit, then deliberately trigger edge states using test accounts and seeded data. 3. **Reconcile**: match captured elements to code definitions, drop code that never renders, and normalise values written in different ways. 4. **Annotate** each group with where it appears and how often, so high-traffic inconsistencies stand out. Web and native mobile apps usually declare values in different units and in separate codebases, so the code audit needs each platform's values converted to a comparable form before counting. ## Example: the course-registration portal The code audit of the portal's web and mobile apps finds dozens of declared font sizes; a fair share turn out to belong to an old advising module nobody can reach any more. The screenshot audit then shows what the counts could not: the registration cart, the timetable and section detail each show a full section in a different way — a red label, a gray row, a lock icon — and the mobile app truncates long course titles where the web app wraps them. The reconciled inventory reports the counts that ship, with screenshots of each variant beside them, which is far more persuasive than either list alone.
- How do you reach hard-to-trigger states during a screenshot audit?Use test accounts and seeded data built for them: a student with a hold on their record, a section at capacity, a waitlisted course, an expired registration window. Ask support and QA which errors users hit most, and pair with engineers who can force states in a test environment. Without this, error and empty states — often the least consistent — are undercounted.
- Why can a code audit's counts overstate the real inconsistency?Source includes dead code, retired screens, experiments and values defined but never rendered, and the same value can be written several ways. Filter counts to what ships and normalise equivalent values before presenting them; otherwise the inventory exaggerates the problem and loses credibility with the teams who know which code is live.
saying these in an interview costs you the question
- A screenshot audit gives exact values for every color and size.
- A code audit shows exactly what users see on screen.
- Auditing only the main happy path is enough for an inventory.
- One lens is enough; running both just duplicates the work.
- Auditing the web app also covers the mobile app.