Design Options in Revit: Setup, Pitfalls, and Actually Showing Them

Design options in Revit let you carry several competing versions of a design inside one model: 2 roof forms, 3 entry configurations, a brick facade against a timber one. One file, no parallel models, no folder of copies with dates in the filename. The feature is genuinely good and genuinely underused, for 2 reasons that have nothing to do with each other. Its rules confuse people. And the options are hard to show.

The first half is documented everywhere. The second half is where the feature actually pays.

How design options in Revit actually work

The mental model first. Your model has a main model, everything common to every version, plus option sets, each holding alternatives. One option per set is the primary. That is what schedules, exports and views show unless you tell them otherwise.

The workflow:

1. Manage tab → Design Options → New option set. Name it for the decision, not the geometry: "Entry configuration", not "Option A".
2. Create the options inside the set. "Canopy entry", "Recessed entry". Explicit names pay off in every dialog after this one.
3. Move existing elements into an option. Select the geometry that varies, use Add to Set, choose which options it belongs to. Everything you leave alone stays in the main model.
4. Edit inside the option. Activate an option, model its version, finish. Elements you create while an option is active belong to that option.
5. Control visibility per view. Each view's Visibility/Graphics → Design Options tab picks which option that view displays. Duplicate a view per option and you have parallel presentations of the same building.
6. Promote the winner. Accept Primary merges the chosen option into the main model and deletes the rest of the set. Do it when the decision is genuinely made. Option sets kept "just in case" rot quickly.

The rules that trip everyone

• An element lives in one option set at most. Geometry cannot belong to 2 sets. If a wall participates in 2 independent decisions, restructure the sets.
• References across the boundary are restricted. Elements in the main model cannot host or be hosted by option elements in ways that would break the other options. Revit will block or warn, and the fix is usually moving the host into the option too.
• Tags and dimensions bind to visible options. Annotate in the option-specific duplicated views, not in shared views, or the annotations vanish when the option switches.
• Schedules follow the primary. Quantity comparisons between options need per-option schedule views with the right Design Options setting. Nearly everyone discovers this after presenting the wrong numbers once.
• Worksharing interacts. On multi-user projects, agree who edits inside which option. Simultaneous edits in one option are the classic collision.

Set up cleanly, the feature does exactly what it promises: one model, several real alternatives, no file duplication.

Why design options in Revit are cheap to build and expensive to show

Here is the strange economics of the feature.

Revit makes maintaining 3 alternatives nearly free. Showing those 3 alternatives convincingly was anything but, because every option needs its own imagery, and imagery was priced per image. 3 options, times 2 views, times a revision round. At hours per render, or hundreds per outsourced image, the honest number of alternatives a practice can afford to put in front of a client is 1.

That constraint quietly shaped the profession. One developed direction, presented and defended. Not because the design process produced one answer, but because the imaging budget did. The client then reacts to the only image they were shown, which is a much weaker conversation than choosing between real alternatives. Nobody chose that workflow. The price chose it.

Change the per-image price and the feature changes value entirely. When a rendered image costs about 30 seconds from a viewport screenshot, the marginal cost of showing every option photorealistically drops to nearly nothing. Screenshot each option view. Render each. Put 3 realistic versions of the building on the table in the same meeting.

Render-driven exploration: when an image costs seconds instead of days, rendering stops being what you do to a decision already made and becomes the thing you make the decision with.

I build SecondRender, which is one way to do this, and the standard honesty applies. AI-generated imagery varies between runs, so treat the per-option renders as convincing representations of each direction, not as pixel-final documents. Carrying one option's exact detailing into a second perspective is still a real challenge, and that is a property of the whole category of AI image models rather than a bug in one product. Fidelity mode keeps your geometry authoritative. A saved style keeps the look consistent across the options, so the client compares buildings and not lighting. For pixel-final deliverables the traditional pipeline still applies, and the people who run it are doing a different job than this one.

The workflow, end to end: duplicate a camera view per option, set each duplicated view to its own option, screenshot each, render each with the same style, present the set.

The client compares buildings instead of imagining the differences from your description. Decisions come back faster and they stick better, because the client chose rather than approved.

When Revit design options are the wrong tool

Whole-building variants, different footprints or different massing strategies, are better as separate files. Design options are for bounded alternatives inside a shared design.

Phasing is its own feature, not an option-set job.

And options kept alive after the decision are model debt. Promote and delete.

Try it on the next set you build: 2 options, one camera view each, screenshots into a render. That is the whole test of whether your next client meeting goes better with more than one image on the table.

Related reading: how to render in Revit covers the full rendering path landscape for Revit users, and the complete guide to architectural rendering covers the economics that make multi-option presentation viable at all.