What DraftBetter taught us about tone

The messages that cost people the most time are short. Declining an invitation. Chasing an invoice that is three weeks late. Telling a client the scope has changed. None of them are hard to write in the sense of being long — they are hard because getting the tone wrong has a cost, and you can feel that while you are typing.

We built DraftBetter for exactly those messages, and the first thing we got wrong was treating tone as a property of the words. It is not. It is a property of the relationship, and you cannot infer the relationship from the draft.

Tone is not an adjective

The obvious design is a dropdown: formal, casual, friendly. We built that. It produced text that was recognisably in the right register and still wrong, because the same sentence carries different weight depending on who is receiving it. "I need to push our deadline" is routine to a colleague and alarming to a client who has already paid.

Formality and warmth are also independent. A message can be formal and kind, or casual and cold. Collapsing both into one control meant people picked the closest option and then rewrote the output anyway — which is the exact work they came to avoid.

The missing input was the relationship

What actually improved the output was asking two things the draft cannot tell you: who this is going to, and what is at stake. Those two answers change more than any tone setting. A decline to a close friend and a decline to a prospective client share almost no structure — the friend version can open with the answer, the client version has to earn it.

• Who they are to you sets how much context the message needs before it gets to the point.
• What is at stake sets how much softening is appropriate before it reads as evasive.
• What you have already said to them decides whether this is a first message or a follow-up, which changes the opening entirely.

A useful test while building: if a tone control produces text you would send to two different people unchanged, the control is not doing anything. Real tone is specific to a reader.

Sharpening beats replacing

The second correction was about ownership. Early versions produced a polished message from a short prompt, and people did not send them. The text was fine. It just was not theirs, and sending something that does not sound like you to someone who knows you is worse than sending something clumsy.

So the flow starts from your rough version rather than from a blank field. You write the blunt one — the one you would never send — and the tool adjusts it. The vocabulary, the rhythm and the specific details stay yours. What changes is the framing, the order and the amount of cushioning.

Length is a tone control too

This surprised us. People associate length with effort, and effort with respect. A one-line decline reads as dismissive even when the words are warm. A five-paragraph decline reads as guilty. Giving length its own control did more for perceived tone than adding tone options did, because it let people match the weight of the message to the weight of the relationship.

What we took from it

Rewriting a difficult message is a design problem before it is a language problem. The quality of the output depends almost entirely on which questions you ask before generating anything, and the useful questions are about people rather than prose. That lesson has outlived this product — it is the same reason the other things we build ask about context first and generate second.