Ask for the Matter, Not the Path

Every internal tool I have built for this firm has had the same first bug, and it was never in the code.

The tool asks a question the user cannot answer.

Not because the user is unsophisticated — the people using these systems are lawyers and legal assistants who manage hundreds of deadlines without dropping one — but because the question is written in a language they have no reason to speak. It is written in the language of the toolkit the thing was assembled from.

Here is the canonical version. A tool that launches a working session puts up a field labeled:

Working directory

And underneath it, helpfully, a placeholder showing a path.

I have watched an intelligent person type the word downloads into that field, because they had a document in their Downloads folder and that seemed like the answer. It is a completely reasonable answer to the question as a normal person would understand it. It is also, to the software, meaningless — the program went looking for a folder named downloads relative to wherever the server happened to be running, found nothing, and produced an error about a directory.

The instinct at that point is to improve the error message. That instinct is wrong. The problem is not that the answer was bad. The problem is that the question was.

(Everything in this article uses invented examples. No client information, matter numbers, or real file paths appear anywhere in it.)

Nobody outside software knows what a “working directory” is

Start with an honest inventory of the words that leak out of developer tooling and into interfaces built by non-specialists:

• working directory
• root
• path
• instance
• environment
• config
• token
• endpoint

Every one of these is precise, every one of them is standard, and not one of them means anything to someone whose expertise is in Minnesota civil procedure. They are not hard words. They are words from a different profession, dropped into a tool used by this one.

The reason they leak is structural. When you build a tool, you build it in the vocabulary of the thing you built it with. The library you called wanted a working directory, so your form asks for a working directory. You have effectively passed your dependency’s API through to a human being.

A lawyer would recognize this immediately in another context. It is the same error as sending a client a letter that says “we will be seeking Rule 37 sanctions for your ex-husband’s failure to respond to our Rule 34 requests.” Every word is correct. The client has no idea what you are going to do.

The fix is not a better label. It is a different question.

Here is the reframe that solved it for us.

The tool did not actually need to ask where on the filesystem should this run. That was an implementation detail that had been promoted to a user-facing question. What the tool needed to know was:

What are you working on?

And the answer to that is something every person in a law office can produce instantly, because it is the organizing unit of the entire practice. A matter.

So the field changed. Instead of a text box expecting a path, the tool offers a chooser whose first and default tab lists every matter folder on disk — searchable by file number or by client name. Type three digits of a file number, or the first four letters of a client’s last name, and there it is. The tool figures out the path. The path was never the user’s problem.

That is the whole principle, and it generalizes:

Ask for the domain object the user already thinks in. Derive the machine detail yourself.

Your users think in matters, clients, deadlines, hearings, and documents. They do not think in paths, IDs, or endpoints. Any place your interface asks for the second kind of thing, there is a translation you failed to write.

Then make typing work anyway

You will not get every case with a picker, and some people prefer to type. So the text field stayed — but it stopped being a validator and became an interpreter.

The rule I settled on: accept anything that unambiguously names a real folder, and say out loud what you decided it meant.

In practice that means the field now accepts all of these:

None of that is clever. Case-insensitive matching, tilde expansion, stripping the decorations that copy-and-paste adds, and one lookup against the matter index. An hour of work, total.

The part that matters more than any of it is the last clause. Under the field, before anything runs, the tool displays what it resolved to — the readable path, and the matter number if it recognized one. If the user typed something wrong, they see it immediately, in a form they can evaluate, while it is still free to fix.

Compare the two failure modes:

• Validator: you type something, you hit go, you get an error about a directory. You try again. You give up and ask someone.
• Interpreter: you type downloads, and the tool says ✓ ~/Downloads before you commit. You either nod or you notice it is wrong.

Same input. Same code paths, nearly. Completely different experience of the tool.

Two things about the Mac worth teaching anyway

Interpretation covers most of it, but there is a floor of user knowledge worth raising, because it pays off everywhere — in this tool and in every open/save dialog anyone in the office will ever see.

1. Select a folder in Finder and press ⌘⌥C. That copies its full path to the clipboard, ready to paste. Most Mac users have never been told this exists.

2. Drag the folder onto the field. Finder hands over a file:// URL, which a well-built field will decode into a path. This is the most discoverable option and requires learning nothing.

3. In any Mac open/save dialog, press ⌘⇧G. That opens a “Go to Folder” box with autocomplete.

Fifteen minutes of training on those three shortcuts removes more friction than most interface work.

The one thing a web page cannot do

A caution for anyone building firm tools as browser-based apps, which is the sensible default in 2026.

A web page cannot open a folder chooser. There is no way around this. An <input type="file"> hands JavaScript a file, never a path, and the directory variants do not change that. If your internal tool runs in a browser tab, your users will be typing or pasting paths forever, and the interpreter above is not a nicety — it is the whole interface.

If you wrap the same app in a thin native shell — which is a few hundred lines and gets you a Dock icon besides — you can bridge from the page to a real system folder panel, and then people get the file chooser they have used since they were children. That is a genuine argument for the native wrapper that has nothing to do with how the app looks.

Whichever you choose, build the domain-object picker anyway. Even with a perfect native chooser available, searching 600 matter folders by file number beats clicking down four levels of a Dropbox tree every single time.

Why this is worth an afternoon

There is a temptation to treat this as polish — the real work is the automation, and the input field is trim.

I think that is exactly backwards, for a reason specific to small firms.

An internal tool with a hostile interface does not get used badly. It gets used by one person, the person who built it, who is the only one who knows what the fields mean. Everyone else quietly routes around it and goes back to doing the thing by hand. You then conclude that the workflow was not worth automating, when what actually happened is that you built a system with a vocabulary test at the front door.

The vocabulary test is the cheapest thing in the whole system to remove. You do not need better models, more integration, or a rewrite. You need to notice that you asked for a path when you meant a matter, and ask for the matter.

Sources

• Apple, macOS Finder keyboard shortcuts (⌘⌥C to copy a file or folder path; ⌘⇧G to open “Go to Folder”), verified in macOS.
• HTML Standard, file upload state (<input type="file">), which exposes selected files to script as File objects and does not expose filesystem paths — verified against the specification’s file upload state and FileList behavior.

This article describes general design practice for internal law firm tooling. All examples are invented. It contains no client information and is not legal advice.