Best practices for AI App Design

Describe the work, not the screens

Say what you need to keep track of, who uses it and what they need to find. "We lend laptops to staff and need to know who has which one and when it is due back" gives a better first design than a list of field names.

Change one thing at a time

Short requests ("add a return date", "make the status a filter") are applied more reliably than a long list of changes in one message. Each one becomes its own version you can go back to. For a big change, such as a whole new department, the designer builds it step by step in the background.

Use a status for things that move

Requests, orders, jobs and bookings move through stages. One status field with coloured stages gives you a filter, a board you can drag cards on, notifications when a stage is reached, and charts. Use a simple choice for categories that do not move.

Link to what you already have

If a record belongs to a client, a lead, a project or a team member, ask the designer to link it. The App then shows the name from your workspace, respects who may see it, and can notify that client or lead.

Put repeated details in the App's Settings

A company address, a default rate or the email that receives orders belongs on the App's Settings page, not typed into every message and document. Write it once as {settings.name}; when it changes, the App's administrators change it in one place.

Notify sparingly, and test first

Notify on the moments that matter (a status reached, a date coming near) rather than on every change. Use Send a test to me before saving, keep the daily limit low for messages to clients and outside addresses, and check What was sent after the first days.

Design documents on the real paper size

Pick the paper first, then place the elements. Preview with a real record before publishing, and keep one table of lines per document: it continues on the next page by itself.

Always preview before publishing

Preview shows the App exactly as your team will see it. Publish when it is right; until then your team keeps using the published version, and the publish screen tells you what will change in the database.

Add fields instead of changing them

Once an App is published, a field holds data. Ask for a new field rather than changing the kind of an old one; removing a field hides it and keeps its data.

Grant access by role

Give most people See and Add / Edit, keep Delete for the people responsible for the data, and give Manage its Settings only to those who run the App.

Deliver rather than hand over, when you keep building

When you build an App for another company, deliver it: they decide who uses it and how it notifies, while you keep improving it and send versions. Hand it over only when they take it over for good.

Translate after the design settles

Translate the missing languages once the design is stable. Texts whose English did not change keep their translations when you edit the App later.