uxdesign
coach.Get a UX review ↗
A SAMPLE DELIVERABLE / FICTIONAL PROJECT

What does a UX review
actually look like?

A concrete example of the observations, priorities and next-test plan you can expect from a focused review.

Illustrative sample created for this site. Orbit is fictional. No client engagement, participant research or measured uplift is claimed.
ORBIT / FIRST PROJECT FLOWSample review · 3 screens

The decision

What should we improve before testing a new customer’s first-project journey?

Scope
Welcome, project creation, project dashboard.
Available evidence
Concept screens and the task brief. No analytics, support history or participant sessions.
Method
Expert walkthrough of the visible flow. Findings below are reasoned concerns to validate.
Outside scope
Production code audit, full accessibility evaluation, research recruitment and redesign.

Three priorities

01 / START HERE

Bring project creation before team setup.

Observation: The welcome screen asks for phone, company size and five invitations before a project exists.

Concern: The setup work delays the task the customer came to do. We do not yet know which fields are operationally necessary.

Recommendation: Confirm dependencies, keep the minimum project fields, and offer invitations once a project is created.

Confidence: Medium as a design concern; impact on completion is unmeasured.

See the annotated comparison ↗
02 / MAKE RECOVERY POSSIBLE

Keep entered work when creation fails.

Observation: The provided concept has no failed-request state.

Concern: Recovery behavior is unspecified. We cannot infer from the screens that data will be lost or preserved.

Recommendation: Define an error state that preserves the name, offers a retry and avoids creating duplicate projects.

Confidence: High that the specification has a gap; unknown production behavior.

Explore error feedback ↗
03 / CONFIRM THE FIRST SUCCESS

Replace generic emptiness with the next task.

Observation: The concept dashboard says “No data available” and offers Refresh.

Concern: A person may not know whether creation worked or what they should do next.

Recommendation: Show the saved project name, confirmation, and a first-task action. Provide separate new-account, loading, error and permission states.

Confidence: Medium; test interpretation with intended users.

See a more useful empty state ↗

The next test

  1. Prepare: confirm required fields with engineering and product. Make both the happy path and failed-create recovery work in a prototype.
  2. Task: “You have a website refresh to organize. Set up a place to manage that work.” Avoid naming interface controls.
  3. Observe: completion without assistance, hesitation, mistaken actions and understanding of the resulting project. Record counts with denominators.
  4. Probe: ask what participants think was saved, whether anyone was invited, and what they would do next.
  5. Decide: revise where observed behavior challenges the design. A small qualitative study identifies issues; it does not establish a revenue lift.

Decision and ownership

Product confirms required setup fields. Design specifies recovery and success. Engineering checks duplicate prevention and feasibility. The team schedules research and records the release decision after reviewing evidence.

Learn what to bring to a focused review ↗