A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
What needs to be finished first
Interfaces, data types and expected behavior are described well enough for developers to work through tasks. Individual questions may still be open.
People who will use the design can identify typical tasks and program together.
What needs to be ready before start
Versioned design with interfaces, data types, expected behavior and examples; scenario list, shared editor and findings log.
Design owners, future users as reviewers, a facilitator and a note-taker. Agree who will answer scenario questions. Reviewers need programming and domain knowledge.
Share design purpose and boundaries, interfaces and examples. Explain the reviewers’ active role.
Use 2 to 4 hours as a planning range for a focused review meeting. Allow additional time for preparation and follow-up; total effort depends on the design and scenarios.
Keep code or pseudocode and findings visible together. Separate clarification from discussion of new design options.
The one question this method answers
Can developers accomplish their important tasks using this preliminary design?
Phases with goal, actions, output and pitfall
ARID helps teams try out interfaces while a design can still change. The developers who will use them choose typical tasks and work through them together. They write code or pseudocode, a simplified description of program steps. This reveals which interfaces are easy to use and where descriptions of their behavior are incomplete or contradictory.
Fictional teaching example
A document template for your review. A separate fictional example shows how to review a reservation library.
Enter the design version, boundaries, participating developers and review roles.
Reservation library v0.3; two consuming teams; Alex facilitates.
Record tasks, priorities, selection reasons and scenarios still to explore.
Safe retry after timeout has highest priority; cancellation remains unexplored.
Link code or pseudocode to interfaces used, questions and assumptions.
After a timeout, it is unclear whether reserve(request) succeeded; calling it again could create a duplicate reservation.
Record the usage obstacle, affected location, owner and repeat check.
Identify the request with an idempotency key and add a status lookup; then repeat the scenario.
The example illustrates the method using invented information.
Paul C. Clements: Active Reviews for Intermediate Designs (SEI, 2000)
Prepare
Goal
Developers can begin a typical task using the materials.
Inputs for this step
Actions
Output
Usable materials and assigned roles
Check that the materials, example and assigned roles are ready for the meeting.
Quality check
Can developers begin a typical task with these materials?
Pitfall
The presentation only shows internal architecture diagrams. Add callable interfaces and examples from the consuming application perspective.
Timing: Prepare before the meeting; allow time according to scope.
Introduce
Goal
Everyone understands the procedure and the proposed design.
Inputs for this step
Actions
Output
Shared understanding and open questions
Record clarification questions and identify information still to be added.
Quality check
Are the interfaces and their expected behavior clear?
Pitfall
The meeting immediately switches to an alternative design. Focus the discussion on how developers can use the proposed interfaces.
Timing: Allow time for the introduction according to the design’s scope.
Select
Goal
Developers determine the relevant tasks for the review.
Inputs for this step
Actions
Output
Prioritized application scenarios
For each selected task, record why it matters for later use.
Quality check
Do priority tasks come from developers who will use the design?
Pitfall
Only prepared success examples are evaluated. Have reviewers add their own tasks and determine the priorities.
Timing: A shared part of the meeting for selecting scenarios.
Exercise
Goal
Concrete usage obstacles become visible through application.
Inputs for this step
Actions
Output
Code or pseudocode with findings
Link each question or obstacle to its location in the code or pseudocode.
Quality check
Can reviewers solve the task using the proposed interfaces?
Pitfall
The lead designer writes the solution for the reviewers. Let the reviewers continue the work themselves and record the support they need.
Timing: This is the main activity; complex scenarios can take hours.
Capture
Goal
The lead designer receives traceable results.
Inputs for this step
Actions
Output
Review record with revisions and repeat checks
Link revisions to the affected scenarios and arrange another check.
Quality check
Does each finding identify the task and the point where it arose?
Pitfall
A solved scenario is treated as approval of all quality goals. Name the scenarios completed successfully and the quality goals that require further technical checks.
Timing: Closing block followed by later repeat checks.
What comes out at the end
Versioned record of scenarios, code or pseudocode, usage obstacles, open questions and next checks.
Link each finding to the design version, scenario and relevant point in the code or pseudocode. Keep earlier reviews.
Allow time for preparation and a joint review meeting. Set the scope around the most important application scenarios.
To be confirmed
To be confirmed
Entire review Time: Use 2 to 4 hours as a planning range for a focused review meeting. Allow additional time for preparation and follow-up; total effort depends on the design and scenarios.
Complete this worksheet on paper or in your own document during the work.
Enter the design version, boundaries, participating developers and review roles.
...
Record tasks, priorities, selection reasons and scenarios still to explore.
...
Link code or pseudocode to interfaces used, questions and assumptions.
...
Record the usage obstacle, affected location, owner and repeat check.
...
Add actual information and evidence. Mark unresolved items explicitly.
Paul C. Clements: Active Reviews for Intermediate Designs (SEI, 2000)
Expected artifact: Usable materials and assigned roles
Check that the materials, example and assigned roles are ready for the meeting.
Entry:
...
Expected artifact: Shared understanding and open questions
Record clarification questions and identify information still to be added.
Entry:
...
Expected artifact: Prioritized application scenarios
For each selected task, record why it matters for later use.
Entry:
...
Expected artifact: Code or pseudocode with findings
Link each question or obstacle to its location in the code or pseudocode.
Entry:
...
Expected artifact: Review record with revisions and repeat checks
Link revisions to the affected scenarios and arrange another check.
Entry:
...
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/arid/run-sheet
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
Concrete filled scenario, fictional example
Fictional: Two teams try out a reservation library. After a timeout, they want to retry a reservation safely. In their joint pseudocode, they call reserve(request) again. This reveals that a safe retry needs a unique identifier for the same request, an idempotency key. They also need a way to check the status of the first reservation. The design owner adds both to the interface rules. The team then repeats the scenario. It investigates runtime and behavior under load in separate tests.
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
The presentation only shows internal architecture diagrams.
Add callable interfaces and examples from the consuming application perspective.
The meeting immediately switches to an alternative design.
Focus the discussion on how developers can use the proposed interfaces.
Only prepared success examples are evaluated.
Have reviewers add their own tasks and determine the priorities.
The lead designer writes the solution for the reviewers.
Let the reviewers continue the work themselves and record the support they need.
A solved scenario is treated as approval of all quality goals.
Name the scenarios completed successfully and the quality goals that require further technical checks.
When to pause, resolve prerequisites, or choose another approach
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.
