A support tool's reply-toolbar molecule grew from send and attach buttons to macros, template search, an assignee picker and a status menu; how do you diagnose and fix it?
answer
- single responsibility drift
- purpose needs the word 'and'
- feature switches in the contract
- unrelated reasons to change
- extract focused molecules, compose above
basics
~20 sIt has become several components in one: its purpose needs 'and', its contract grew feature switches and unrelated teams edit it. Extract one focused molecule per job and compose them in a larger component that keeps the familiar layout.
solid answer
~40 sA molecule should do one focused job; this toolbar now does five. I would confirm it from the contract and history: a purpose that needs 'and', show-or-hide switches that turn whole features off, changes driven by unrelated teams, callers such as the mobile compact reply that disable most of it, and flag-combination tests. The fix is to name the jobs — act on the draft (send, attach), insert saved content (macros, template search), change ticket properties (assignee, status) — extract one molecule per job, and compose them in a larger component so agents keep the layout they know. Then migrate callers deliberately and delete the switches. I would not split too far: send and attach share one draft and its busy state, so they can reasonably stay together.
go deeper
Recall that a molecule should do one focused job, and that a component which many screens mostly switch off is a warning sign.
Explain the diagnostic signals — a purpose needing 'and', feature switches, unrelated reasons to change — and why each makes the component harder to test and reuse.
Walk through the split: naming the jobs, extracting focused molecules, composing above to keep the layout, migrating callers and deleting switches, while avoiding over-splitting.
Discuss how contribution cost and review triggers shape whether teams bolt features onto existing molecules, and how the system team keeps large components honest over time.
## The symptom In **atomic design**, a **molecule** is a relatively simple group of atoms working as one unit with one focused purpose. Brad Frost ties the level to the **single responsibility principle**: burdening one pattern with too much complexity makes it unwieldy. Real systems drift. In a customer-support ticketing tool, the reply toolbar under the message composer started as a molecule of two atoms — send and attach. Over a year, teams added a macro button, a canned-reply template search, an assignee picker and a status menu, because the toolbar was where agents' hands already were. It still occupies one strip on screen, but it now does five jobs. ## Diagnosing it The signs usually show in the contract and the change history before anyone looks at pixels: - **The purpose needs 'and'.** 'Sends a reply and attaches files and applies macros and searches templates and changes assignment and status' is several purposes. - **Feature switches in the contract.** Inputs such as show-macros or hide-status turn whole jobs on and off. Each switch multiplies the combinations to test and document. - **Unrelated reasons to change.** The file changes when the routing team changes assignment rules and when the knowledge-base team changes templates; their releases collide in one component. - **Callers use a fraction of it.** The compact reply on the native mobile app turns most features off; the internal-note composer turns off others. A component most callers mostly disable is several components. - **Pass-through sprawl.** Dozens of inputs forwarded to atoms the molecule barely coordinates signal a container, not a unit. - **Combinatorial tests.** Verifying one change means exercising many switch combinations. ## Fixing it 1. **Name the focused jobs.** Here: act on the drafted reply (send, attach); insert saved content (macros, template search); change ticket properties (assignee, status). 2. **Extract one molecule per job**, each with a short contract: a reply-actions molecule, a template-search molecule that reuses the system's search field, and property controls that each pair a label with a control. 3. **Compose at the level above.** The arrangement agents know — everything in one strip under the composer — becomes a larger component that places the new molecules side by side. The layout survives; it stops pretending to be one unit. 4. **Migrate callers deliberately.** The old contract changes, so treat it like any breaking change in a shared library: announce it, keep the old name as a thin composition of the new parts for a stated period, then remove it. 5. **Delete the feature switches.** Callers that used to turn features off now simply leave those molecules out. | Before | After | |---|---| | One molecule, five jobs, many feature switches | Focused molecules plus one composing component | | Several teams edit the same file | Each molecule has one reason to change | | Tests cover switch combinations | Tests cover each molecule's single behaviour | | Mobile compact reply disables most of it | Mobile composes only the molecules it needs | ## Not splitting too far The opposite failure is real. Splitting send and attach into separate molecules would lose a relationship that matters: both act on the same draft and share its busy state while an attachment uploads. A good split keeps parts together when they share **one purpose and a fixed relationship**, and separates them when they have **different reasons to change**. That is a judgement, not a rule; a team with a different upload flow might reasonably split them. ## Preventing a repeat - Ask each molecule's documentation to state its purpose in one sentence without 'and'. - Treat a new feature switch on a molecule as a review trigger: is this a variant of the same job, or a second job? - Keep the path for contributing a new molecule cheap, so teams stop bolting features onto the nearest existing one. - Revisit the largest molecules periodically by counting their inputs and their distinct callers' configurations. The molecule level is useful precisely because it resists accumulation. When a molecule does accumulate, the level makes the drift visible — if the team is looking.
- The product lead objects that splitting will change what agents see; how do you respond?The split is structural, not visual. The composing component reproduces the current strip, so agents see the same controls in the same places. What changes is that each job has its own contract, tests and owner, and screens like the mobile reply can include only what they need.
- How do you tell a legitimate variant from a second job when someone asks for a new switch?A variant changes how the same job looks or behaves in a context — compact density, icon-only buttons. A second job adds something the molecule's one-sentence purpose does not cover. If describing the request needs 'and' in the purpose statement, it is a second job and belongs in its own molecule.
saying these in an interview costs you the question
- It all sits in one strip on screen, so it must stay one molecule.
- Adding show-or-hide switches is a cheap, harmless way to extend a molecule.
- Splitting it means agents must get a different layout.
- Every pair of atoms should become its own molecule to be safe.
- The old contract can be removed at once without telling consuming teams.