7 Visual Ways to Explain Solar Access Clearly

Solar access becomes hard to explain when a proposal jumps straight from a roof photograph to an annual energy number. The customer sees a conclusion but cannot see the path that produced it. A better explanation uses a sequence of visuals, with each visual doing one job and carrying its own limits.

For an installer, designer, or sales lead, that sequence is more than presentation polish. It is a review trail. It shows which roof area was considered, what could block sunlight, how the sun’s position changes, which inputs shaped the model, and what still needs confirmation. The aim is informed discussion, not visual certainty.

The U.S. Department of Energy’s solar radiation primer explains that the solar resource reaching a surface varies with location, time of day, season, weather, and surface orientation. A customer does not need a physics lecture, but the explanation should preserve those variables. One attractive heat map cannot carry them all.

Build the explanation as a chain of evidence

Start with what the customer can recognize and move toward what the model infers. This order matters. If the first image is a colorful production chart, the customer may read the result as measured truth. If the first image is the actual roof with sources and uncertainties labeled, later estimates have a visible foundation.

Use a simple test for every graphic: what exact question does it answer? A roof image answers, “Which surface are we discussing?” An obstruction plan answers, “What could interrupt sunlight?” A sun-path diagram answers, “When can that interruption occur?” A monthly chart answers, “How does the modeled result change through the year?”

The visual should also say what it does not answer. An aerial image does not verify roof condition. A path diagram does not quantify energy loss by itself. A monthly estimate does not guarantee a future utility bill. These boundaries make the explanation stronger because they stop one visual from pretending to be an entire design review.

Keep the visual sequence connected to the wider solar design workflow, where each drawing can remain tied to the input and project stage that produced it.

1. Anchor the discussion with an annotated roof image

The first visual should help a customer say, “Yes, that is my roof.” Use a current, legible overhead image or survey drawing. Mark roof planes, orientation, proposed array zones, obvious obstructions, and areas excluded from the concept. Add a small source note with the image date if available.

Do not overload this view with simulation colors. Its purpose is orientation. A customer who cannot tell which structure, slope, or carport is under discussion will struggle to interpret any later diagram. On a commercial site, include building names or zone labels that match the project record. On a residential roof, use plain labels such as front, rear, garage, and extension.

Draw uncertainty visibly. A dashed outline can mark a roof edge inferred from imagery. A question icon can identify an object that might be a vent, skylight, or image artifact. A note can state that tree height comes from imagery rather than a field measurement. This is more useful than quietly choosing an interpretation and letting it harden into the design.

Image age matters. Roof work, tree growth, new mechanical equipment, neighboring construction, and changed parapets can make an old scene unreliable. The Department of Energy’s homeowner guide tells prospective buyers to consider roof condition and shading among the practical questions before installation. That does not make a satellite image wrong; it makes its observation date part of the evidence.

For preliminary work, say “concept area based on available imagery.” Reserve stronger language for geometry and conditions that have been measured and reviewed. If a site survey later changes the usable area, the customer can see why the plan changed rather than assuming the team reversed an unexplained promise.

2. Separate obstructions from their predicted effects

An obstruction plan names physical objects before discussing shade. Mark trees, chimneys, vents, dormers, parapets, rooftop units, adjacent structures, poles, and other visible features. Also distinguish objects that occupy array space from objects that may cast shade. A skylight can affect placement even when it casts little shade. A distant tree may cast shade without occupying the roof.

This separation prevents a common communication error: using the word “shading” to cover every reason a module was not placed somewhere. Fire access, maintenance access, structural limits, roof condition, drainage, and electrical routing are not solar-access effects. If they matter, give them their own label or layer.

Use a consistent symbol key. Solid shapes can mean observed objects. Outlined shapes can mean inferred objects. A third status can indicate “confirm on site.” Color alone is insufficient because customers may print the proposal in grayscale or have color-vision differences. Combine color with shape, border, text, or hatching.

When an obstruction came from a field survey, cite the survey date. When it came from plans, name the drawing and revision. When it came from imagery, name the provider or internal record. Evidence labels allow a reviewer to resolve conflicts. They also tell the salesperson what to ask when the customer says, “That tree was removed last month.”

Do not claim that every marked object produces a particular loss unless the analysis supports it. The plan is an inventory, not the result. Its job is to make the modeled horizon understandable and to expose missing objects before they become buried inside an annual figure.

3. Use a sun-path diagram to explain time and season

A sun-path diagram maps solar position across time for a particular location. It can show why a chimney west of an array matters differently in the morning than in the afternoon, or why an obstruction’s winter effect may not match its summer effect. The key is to teach the customer how to read the axes before drawing a conclusion.

Label compass direction, elevation angle, month or representative date, and time convention. Clarify whether clock times reflect solar time or local civil time. Without these labels, a precise-looking curve can be misunderstood. North and south orientation also need care across hemispheres. Avoid a generic diagram detached from the project’s actual latitude.

The sun’s seasonal path helps explain why a single midday photograph is incomplete. One photograph records one moment under one sky. It cannot show the range of positions across a year. Conversely, a computed path does not show clouds or prove the exact outline of a tree. Pair geometry with site evidence instead of asking either to do both jobs.

The solar resource maps from the National Laboratory of the Rockies (NLR, formerly the National Renewable Energy Laboratory/NREL) illustrate how solar resource information is tied to geography and defined metrics. A project-level sun path is more local than a resource map, but the same communication discipline applies: name location, units, period, and data basis.

Avoid placing a percentage in the center of the diagram unless its method is explained nearby. Customers often treat a prominent percentage as a grade. Solar access is better discussed as a condition over relevant times, tied to a model and a design decision. If the metric excludes early or late hours, uses a specific weighting method, or applies only to one point, state that scope.

4. Turn a shade view into a time-based explanation

A shade visualization is useful when it shows a relationship between an obstruction and a period, not merely dark patches on a roof. Use snapshots at selected times, a horizon profile, or a time grid depending on the decision. Each format has a different strength.

Snapshots are intuitive. They let a customer see how a modeled shadow moves over the array on a representative date. Their weakness is selection: a few attractive frames can omit the periods that drive the design conversation. State why the dates and times were chosen, and do not imply that the frames represent every condition.

A horizon profile is less familiar but often more explanatory. It places obstruction elevation against azimuth, then overlays the solar path. This lets the reader see when an obstruction intersects the path. Add plain-language annotations, such as “tree line may affect late-afternoon sun in this period,” rather than expecting a customer to decode the plot alone.

A time grid can summarize months and hours. It is good for locating patterns, but its color scale must be explicit. Does a dark cell mean blocked beam radiation, low irradiance, modeled energy reduction, or simply an obstruction angle? Those are not interchangeable. Put the metric and units beside the legend, not in a remote appendix.

The technical model still requires review. Obstruction dimensions, terrain, roof geometry, module placement, diffuse irradiance treatment, and weather inputs can affect results. If vegetation changes, consider whether the model represents current height, expected maintenance, or an unresolved future condition. Do not convert a living tree into a permanent numeric promise.

5. Connect solar access to monthly production without hiding the model

Once the physical story is clear, a monthly production chart can connect sunlight conditions to the modeled energy discussion. Monthly bars are usually easier to interpret than one annual total because they expose seasonal variation. They can also reveal an assumption error that an annual sum conceals.

Put the chart’s basis directly below it: system configuration, orientation, weather data source, loss assumptions, and whether shade effects are included. If two scenarios are compared, change one major factor at a time when possible. A “with current tree” and “without current tree” comparison may help evaluate a question, but it should not imply permission to remove vegetation or guarantee the modeled difference.

PVWatts estimates energy production for grid-connected PV systems from user inputs and a defined calculation process. NLR’s System Advisor Model supports more detailed performance and financial analysis. Either kind of model needs inputs. A software output does not become measured evidence because it is presented to the nearest kilowatt-hour.

Use “modeled annual energy” or “modeled monthly energy,” not “your panels will produce.” Weather varies, equipment behavior changes, and the as-built system may differ from the preliminary concept. A proposal should state its observation date and modeling boundary. If no field survey has occurred, say so before the customer reaches the chart.

Charts should start at zero when bar height represents energy magnitude. Avoid perspective effects and decorative curves that exaggerate small differences. Provide numbers in a table when a customer may need to compare or share them. A visual can invite attention, but the underlying values and assumptions should remain accessible.

The PVWatts technical reference documents inputs and modeling choices behind that tool. You do not need to reproduce the equations in a proposal. You do need to preserve the distinction between a tool’s calculation and the site evidence supplied to it.

6. Make an assumption key part of the picture

An assumption key is often the most honest visual in the proposal. It can be a compact panel with four columns: input, value, evidence, and status. Use statuses such as confirmed, modeled, assumed, and field verification required. The customer can then see which conclusions rest on stable evidence and which may change.

Do not bury decision-changing assumptions in eight-point text. Roof dimensions inferred from imagery, vegetation height, future consumption, equipment availability, tariff details, and access constraints can alter the discussion. Place the important ones near the visual they affect. A full register can sit elsewhere, but the customer should not have to hunt for the reason a chart might change.

Give each open item an owner and a next action. “Tree height assumed” is incomplete. “Tree height estimated from imagery; site assessor to measure before final layout” is operational. The second version explains how uncertainty will be resolved.

For internal review, link visual callouts to the project record. A designer should be able to trace an obstruction label to a survey photograph or note. A sales representative should be able to trace a usage figure to a bill period. This is where solar site survey data collection and a consistent evidence naming scheme support the customer conversation.

An assumption key also limits accidental version drift. If a roof image is replaced but the old production chart remains, mismatched observation dates become visible. If a customer supplies a new bill, the record shows which scenarios need recalculation. Visual consistency is therefore part of change control, not merely branding.

7. Compare options by changing one decision at a time

An option visual should help a customer understand a choice. Compare layouts by the variable that actually changes: array zone, module count, obstruction treatment, orientation, or a defined constraint. Keep the base assumptions the same, and list any exceptions. Otherwise the comparison mixes causes and prevents a sound conclusion.

Side-by-side roof plans can compare physical use. A small table can compare modeled energy, required verification, and operational tradeoffs. Avoid presenting a single score that hides those dimensions. A lower-capacity layout may preserve access or avoid uncertain roof area. A higher-capacity concept may depend on structural or electrical work not yet assessed.

Do not call one option “recommended” unless the recommending role, criteria, and evidence are clear. Design software can organize scenarios, but the responsible people still need to judge site, engineering, authority, utility, financial, and contractual constraints. Solar shading analysis can inform the comparison without deciding every other project issue.

Keep customer control visible. If tree work is one scenario, state that it depends on ownership, permission, cost, condition, and local requirements. If equipment substitutions are possible, explain that final selections need current documentation and review. The visual should expose the decision, not quietly assume it has been made.

How should a solar team choose the next visual in the explanation?

A solar team should choose each visual from the customer’s next question and the evidence maturity of the project. Start with a recognizable roof image, then show obstructions, solar position, modeled shade, production implications, assumptions, and options only when each layer is supported. Skip any graphic whose source, time basis, status, or decision purpose cannot be explained beside it clearly.

Write the customer’s question above the empty slide or content block before choosing a format. “Why is the west roof area open?” calls for an annotated spatial view. “When could that tree interrupt direct sunlight?” calls for a sun-path and obstruction relationship. “What changed between these concepts?” calls for a controlled comparison. A decorative solar photograph cannot answer any of those questions.

Next, decide whether the project evidence is mature enough for the requested visual. A current survey can support a different level of detail than old aerial imagery. A verified obstruction record can support a more grounded shade discussion than an unidentified object in a screenshot. When the evidence is early, the visual should become more explicit about status, not more visually confident.

Use the following routing table during proposal planning:

Do not show every available output because the software can export it. Extra views create new questions, new accessibility work, and more opportunities for versions to disagree. Choose the smallest sequence that lets the customer check the property, understand the controlling relationship, see the assumption boundary, and identify the next verification step.

Illustrative workflow example, not a customer result: A proposal reviewer sees a request for an annual shade percentage but finds that the team has only an older roof image and an unconfirmed tree outline. The reviewer replaces the unsupported result with an annotated obstruction question, assigns a site check, and reserves the time grid and production comparison for the reviewed scenario.

That change does not make the early conversation less useful. It gives the customer a concrete fact to correct and gives the project team a defined evidence gap to close. Once the site record changes, the visual sequence can advance without pretending the earlier source established more than it did.

What should every solar access visual disclose?

Every solar access visual should disclose property or example, source, observation date, orientation, time convention, unit, model or measurement status, version, and unresolved field checks that affect interpretation. The visual should also state what it cannot establish. A reader must be able to distinguish observed roof evidence from modeled sunlight, energy estimates, judgments, and approvals that remain outside its scope.

Place the decision-critical facts where the customer encounters the image. The property or example label belongs in the title or subtitle. The source, date, version, and status can sit in a compact provenance line. The legend should name the metric and unit. A nearby note should identify the limitation most likely to change the customer’s conclusion.

Treat absence as a status, not an invitation to fill the blank. If tree height is unknown, label it unknown or estimated from the stated source. If an image date is unavailable, say that the capture date is unconfirmed. If field verification has not happened, do not use “confirmed” for geometry merely because several team members have reviewed the same remote image.

Use this copy-ready disclosure record for each customer-facing visual:

1. Visual identifier and version:
2. Property, building, roof zone, or labelled illustrative example:
3. Reader question:
4. Image, survey, drawing, dataset, or model source:
5. Observation, retrieval, survey, drawing, and model dates that apply:
6. Orientation, location, time convention, period, metric, and unit:
7. Status of each important input: observed, supplied, inferred, assumed, modeled, or unknown:
8. What this visual supports:
9. What this visual cannot establish:
10. Field check, reviewer, or approval still required:
11. Owner, expiry event, and derivative locations:

The record should travel into the proposal source, not live only in an editor’s notes. When a roof image changes, an owner can identify which shade view, chart, option table, and customer document depend on it. When the design advances, the team can retire the preliminary image or mark it superseded rather than leaving two confident-looking versions in circulation.

Customer privacy also belongs in the disclosure workflow. Remove names, account identifiers, addresses when they are not needed, and fine-grained usage information from examples intended for reuse. Obtain the permissions required by the organization. A clean crop is not proof that the source was authorized or that the remaining visual cannot identify the site.

How can a salesperson review solar access visuals before a meeting?

Before a solar access visual reaches a customer, reviewers should confirm the correct site, current sources, geometry, orientation, dates, time basis, units, legend, scenario, and evidence status. They should compare every view for consistent array areas, obstructions, and assumptions, then test the explanation with someone unfamiliar with the model. Any mismatch or overclaim must return to its owner before release.

The salesperson does not need to reproduce the shade or energy model. The job is to catch a broken explanation and route technical questions to the responsible reviewer. Begin by matching the address, building labels, roof zones, and visual versions with the opportunity record. Then compare the annotated image, obstruction plan, shade view, production chart, and assumption key side by side.

Look for small mismatches that change trust quickly. Does a tree disappear between the obstruction plan and shade view? Does the proposal use different module areas in two images? Does a monthly chart refer to a scenario name that does not appear in the option table? Does the legend say “loss” without identifying whether it means blocked beam radiation, an energy-model factor, or another metric?

Run a spoken review rather than reading captions silently. Ask the salesperson to explain each visual in plain language, including one limitation and one next action. If the explanation needs “the software says” as its evidence, stop and retrieve the source or reviewer note. If the salesperson cannot distinguish observed from modeled information, the customer is unlikely to make that distinction unaided.

Use this short meeting-release checklist:

1. Confirm identity, source dates, visual versions, and the project stage.
2. Verify that each visual answers one named customer question.
3. Compare roof areas, obstruction labels, scenario names, and assumptions across every view.
4. Read all units, legends, statuses, and decision-changing qualifications aloud.
5. Check that accessible text and the numeric table carry the same conclusion.
6. Identify which questions the salesperson can answer and which must go to design, engineering, finance, the utility, an authority, or another qualified reviewer.
7. Record unresolved issues and remove any visual that has no accountable owner.

If the customer corrects an obstruction, roof change, or usage input during the meeting, capture the correction as new evidence. Do not improvise a revised production conclusion on the spot. Route the input through the project’s change process, update dependent outputs, and return with a version that can be traced and reviewed.

A seven-visual review sequence

Use this order as a meeting path rather than a rigid page template:

1. Confirm the correct property and roof area on the annotated image.
2. Ask the customer to correct the obstruction plan before discussing results.
3. Explain the project’s sun path with direction, season, and time labels.
4. Show where modeled obstruction and sun path intersect.
5. Connect those conditions to monthly modeled production.
6. Review the assumption key and assign unresolved checks.
7. Compare only the options the current evidence can support.

Pause after steps two and six. Those are the best points for the customer to supply corrections. A presentation that waits until the final slide to ask for questions misses the customer’s most useful knowledge: recent site changes, plans for the property, and priorities that affect the choice.

The sequence can be shortened for a simple roof, but do not remove the evidence boundary. A customer should leave knowing what was observed, what was modeled, what was assumed, and what happens next. That is a better standard than whether the graphics looked impressive.

Review the visual package before it reaches the customer

First, verify identity and dates. Confirm the address, building, image date, survey date, drawing revision, and model run. Then check orientation, labels, units, legends, and accessibility. Make sure each chart names its metric and each plan names its source.

Next, compare the visuals with one another. The module count should agree across the roof plan, equipment summary, and modeled scenario. Obstructions should not disappear between views without explanation. A changed assumption should trigger review of every dependent output. See the solar proposal pre-send checklist for the wider customer-document review.

Finally, read the words as a customer would. Remove guarantees and unexplained scores. Replace “accurate” with the actual evidence status. Replace “optimal” with the criteria being optimized. State remaining survey, engineering, authority, utility, equipment, and contract reviews.

For SurgePV, results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Frequently Asked Questions

What does solar access mean in a customer conversation?

Solar access describes how much useful sunlight reaches a proposed array location over relevant times and seasons. It is not a promise of annual production. Explain the roof area, surrounding obstructions, modeled sun positions, weather basis, and remaining field checks so the customer understands both the opportunity and the uncertainty.

Is a sun-path diagram the same as a shading analysis?

No. A sun-path diagram shows where the sun appears by time and season for a location. A shading analysis adds the horizon and obstruction profile that may block that path. The diagram explains geometry; the analysis estimates the effect using stated inputs, methods, and assumptions.

Which visual should appear first in a solar proposal?

Start with an annotated roof image that lets the customer recognize the property and proposed array area. Follow it with the obstruction or shade visual that explains the main design constraint. Production charts belong later, after the physical evidence and modeling assumptions that support them have been made visible.

Can satellite imagery replace a solar site survey?

Satellite or aerial imagery can support preliminary design, but it cannot confirm every dimension, roof condition, obstruction, electrical detail, access issue, or recent site change. Label image dates and uncertain features, then state which conditions require field measurement or review before design, engineering, permitting, procurement, or construction decisions.

How much technical detail should a homeowner see?

Show enough detail for the customer to connect a conclusion to visible evidence. Define unfamiliar terms, label units, and move secondary settings into an assumptions panel. Do not hide a decision-changing limitation merely because it is technical. A clear visual should simplify navigation through the evidence, not remove the evidence itself.