Connecting a domain you already own, without losing your email
Two independent proposals answering the same brief, produced under the same conditions,
with the same access and the same budget, and presented here for review side by side.
A customer wants visitors to reach their new website using a domain they already own.
Their existing email must continue working.
The brief named no solution. Deciding what the customer actually needs — and which
journeys matter — was part of the task. Each proposal spans a customer portal and an
internal operator portal, and each chose its own page structure.
These are mirrors, not the product. Every customer, domain, mail provider, server and
request in them is invented; addresses come from the reserved documentation ranges and the
reserved .example and .invalid domains. Nothing here changes DNS,
email or hosting, and no page is connected to any real system.
Draft 1
Branches on how the customer is about to make the change — edit the records,
use a provider wizard, or move nameservers — and refuses the one that would take
the mail down. The operator's actions are gated in order, and the last one is held while
the mail check is failing.
Branches on where the domain's DNS currently lives, treats “I don't
know” as a real answer, and labels every state with how it was established and by
whom. The operator cannot hand over nameservers until the customer confirms their mail
records are back.
Start on the customer side and go all the way through to submitting. Then open the
operator screen for the same request and try to finish the job. Then go back to the
customer's page and see whether the two agree about what happened. That round trip is
what the two proposals differ on most.
Observed and proposed
Both drafts label what they observed in the current product separately from what they are
proposing. Draft 1 mirrors two of today's screens directly so the difference can be
compared rather than taken on trust. Neither draft claims a turnaround time, a service
commitment or a business policy, and neither should be read as one.
Known defects
Both drafts were reviewed by an independent reviewer who did not know how either was
produced, and both were left exactly as their authors made them — nothing was
repaired before review. Draft 2's submit lands on a page that reports work as finished
before it has happened; draft 1 tells the operator the mail records were preserved on the
one route it has just warned may destroy them. Neither has been fixed here on purpose.
Reviewing these
Judge the rendered experience, not the page count. A simulated state change on these
pages is not evidence that a real operation would succeed.