Choose one workflow and an acceptable outcome
Begin with a concrete problem: repeated room-data entry, ambiguous specification revisions, or a handoff whose current files are difficult to identify. Avoid “make design faster” as the sole acceptance criterion. Decide what a colleague should be able to do at the end without relying on the person who prepared the work.
Use a fictional or permitted non-confidential test project. Keep the brief, room data, and requested outputs the same across products. Name which outputs are essential now and which would be useful later. This guide does not rank vendors or imply that OpenLintel currently satisfies every test.
Use a worksheet based on observed evidence
Copy this table into your evaluation notes. For each row record the observed result, the software version or test date, the evidence retained, and any unresolved question. Use “demonstrated,” “partial,” “not observed,” or “not required” rather than treating a marketing claim as a passed test.
| Test | What to ask the demonstrator to do | Evidence to retain |
|---|---|---|
| Source trace | Show where a room dimension came from and how its confidence is represented. | Source reference and behavior after correction. |
| One item across records | Find the same furniture reference in its plan, specification, and quantity record. | Current identifiers, fields, and any manual reconciliation required. |
| Controlled change | Change one candidate selection and show what updates or remains open. | Affected records, preserved history, and unresolved work. |
| Review boundary | Distinguish a concept choice from technical review and purchasing state. | Actual available states and who can change them. |
| Export and reuse | Export the required formats and open them in your receiving tools. | Readable files, editability, retained references, and known losses. |
| Client-data handling | Explain actual storage, external processing, retention, access, and deletion. | Current policy/configuration evidence and unanswered questions. |
Run the test, including the inconvenient parts
Ask to see a small end-to-end sequence rather than unrelated finished screens. Enter the agreed inputs, create or locate the required records, introduce a change, and inspect the resulting issue. Note which steps are manual, which need another service, and where a human must review the result.
A downloadable example is not proof of a live export function. An animated walkthrough is not proof that your own inputs are supported. Open files in the software your studio and collaborators actually use; a format name alone does not establish interoperability or that all fields survive.
If measuring preparation effort, define the start and finish and include corrections and review. Repeat a comparable task before drawing conclusions. Do not turn a single demonstration into a claimed percentage saving.
Examine data handling before uploading client work
Ask which systems receive uploaded images, drawings, and prompts; what is stored; which people can access it; and how deletion works. Check the actual configuration and applicable vendor terms with your organization’s responsible reviewer. A local interface or open-source license does not, by itself, mean all processing stays offline.
Do not use a real home address, identifiable family information, or confidential project files merely to make a demonstration realistic. A fictional test can establish many workflow behaviors without that exposure. If an essential question cannot be answered, record it as unresolved before a real-project trial.
Make a decision that matches the evidence
Summarize the essential tasks demonstrated, manual work still required, critical gaps, implementation prerequisites, and the next test. Distinguish an experimental pilot from a production rollout. Choose a limited pilot only if the remaining uncertainty is acceptable for its intended use and the relevant people understand the limitations.
For OpenLintel, start with the public product-status page and repository prerequisites. The Window Room and resource downloads are illustrative editorial assets, not customer outcomes or proof of a hosted application workflow. A discovery conversation is a way to compare your needs with active development; it does not guarantee access or pilot admission.
Before you move on
- Are acceptance criteria tied to a real studio task?
- Did you observe the required workflow and inspect its exported results?
- Are privacy questions, review boundaries, and unproven capabilities explicitly unresolved rather than assumed?
About this resource
Authored by OpenLintel with AI assistance. Examples are illustrative and have not received independent professional review. Adapt the structure to your practice and verify project-specific information. No legal agreement, regulatory compliance, or construction readiness is represented.
See the information connect
Follow the corresponding chapter of The Window Room: one illustrative brief, one selected direction, and coordinated sample references.
Explore the sample handoffDiscuss your studio’s workflow
OpenLintel is in active development, not a guaranteed hosted trial. Bring your evaluation requirements to a pilot discovery conversation and compare them with the product’s verified status.
Request a pilot discovery conversation