Most custom-optics projects don't go wrong in the design phase. They go wrong two months earlier, in a requirements document that was simultaneously over-specified where it didn't matter and silent where it did. This guide is the checklist we wish every incoming spec followed — written for product engineers who need optics but don't design them.
Start from the scene, not the lens
The strongest optical specifications describe the task: what must be detected, resolved, measured or illuminated, at what distance, under what light. From a well-posed task, a designer can derive focal length, aperture and format honestly. From a pre-guessed lens spec ("50 mm, f/2.8, C-mount"), a designer can only inherit your assumptions — including the wrong ones.
Give the scene: object size and distance range, required feature size, motion, illumination level and spectrum, and the environment (temperature, vibration, washdown, altitude). Every one of those maps to glass.
The ten numbers a designer actually needs
- Wavelength band — not "visible," but a band with weights: e.g. 450–650 nm, peak sensitivity 550 nm. Every glass choice hangs on this.
- Field of view / object size — with the tolerance on it. A ±5% FOV tolerance can halve the cost of a distortion requirement.
- Resolution at the object — the feature you must resolve, in millimeters, and the contrast at which you must resolve it. This converts to an MTF requirement, which is what a designer can actually optimize.
- Sensor — model or at least format, pixel pitch and cover-glass details. Optics and sensor are one system; specifying them separately is how Nyquist mismatches are born.
- Aperture / light budget — either a radiometric requirement (SNR at scene illuminance) or an f-number with the reasoning attached.
- Working distance and envelope — including the volume the lens may occupy and every keep-out. Track length is the constraint that kills more first designs than image quality.
- Depth of field — the object depth that must stay usable, and what "usable" means for your task.
- Distortion tolerance — with a statement of whether software correction is acceptable. This one word ("yes") routinely saves multiple elements.
- Environment — operating and storage temperature, shock and vibration, sealing. Athermalization is a design-in decision, not a retrofit.
- Volume and target cost — 5 prototypes and 50k/year units yield different designs, different glass, different tolerancing philosophies. Say which product you are building.
What to leave open — on purpose
A specification's power comes as much from its silences. Unless they are genuinely constrained, leave open: the number of elements, glass types, aspheric usage, and the internal architecture. Locking these early converts your requirements document into a worse version of the designer's job and removes the degrees of freedom that make hard specs achievable.
Flag, rather than fix, anything you suspect matters: "boresight stability probably matters — we don't know how much yet" is a professional and useful sentence.
The traps that cause requirement churn
- Adjectives instead of numbers. "Sharp," "compact" and "robust" cannot be optimized. Convert each to a measurable with a test method, or delete it.
- Copy-pasted heroics. Requirements inherited from another program ("λ/10 surfaces," "0.1% distortion") multiply cost silently. Every tight number should be traceable to a task need.
- The missing tolerance on the requirement. Every value needs a tolerance or a min/max direction. "EFL = 35 mm" is incomplete; "EFL = 35 mm ± 2%, shorter preferred" is actionable.
- Interface amnesia. Mounting geometry, flange distance, filter placement, cover glass, connector keep-outs — interface surprises at CDR are self-inflicted.
- Specifying the prototype, meaning the product. If the real goal is a manufacturable volume product, say so on page one; the design path diverges immediately.
What a good response looks like
When a specification like this reaches a competent optics partner, the response should not be a quote — it should be a requirements review: a table restating each requirement, its derived optical consequence, the two or three that dominate cost or risk, and any conflicts made explicit with options. If a vendor quotes your first draft without pushing back on a single number, that is not efficiency; that is a partner who will discover your spec's contradictions at your expense, on your schedule.
That review conversation — typically a week or two of structured work — is the cheapest optical engineering your program will ever buy. It is also, not coincidentally, exactly how our own fixed-scope diagnostic engagements begin.
Have a similar engineering challenge? Talk to our optical engineers — a fixed-scope diagnostic turns uncertainty into a costed plan, typically within weeks.