Naming, tone and consistency

Good software feels coherent. Buttons say what they do, labels match across screens, and the tone holds steady from the landing page to the empty states. Vorx handles the build — the words are yours to guide, and a little direction up front is what makes an app feel considered rather than generic.

Name things once, use them everywhere

Decide what your core objects are called and stick to it. If a record is a Deal, it should be a Deal in the menu, the button, the table header and the confirmation message — never a Lead on one screen and an Opportunity on another.

Tell Vorx your vocabulary directly:

Call customer records Clients everywhere, and call each booking a Session, not an Appointment.

This is worth saying early. Your nouns land in the design stage and become the entities themselves, so naming them up front keeps the data model, the screens and the copy using one word for one thing.

Set the tone deliberately

Tone is a choice, and Vorx follows the one you describe. A finance dashboard and a hobby tracker shouldn't sound the same. Name the voice you want and give an example:

• "Keep the copy calm and professional — plain, reassuring, no exclamation marks."
• "Make the tone warm and encouraging, like a friendly coach."
• "Keep microcopy short and direct; prefer verbs like Save and Send."

If you have brand guidelines, paste the relevant lines into your prompt. Vorx applies that voice across headings, buttons and messages.

Mind the small copy

The words users notice most are often the smallest: empty states, error messages, tooltips and confirmations. They're easy to overlook and easy to fix.

Ask for them explicitly once the main screens exist:

Write friendly empty states for every list — tell the user what the screen is for and how to add the first item.

Empty states in particular turn a blank, confusing screen into a helpful one. They're worth a prompt of their own — and worth checking in the preview before you have data, because that's the version a new user sees.

Keep buttons honest

A button should say exactly what happens when you press it. "Delete permanently" beats "OK". "Send invoice" beats "Submit". Precise labels reduce hesitation and mistakes.

When you spot a vague control in the preview, fix it where you found it: switch to visual mode, click the button, and say what it should read. No need to describe which of four buttons you meant.

Stay consistent as you grow

As you add screens, new copy drifts from the tone you set. Periodically ask for an alignment pass:

Review all button labels and section headings for consistent capitalisation and wording, and match the tone we agreed.

A quick pass every few builds keeps a growing app feeling like one product rather than a patchwork. If a pass overreaches, roll it back — it costs nothing — and ask again more narrowly.

A short style note goes a long way

Before you build heavily, write two or three sentences describing your naming and voice, and reuse them in prompts. It becomes a lightweight style guide keeping every screen pulling in the same direction.

Clear words make even a simple app feel trustworthy. Pair this with design systems to keep the look as consistent as the language.

In the docs: Components and design.