How to write an app prompt

The four things that cannot be missing

1. Who uses it. One concrete person, not "users". It changes everything whether the person opening it is the customer, the employee or the owner.
2. What they do there. One verb at a time: order, book, log, approve, look up.
3. What gets stored. That is what later becomes the list, the filter, the search and the report. It is the part people forget most and the most expensive to fix.
4. Who sees what. One sentence is enough, and it heads off the costliest defect: one customer seeing another's order.

A short template that works

An app so that [who] can [what they do]. Each [record] stores [fields]. [Who] sees only their own; [who] sees everything. When [something happens], the app [notifies someone / changes the state].

Four lines cover more than a page of loose wishes. The rest resolves better by looking at the finished screen.

What to leave out of the first request

• technology, unless you have a specific reason;
• colours and fonts, unless the brand already exists. Visuals are the easy part to change later;
• version 3 features. Advanced reports, metric dashboards and integrations come once version 1 has people using it;
• login, if there is nobody to log in yet.

The second prompt matters more than the first

The first request generates the app. The ones after it are what make it right, and they have a different shape: instead of describing everything, they point at one spot.

A good fix request has three parts:

• where: the screen or the button;
• what happens today;
• what should happen.

"On the orders list, the date filter changes nothing when I pick a month; it should show only that month's orders." That request changes very little. "Improve the orders screen" invites a rewrite of what was already fine.

When the problem is layout, a screenshot beats a paragraph.

Mistakes that show up every week

• asking for everything at once. The app is born large, wrong in several places, and it becomes hard to tell which fix broke what;
• describing the solution instead of the problem. "Add a hidden field that stores the status" takes away the chance of a better answer;
• changing subject halfway. One request, one subject;
• not stating the permission rule, and finding out in front of a client.

The summary

• who uses it, what they do, what gets stored, who sees what;
• four lines beat a page;
• leave technology and visuals for later;
• fixes carry where, what happens and what should happen;
• one request, one subject, and a screenshot when it is layout.