Skip to main content
Use this guide when you need a repeatable way to run design reviews in Speckle. It ties together saved views, federation, sketches, and issues into one end‑to‑end workflow, for teams that already view and share models in Speckle.
Before you start: You need a Speckle project, at least one model, and access to the 3D viewer. If you are new to Speckle, complete the Quickstart first.

​
Prepare the model for review

When to use: Before a formal review meeting or an asynchronous review round.
1

Create a review project and models

Create or open a Speckle project for your review. Organise separate models per discipline (e.g. Architecture, Structure, MEP) and ensure each author is publishing to the correct model.
2

Federate models if you have multiple disciplines

In the 3D viewer, load the primary model, then select Add model to scene (+) in the Models panel and add the other disciplines (e.g. structural, MEP). See Federation for options and limits.
3

Set up saved views for key topics

Navigate to an important viewpoint (e.g. lobby, core, facade area) and set section planes, filters, and visibility. In the Views panel, select Save view and give each viewpoint a clear name such as “Level 02 Lobby – Fire Strategy” or “Facade – North Elevation”. Group related views by discipline or review round. See Saved Views for details.
4

Decide what will be reviewed in each session

For each review session, pick a small set of saved views and topics (e.g. “Stair core clearances”, “Envelope coordination”, “Plant room layout”). Note which disciplines and team members must attend.
5

Share access and links ahead of time

Invite reviewers to the project and confirm they can open the relevant models. Use Copy link on each saved view and paste the links into the calendar invite or meeting agenda so everyone lands in the same context.
Outcome: A federated model with named saved views and clear scope for the review session.

​
Run a formal design review session

When to use: Live reviews on a call or in a room where one person drives the model.
1

Start from the agreed saved view

Open the project and models in the 3D viewer, then select the first saved view from the review agenda. Confirm that everyone sees the same context before you start.
2

Keep the geometry readable

Use Section, Filters, and Isolate to keep the area under discussion clear while you talk through the design. Avoid making large camera movements while others are commenting. See Exploration for the tools.
3

Capture visual feedback with sketches

As people raise comments, draw on the model with Sketch (pen, arrows, revision clouds, text). Save one view per topic and name it to match the agenda item or issue it relates to. See Sketch on your model for tools.
4

Convert important points into issues

For each decision or required change, select the relevant object(s), then create an Issue from the Issues panel. Set title, description, assignee, priority, and due date while the conversation is fresh. Use labels to tag discipline or review round (e.g. “DR01”, “Structure”). See Issues for full field behaviour.
5

Capture open questions as issues or comments

When there is an open question or debate that will continue after the meeting, either create a separate Issue for it or add a clear comment on an existing issue. Mention the relevant people, summarise options, and link to any supporting files.
6

Bookmark the review state

Once the meeting ends, save a view that captures the final camera, filters, and sketches. Use this as the entry point for asynchronous follow‑up work.
Outcome: Key decisions and change requests are captured as issues and comments, with sketches and saved views tying them back to the 3D model.

​
Collect asynchronous feedback

When to use: Reviewers are in different time zones or cannot attend the same meeting.
1

Send links to review views and issues

Share links to the saved views and specific issues created during the session. Encourage reviewers to reply in‑place instead of sending screenshots or emails.
2

Group related feedback on issues

For topics that affect multiple areas or models (e.g. fire strategy, circulation), keep the conversation in one or a small number of Issues. Encourage people to reply on those issues so context stays in one place instead of spreading across channels.
3

Assign clear owners

Ensure every actionable comment is attached to an Issue with an assignee. Use @mentions in issue comments to bring in additional stakeholders where needed.
4

Resolve issues when agreed

When a topic is agreed or a question is answered, select Resolve issue so they no longer clutter the active list. You can always create follow‑up issues later if required.
Outcome: Feedback from people who were not in the original meeting is captured directly against the model and grouped by issue.

​
Coordinate across disciplines and versions

When to use: Multi‑disciplinary models or multiple design rounds.
1

Use federation for cross-discipline context

Keep models from different tools and disciplines loaded together so reviewers see clashes and coordination issues in context. Use Isolate model or Hide model in Models to focus on one discipline at a time.
2

Ask what changed between rounds

When a new version is published, ask Speckle Intelligence what changed since the previous round, and have it filter and colour the changed elements. Focus on areas with many issues to confirm that fixes have been applied. See Assess model changes with Speckle Intelligence.
3

Tie issues to specific versions when needed

For changes that must be tracked precisely, record or pin the model version in your issue descriptions so reviewers know which drop a comment relates to. Opening an issue loads the version it was raised on, so you can revisit the original context when validating fixes.
4

Use labels to group issues by review round

Agree label conventions such as “DR01”, “DR02”, or “Coordination‑MEP” and apply them consistently. This makes it easy to filter issues per round or per coordination topic in both the viewer and dashboards.
Outcome: Discipline teams can see how designs evolve between rounds and confirm that coordination issues are being resolved.

​
Follow up and close the review

When to use: After a review round, when changes are being implemented and verified.
1

Review open issues by priority and due date

Open the Issues panel in the 3D viewer or the project’s Issues page. Filter by status, priority, assignee, labels, or overdue. Confirm that high‑priority items from the latest round are clearly assigned and understood.
2

Implement changes in authoring tools

Designers and engineers resolve issues in their native tools, using connectors to see associated issues where available. Keep the Speckle model updated by publishing new versions once fixes are applied.
3

Verify fixes in the viewer

After publishing, load the updated versions and re‑visit the saved views and issues. Confirm that each issue is addressed visually and in the data (e.g. correct geometry, properties, and clearances).
4

Update issue status and resolutions

For each verified fix, move the issue to Ready for Review or Resolved according to your team’s convention. Add a short reply describing what was changed so the history is clear.
5

Prepare for the next round if needed

If further review is required, create new saved views and issues for the next round, and label them accordingly. Delete views that are no longer in use to keep the Views panel tidy.
Outcome: Design review rounds are closed cleanly, with a clear record of what was requested, what was changed, and when it was verified.

​
Best practices

  • Keep scopes small: Limit each review session to a manageable set of views and topics so issues stay focused.
  • Name consistently: Use consistent naming for saved views, issues, and labels so people can find related items quickly.
  • Decide on status conventions: Agree what Open, Ready for Review, and Resolved mean for your team before you start.
  • Use labels for reporting: Plan labels so dashboards and reports can slice issues by discipline, review round, or risk category.
  • Avoid duplicate channels: Encourage feedback in issues (and their comments) instead of email and chat so history stays with the model.

​
FAQ

Start with a small number that cover the key questions for the session, typically 5–10 views. You can add more later, but too many views make it harder for reviewers to know where to focus.
Use one issue when several comments all relate to the same location and decision, and separate issues when there are clearly different problems or owners. Each issue should represent a reviewable piece of work with a clear outcome.
Use labels on issues (e.g. DR01, DR02) and include the round in saved view names. You can then filter issues by label in the viewer or dashboards to see everything from a specific round.
Yes. Give them the Reviewer project role and share links to saved views. Reviewers can open issues and reply to them, but cannot save views.
You can create issues after the fact from sketches and meeting notes by revisiting the saved views and translating important comments into issues. The earlier you do this, the less context you lose.
Before creating a new issue, quickly search existing issues by keywords, labels, or affected area. If one already exists, add a reply or update its properties instead of creating a new one.
Use dashboard Issues widgets to track issue counts by status, label, and assignee. See Common workflows for dashboard patterns.
Create a single coordination issue that references all relevant models and clearly describes the cross‑discipline impact. Use labels to tag each discipline and link to any related per‑discipline issues.
Issues stay attached to the objects and versions they were created on. If objects are deleted or heavily modified, you can still load the original version to see the original context, then decide whether to close or recreate issues on the new design.
Not directly from the Issues list. Build a dashboard with the Issues list or Issues Overview widget and share it instead. See Issues.
Speckle keeps feedback, issues, and sketches tied directly to models and versions, with structured fields (status, assignee, labels) and version awareness. Tools like Miro are excellent for presentation boards, but treat the model as just another frame; you have to manage ownership, status, and version context manually. A common pattern is to run the actual review and tracking in Speckle, then embed Speckle views into Miro or similar tools when you need a storyboard or client presentation.

​
See also

Last modified on October 19, 2026