Showing it a file

Showing is how a non-developer specifies something. Attach a file to a message and the builder can use it.

What is worth attaching#

A screenshot of the report somebody wants. The fastest way to specify a screen is a picture of one. A photograph of a whiteboard works too.

The spreadsheet the data comes from. It gives the real column names, the real value ranges, and a sense of how much of it there is — all of which change what gets built.

A PDF of the form being replaced. Every field, in the right order, with the right wording, without you retyping any of it.

Your brand guidelines. Useful when setting up a design system rather than building a screen — see Your own design systems.

How it is used#

Images and PDFs are looked at — the builder can see them and work from what is in them.

Spreadsheets, CSV files and other data files are handed over as files it can open and read. That is more useful than it sounds: it can read the whole thing, work out the shape of it, and seed the application with real data.

Where files go#

An attachment is stored with the conversation and copied into the application's own workspace, so the builder can open it during that build and later ones.

Attachments are not the same as published files, which are the documents your application hands to its users. An attachment explains what to build; a published file is part of what the business does.

Limits#

There is a cap on how many files one message takes — you are told if you exceed it, and sending them across two messages is fine.

Very large spreadsheets are better summarised: a few hundred representative rows tell the builder everything that fifty thousand would, and cost less.