skip to content

In an insurance claims portal, when should auto, home and travel claim-detail screens share one template, and when does each need its own?

level: middleimportance: nice to knowfreq 26%

answer

  1. same skeleton, different fillings
  2. regions, order, hierarchy
  3. fill differences stay in regions
  4. structure differences justify a split
  5. god template versus drifting copies

basics

~20 s

Share one template when the screens have the same skeleton — regions, order, roles and hierarchy — even if different organisms fill them. Give a screen its own template only when its structure differs, not merely its content.

solid answer

~40 s

The test is the **skeleton**, not the content. Auto, home and travel claims all have a summary, a timeline, documents, messages and next steps in the same order with the same heading hierarchy; what differs is what fills a region — vehicle details versus property details versus trip details. That is one template, with the application choosing the organism per product line. A separate template is justified when the **structure** differs: travel claims needing a multi-leg itinerary region placed above the timeline, changing reading order and hierarchy, would qualify. Too few templates produce a 'god template' full of optional regions and switches; too many produce copies that drift, so a layout or landmark fix lands in one and not the others. When in doubt, count what would differ: fillings mean share, regions mean split.

go deeper

for a junior

Recall that a template is the skeleton, so screens with the same regions and order can share one even when their content differs.

for a middle

Apply the skeleton test — regions, order, hierarchy, reflow, empty behaviour — and explain why different fillings do not justify a new template.

for a senior

Show how you would spot a god template or drifting copies in a real portal, and when a structural request justifies a split or a shared frame.

for a principal

Discuss how template granularity affects consistency across product lines and who arbitrates structural requests from competing product teams.

## The decision In **atomic design**, a **template** is a page-level skeleton: it places organisms into regions and shows the content structure, while real content arrives at the page level. A portal with several product lines has to decide how many skeletons it needs. In an insurance claims portal, auto, home and travel claims each have a claim-detail screen. One template, or three? ## The skeleton test Compare the screens on the properties a template owns: - **Regions** — which areas exist. - **Order** — the reading and visual sequence of those areas. - **Roles and hierarchy** — which region is the primary content, which is supporting, and what heading levels they use. - **Reflow** — how the regions rearrange when space is narrow. - **Empty behaviour** — what each region does with no content. If all five match, the screens share a skeleton, however different their content. ## Applying it to three product lines | Property | Auto | Home | Travel | |---|---|---|---| | Summary region | vehicle, incident, status | property, incident, status | trip, incident, status | | Detail region | vehicle and repair-shop details | property and contractor details | itinerary and provider details | | Timeline, documents, messages | same | same | same | | Order and hierarchy | same | same | same, unless the itinerary must lead | The differences sit **inside regions**: the detail region holds a vehicle-details organism for auto and a property-details organism for home. That is one template, with the application choosing which organism fills the detail region for each product line. Travel is the interesting case. If a multi-leg itinerary needs its own region **above** the timeline, the reading order and heading structure change. Then the travel screen has a different skeleton, and a second template is justified. ## The cost of too few templates Forcing every screen into one template produces a **god template**: 1. Optional regions accumulate for single product lines. 2. Switches appear to reorder regions for one case. 3. Every change must be checked against every product line. 4. The structure the template was meant to communicate becomes unreadable. ## The cost of too many templates Copying the skeleton per product line looks harmless and costs later: - A fix to reflow behaviour or landmark roles lands in one copy and not the others. - The copies drift in spacing and order, so claims look inconsistent across products. - Reviewers must review three near-identical layouts for every change. ## A practical rule Count what would differ: - **Only fillings differ** — which organism goes in which region — so share the template. - **Regions, order or hierarchy differ** — so split, and give the new template a name that states its structural difference. - **Unsure** — build the shared template first and watch whether requests start asking to move or add regions for one product line; that is the signal to split. The same rule applies on every platform: a native claims app decides between one screen scaffold and several on the same grounds, and a design editor's library holds one frame per distinct skeleton, not one per product line. ## Common mistakes - Splitting templates by business line because the org chart is split that way. - Keeping one template long after a product line's structure diverged, patched with switches. - Treating visual differences inside a region as a reason for a new skeleton.

  • A home-claims product manager wants the documents region above the timeline because home claims rely on photos; share or split?
    That is a structural difference — region order — so it is a genuine reason to split, or to make region order a documented variant if several product lines want it. First check whether the need is real for all home claims or only some; a region-order switch used once is the start of a god template.
  • Can two templates share parts of their skeleton?
    Yes. Teams often extract a common frame — header, footer, sidebar placement — used by several templates, so each template defines only its main area. That keeps landmark and reflow fixes in one place while allowing structural differences where they are real.

saying these in an interview costs you the question

  • Each product line should get its own template by default.
  • Different organisms in a region mean the screens need separate templates.
  • One template with switches can cover any structural difference.
  • Copying a template per product line costs nothing later.
  • Business-unit boundaries decide how many templates exist.