Interfaces people can use on the first afternoon

What it is

Interface and product design is the work of deciding what a piece of software does, in what order, and what each screen has to say, so a person can finish the task in front of them without being taught first.

It starts before the screens. The first thing drawn is a loop: how somebody arrives, what they finish on the first afternoon, what brings them back. Screens come out of that loop rather than out of a feature list, and there are fewer of them than the list implied.

Handover is that flow, the screens that carry it, every state they can be in, the forms field by field, and a design system small enough to hold in one head. Where the build is here too, the same person writes the front end.

Who it is for

Founders with a build under way and no designer on it, which is the common one: the developers are shipping, the screens are accumulating, and nobody owns the question of whether the thing makes sense. Operations teams who have outgrown a spreadsheet and are commissioning an internal tool. Development shops that build well and want a design pair of hands.

Then the businesses whose interface is the whole transaction: hotels and clinics taking bookings, service companies whose enquiry form is the product, small shops where the checkout is where the money is taken or lost. That is often one flow rather than a whole application, and a studio day is the right size.

What it costs

Two prices, published so you can rank this studio against others before you write. There is no hourly rate here or anywhere on the site, because it makes working quickly a penalty.

USD is the anchor on every quote and invoice. The figure in parentheses is the same price in dirhams at the pegged rate of 3.6725 to the dollar, one local equivalent rather than a currency list, correct as of 5 September 2026. Prices exclude any VAT, sales tax or withholding your own country applies to imported services.

There is no third number for interface work sold as a fixed project, and inventing one would be worse than leaving the gap visible. That work is quoted with the build it belongs to, from the rungs on the services page.

Form design, which is most of the job

Most software is a form wearing a product for a coat, and most abandoned tasks are abandoned inside one. The rules here are unglamorous, applied every time, and the three forms on this site were built to them.

• One column, labels above the fields, and no placeholder standing in for a label: it goes the moment somebody types.
• The fewest fields that let the work happen, and a reason that can be said out loud for each survivor.
• Validate when a field is left, not on every keystroke, and word the error as what to do next.
• Never clear what somebody typed. A form that empties itself on an error is abandoned on the second attempt.
• Correct autocomplete and inputmode attributes, so a phone keyboard shows digits and the browser fills an address.
• Every control reachable from the keyboard, a visible focus ring, and the whole thing usable at 200 percent zoom.

Booking and checkout flows

A booking flow is a sequence of promises, and the order matters more than the styling. Show availability before asking who somebody is: a person made to register only to find out you are full does not come back. Hold the slot while they finish, and say for how long. Put the total, including whatever arrives at the end, on screen before the payment step.

Guest checkout stays available, because forcing an account in order to buy is a tax on the buyer for the seller's convenience. The confirmation has to survive being read on a phone three weeks later, so the date, the amount and the way to cancel are in the text, not only in a picture. Where the flow crosses a payment provider or a property system, it is designed against what that system does, not its marketing page.

Working with your developers

The handover is written for the person who has to build it. Annotated screens, a token set for type, colour and spacing, every state enumerated: empty, loading, partial, error, permission denied, and the case where a name is forty characters long. A component list that separates the new from what exists, so the estimate is an estimate rather than a guess.

Where it is useful that handover is a working front end in HTML and CSS instead of a picture of one. This studio builds as well as draws, so no translation step is left in which the spacing quietly changes, and I will read a pull request and say where the build drifted.

How it runs

1. You write what the software is for, on the brief card below: who uses it, and what they need to finish.
2. I reply in writing, usually inside a day, with what I think the work is and whether it wants the subscription or a day.
3. One call, thirty minutes, for the parts that do not survive being typed, then a quote or a start date.
4. The loop before the screens. The flow is drawn and agreed first, the assumptions written down so they can be proved wrong later.
5. Requests, one at a time, back in 48 to 72 hours. You review as the work is drawn rather than at a reveal, and revisions belong to the request.
6. Handover. Files, tokens, states, the component list, the rights, and the decisions in writing, so the next person can carry it without ringing me.

What it has proved

Not yet what a page like this usually claims. There is no client interface engagement here with a measured before-and-after, so there is no conversion figure and no chart. The Search Console exports on the other service pages measure sites, not interfaces, and borrowing them here would be dishonest. What stands in for them is work you can open.

• Lantern. A CRM built for six beds, not six hundred: a small hospitality operation's day on one screen, useful on the first afternoon without training. At lantern-beige.vercel.app/app.
• The three forms on this site. The statement form, the step form and the brief card, all shipped, all testable before you pay anything.

Lantern is a demonstration rather than a measured engagement, and its claims are product claims with no measured series behind them, as this studio's research note 07 records in section 2.5. It proves the thing exists and works, not that it moved a number in a business.

Who it is not for

Questions people ask before they write

Sources

1. Lantern, a working demonstration CRM built by this studio, at lantern-beige.vercel.app/app, read on 5 September 2026.
2. Claim marking for Lantern as a product claim with no measured series, ShepherdUX research note 07, section 2.5.
3. Pricing benchmarks and buyer behaviour, ShepherdUX research note 18, September 2026, drawing on published agency and freelance rate surveys.
4. United Arab Emirates dirham pegged at 3.6725 to the United States dollar, Central Bank of the UAE, rate as of 5 September 2026.