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.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.
Federate models if you have multiple disciplines
In the 3D viewer, load the primary model, then open the Federation panel (left sidebar) and add additional models (e.g. structural, MEP). Adjust transforms if needed so models align. See
Federation for options and limits.
Set up saved views for key topics
Navigate to an important viewpoint (e.g. lobby, core, facade area) and configure section boxes, filters, and view modes. In the left sidebar, open Saved views and save each viewpoint with 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.
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.
Run A Formal Design Review Session
When to use: Live reviews on a call or in a room where one person drives the model.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.
Use presentation tools to keep focus
Use view modes, section tools, and lighting controls to keep geometry readable while you talk through the design. Avoid making large camera movements while others are commenting. See
Presentation for options.
Capture visual feedback with markups
As people raise comments, draw over the model using Markups (arrows, boxes, text). Use one markup per topic and name them so they match the agenda item or issue they relate to. See
Markups for tools and export options.
Convert important points into issues
For each decision or required change, create an Issue on the relevant object(s). 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.
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.
Collect Asynchronous Feedback
When to use: Reviewers are in different time zones or cannot attend the same meeting.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.
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.
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.
Coordinate Across Disciplines And Versions
When to use: Multi‑disciplinary models or multiple design rounds.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 visibility toggles to focus on one discipline at a time when needed.
Compare design rounds with version comparison
When a new version is published, use the Compare versions tools to see what has changed between rounds. Focus comparisons on areas with many issues to confirm that fixes have been applied. See
Compare Versions for options.
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. Use the Issues version filters to revisit the
original context when validating fixes.
Follow Up And Close The Review
When to use: After a review round, when changes are being implemented and verified.Review open issues by priority and due date
Open the Issues panel in the 3D viewer (left sidebar) or the project’s Issues tab. Filter by status, assignee, labels, and due date. Confirm that high‑priority items from the latest round are clearly assigned and understood.
Implement changes in authoring tools
Designers and engineers resolve issues in their native tools, using connectors to see associated issues and markups where available. Keep the Speckle model updated by publishing new versions once fixes
are applied.
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).
Update issue status and resolutions
For each verified fix, move the issue to Ready for Review or Done according to your team’s convention. Add a short note describing what was changed so the history is clear.
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, markups, issues, and labels so people can find related items quickly.
- Decide on status conventions: Agree what Open, Ready for Review, and Done 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
How many saved views should we create for a review?
How many saved views should we create for a review?
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.
Should we use one issue or many for feedback?
Should we use one issue or many for feedback?
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.
How do we keep track of which comments belong to which review round?
How do we keep track of which comments belong to which review round?
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.
Can external stakeholders review the model without editing anything?
Can external stakeholders review the model without editing anything?
Yes. Give them view‑only access to the project and share links to saved views. They can still open and comment on issues if project permissions allow, but they cannot change the model geometry.
What if we forget to create issues during the meeting?
What if we forget to create issues during the meeting?
You can create issues after the fact from markups and meeting notes by revisiting the saved views and translating important comments into issues. The earlier you do this, the less context you lose.
How do we avoid duplicate issues for the same problem?
How do we avoid duplicate issues for the same problem?
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.
Can we report on review progress across projects?
Can we report on review progress across projects?
Yes. Use Speckle Intelligence dashboards with Issues widgets to track counts by status, label, assignee, or version. See Common workflows for dashboard patterns.
How do we handle issues that span multiple models or disciplines?
How do we handle issues that span multiple models or disciplines?
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.
What happens to issues when a model changes significantly?
What happens to issues when a model changes significantly?
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.
Can we export a summary of review issues?
Can we export a summary of review issues?
You can build an Issues dashboard in Speckle Intelligence and share it, or connect data to external reporting tools. Direct export from the Issues list is not yet available; check the Issues documentation for
the latest capabilities.
Why use Speckle for design review instead of Miro or similar?
Why use Speckle for design review instead of Miro or similar?
Speckle keeps feedback, issues, and markups 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.