Product Design App Critique Interview: Evaluate a Flow Without Guessing the Company's Metrics

In a product design app critique interview, choose one user goal, inspect a bounded flow and explain what the evidence supports. Preserve what already works, separate your hypotheses from observations, and propose one change you could evaluate. If the company's conversion data is unavailable, identify what you would measure instead of inventing a baseline.

Start with PracHub's product-critique exercise. The worked Open Library search below shows how to discuss a real interface while keeping an unfinished task and unknown business metrics explicit.

Evidence boundary: The public web flow was observed in desktop Chrome on November 3, 2026, with the interface in English and no Open Library account signed in. Search and a candidate-edition selection were observed; a Human Verification page stopped the walkthrough. No verification, signup, borrowing, download or reading session followed. The proposed change and evaluation are original preparation ideas, not a user study or a claim about Open Library's private metrics.

Set a user goal before rating the interface

For this exercise, choose a visitor looking for Jane Austen's Pride and Prejudice who wants to identify a candidate edition and check its reading options. That is narrower than evaluating the entire catalog, the borrowing service or whether people return to the site.

Confirm whether the interviewer wants interaction critique, visual craft, product strategy or a combination. State the device and account context you can inspect. A desktop observation should not become a claim about the mobile app, a signed-in reader or every person using assistive technology.

NNGroup's design-critique guidance frames feedback around clear scope and agreed objectives. Apply that principle by naming the task before describing a control. A result list can serve an exploratory reader differently from someone seeking one specific author's work.

Also check the product's stated purpose. Open Library's official introduction describes a collaborative book catalog that connects people with discovery and reading resources. Related works and catalog records have legitimate value even when our chosen visitor wants one readable edition. Evaluate the catalog against its stated purpose before treating immediate reading as every page's goal.

Report the actual search before interpreting it

Observed behavior: Opening Search and entering Pride and Prejudice produced a results dialog with book-search controls. The visible list included Austen results alongside related or adapted works by other authors. Result entries exposed title, author, year and, where shown, a Readable label.

The Readable Only switch changed the visible result set. Adaptation-related results remained visible. That establishes a distinction between narrowing for reading-related availability and identifying the exact work the visitor intends; it does not show that the filter malfunctioned.

The search surface also showed a Language control and reading-log save controls. Their full behavior was not verified in this walkthrough. The English interface setting does not establish the language of a particular edition, and a visible save control does not prove that saving was completed.

Selecting the first observed Austen result led to Human Verification rather than a completed edition inspection. Record that endpoint precisely. We cannot say whether the selected edition could then be read, whether a borrow action was available or whether this same boundary appears for other visitors.

Avoid publishing an exact search-result count as if it were a stable product characteristic. For this critique, the relevant observation is the composition and identifying information in the visible results, not a number that can change with the catalog or query.

Explain the strengths you would preserve

In the observed anonymous session, targeted search was available without creating an account or reading log. That supports the discovery task we could observe. It does not establish the account requirements of later reading or borrowing steps.

Author and year cues provide evidence beyond a title match. They help a person compare similarly named records and notice when a result is associated with another author. Preserve those cues in the proposal so the visitor can still distinguish Austen from a similarly titled adaptation.

The availability-oriented filter is another useful affordance. It gives the visitor a way to narrow the candidate set while retaining a search context. Its presence is a strength even though our observation cannot establish whether every displayed item meets a particular visitor's access needs.

A critique that identifies only defects can accidentally remove these useful properties. Explain the task each existing element supports, then identify the narrower uncertainty worth investigating. You do not need to prove that the whole product is unsuccessful to recommend examining one interaction.

Do not make the identification cues carry more meaning than was verified. A visible year does not by itself establish an edition's language, completeness or suitability for the visitor. Someone seeking Austen's original novel may reject an adaptation even when it is readable. Someone exploring related works may welcome it. Clarifying that difference prevents a critique from treating every nonmatching personal preference as a search-quality failure.

Separate observation, hypothesis and unknown outcome

Use a ledger that makes each claim inspectable. The following entries refer to this desktop walkthrough, not a measured population of readers.

The important move is to keep a possible interpretation from becoming an observed problem. “The label makes people abandon” requires evidence of interpretation and abandonment. Our observation supplies neither. A useful critique can still name that question and suggest how to investigate it.

Open Library's reading FAQ distinguishes catalog records from digital availability and explains reading and borrowing actions. That official context helps explain why finding a title and accessing its text are different steps. It does not prove that this particular selected edition was accessible in the observed session.

Propose one reversible improvement

Original proposal: Add a short helper sentence above the results: “Select a result to check that edition's reading options.” Retain the existing title, author, year, availability cues and filter. The intended benefit is a clearer expectation about the next step, not a promise of immediate access.

This is a hypothesis to test. The wording might help first-time visitors distinguish candidate selection from reading, or it might add noise to an already understandable search. Its value is not established by our ability to write a more explicit sentence.

Keep the change reversible and narrow. It does not alter ranking, catalog membership, account requirements, availability or book rights. Before implementing it, confirm that its wording accurately describes the supported destination across relevant result types and that it fits the responsive layout.

An alternative is to remove related works from the list. That could undermine legitimate discovery and assumes an exact-work intent that the title query alone does not necessarily establish. Another alternative is to replace the cue with an immediate reading promise; our incomplete walkthrough gives no basis for that promise.

Do not bundle several redesigns into the first recommendation. A new ranking model, reorganized filters and a rewritten access flow would make it difficult to determine which change affected understanding. Evaluate the helper sentence by itself, then revise or remove it if it does not clarify the next step.

Define the evaluation contract before choosing a metric

NNGroup's usability overview distinguishes usefulness from ease of use and recommends observing representative people performing relevant tasks. For our proposed evaluation, success must describe the reader's intended result rather than only the action the interface makes easy to count.

Ask a realistic task without telling participants to use your helper. After selection, ask what they expect next and what they believe they have accomplished. Observe the existing design first so the proposal is responding to an actual misunderstanding rather than assuming one exists.

Record the participant context: familiarity with the catalog, device, language needs and any relevant access constraints. Keep those conditions comparable when reviewing an alternative. A person who knows the service well may not need the extra explanation; a first-time visitor may read it differently.

Discuss metrics without inventing the company's targets

If an interviewer asks which metric should improve, distinguish a proposed measure from a known company objective. You could evaluate correct-work selection, accurate access expectations and completion of a defined reading task. You cannot state Open Library's current baseline or target for those measures from this inspection.

Keep denominators and endpoints explicit. A click-through measure might count candidate selections among search sessions, but that would not show whether people found Austen or started reading. Fewer clicks could mean greater clarity, fewer relevant results or simply less exploration. The interpretation needs supporting evidence.

Public mission information can guide the question, but it does not reveal internal priorities. Ask whether the team is improving discovery, catalog contribution, reading access or another outcome before recommending a north-star metric. These goals can overlap while requiring different success definitions.

If the team later instruments the journey, define separate observations for search, candidate selection, access-option selection and opening the intended text. Treat those as proposed measurement definitions, not existing Open Library events. Decide how an unfinished or blocked attempt is represented instead of silently counting it as successful reading. The definitions should let the team distinguish a visitor who explored another work from one who could not access the intended edition. They should also identify which outcome the helper sentence can plausibly influence and which depends on later service behavior.

A small comprehension study can inform a design decision without estimating a business effect. If later production evaluation is appropriate, define the eligible population, comparison, observation period and guardrails with the product team. Do not attach an invented conversion uplift or retention percentage to the helper sentence.

Treat a boundary as missing evidence, not a product verdict

The verification page is part of the observed chronology. It prevented this walkthrough from establishing downstream task completion. It does not identify the cause, show how frequent the condition is or establish whether a typical authorized reader encounters the same path.

Keep separate records for search behavior and later access evidence. If a future authorized session reaches the edition and reading options, record its context rather than retroactively claiming that our earlier attempt succeeded. If the user goal remains blocked, state which part could not be evaluated.

The same discipline applies to untested controls. We saw a Language control but did not establish its selectable options. The appropriate answer is that its behavior is unverified, not that language filtering works perfectly or is broken. Seeing a control in a screenshot can feel conclusive, but it still leaves its interaction unresolved.

This boundary does not make the search critique useless. It narrows the defensible conclusion: we can discuss search affordances, identity cues and expectations at selection, then propose a separate access evaluation. That is more useful than filling an unseen part of the journey with a confident story.

Present a recommendation that can survive a challenge

A concise rehearsal answer could be: “For an anonymous desktop visitor seeking Austen's novel, the search exposes useful author and year cues and a reading-oriented filter. We selected a candidate, but verification stopped the access walkthrough. I would test one helper line clarifying that selection checks edition-level reading options. I do not yet know whether users need it or whether it improves the full reading task.”

If asked to prioritize the idea, explain why it deserves a small evaluation rather than immediate implementation. It addresses a specific possible expectation mismatch and leaves the catalog intact, but that mismatch has not been observed in users. Evidence that the real difficulty lies elsewhere should move this idea down the list.

If challenged on why not redesign the list, return to the task and evidence. Explain what currently helps, which uncertainty your smaller proposal targets and what it costs in space and attention. Change your view when the reviewer supplies information that invalidates the premise.

The strongest conclusion may be that no change is justified yet. If likely users already understand the next step and the helper adds clutter, keep the existing interaction. A critique demonstrates judgment when it identifies evidence that could reverse the recommendation.

Practise app critique with PracHub

These verified question records provide adjacent critique and product reasoning. They are not Open Library interview questions or predictions of an employer's assessment; adapt the task-specific follow-up while retaining each record's original context.

Open Product Critique & Improvement. Choose one flow you can inspect and write one verifiable observation first. Add the hypothesis and unknown outcome, then propose a reversible change. End by naming the task outcome you still cannot claim.

Sources and Further Reading

• Open Library: Official project introduction and catalog purpose
• Open Library: Reading books and available access options
• Open Library: Public search entry point observed in this exercise
• NNGroup: Design critiques, scope and objectives
• NNGroup: Usability, utility and task observation