Why a distinctive title needed fewer options, not another display mode

The request was to make a title feel more distinctive. The first proposal was a separate title style, a new display mode sitting beside the existing ones. The better answer was to use the title style that already existed and expose the missing controls that made it useful.

A feature request can sound like a request for a new option: a new display mode, a new kind of setting, a new workflow, a new screen. The first instinct is often to add a parallel branch. That is sometimes right. Before doing it, ask what existing capability the request is asking us to expose.

Find the pattern before you build a branch

Mature products often have more capability than their visible interface suggests. A setting may already have a shared rendering pattern, a standard way to save changes, a rule for when it should appear, and a consistent way to recover from a mistaken edit. The product may need only one well-placed control.

Before designing a parallel feature, look for:

• a nearby control with the same data shape;
• an existing save path that already validates and persists similar settings;
• a visibility rule that already separates applicable contexts from inapplicable ones;
• a tested rendering or interaction pattern that users already recognize; and
• a documented owner and change process for the capability you are extending.

Reusing a pattern still needs review. You inherit behavior that has already been tested and understood, and you check that the new use belongs inside its boundaries.

Reuse the gate, not just the presentation

The strongest part of an existing pattern is often invisible. A control may appear only when it applies, stay unavailable when it could confuse or harm a user, and save through a validated path. A parallel feature has to recreate every one of those decisions. An extension inherits them when the shared condition represents the same product rule.

So read what a condition protects before you copy it. Confirm the new control has the same applicability, accessibility, authorization, data-handling and lifecycle requirements. Then test a negative case: a place where the control should not appear or should not take effect. The happy path will look consistent either way, so the negative case is the one that tells you.

Test away from real customer impact

A familiar interface can make a change feel low-risk when it is not. Before a demonstration or release, use an authorized non-production environment or representative test data. Confirm that the change saves correctly, appears only where intended, preserves existing content and can be reversed. Access to live customer data gives you no test plan, so write one.

Record what changed, who approved it, what was tested and how to recover if the feature behaves unexpectedly. A small extension with that record is easier to trust than a large new branch with unclear boundaries.

Why less code can mean more coherence

A parallel option usually brings a parallel set of problems: its own visibility rules, persistence logic, rendering behavior, documentation, support questions, analytics and eventual migrations. Each one is another place for the product to drift.

When an existing pattern fits, the new behavior gets the same semantics as its neighbors. Users find it where they expect it, and maintainers can reason about it through the same model. The product gains capability and nobody has to learn a second way to do the same job.

Start from what is already close

When a request arrives, we start by asking which part of the product is already close, and what is missing from its public surface. A new branch is justified when the underlying job, risk, ownership or lifecycle is different. Otherwise, exposing the right control on a trusted path gives us less duplication, clearer behavior and safer change management.

dxdev LESSON · paste into your AI agent

LESSON: Apply the Lesson: Before adding a new option, ask whether the existing one is almost right

WHAT TO SHARE:
A short description of the work, the problem you are seeing, the constraints that matter, and any de-identified examples or notes you want reviewed.

ASK YOUR AGENT TO:
1. Restate the problem in plain language and identify the assumption that needs checking.
2. Separate observations from guesses and list the evidence that is still missing.
3. Suggest a small, reversible next step or review plan that fits the situation.
4. Identify the decisions, approvals, and safeguards that should remain with a person.

RETURN:
A concise table with the problem, evidence to check, safe next step, human owner, and questions to resolve.

BOUNDARY: Analyze and recommend only. Do not alter code, records, files, permissions, settings, external systems, or published content. A responsible person must review and approve any action.