How to brief a digital product studio without pretending you know the answer

A surprising number of briefs are written backwards. They open with a page count, a platform and forty features, and close with a short paragraph about the business.

I understand why. A feature list feels concrete, and it gives every agency the same thing to price. It also fixes the answer before anyone has understood the question, and it quietly turns the studio into a typist for decisions you made alone.

A useful brief is shorter than most people expect. Its job is to give the people doing the work enough context to ask better questions. One of my favourite briefs arrived as a four minute voice note, recorded in an auto rickshaw somewhere near Andheri, horns included. It never mentioned a feature. It told us exactly what was going wrong, and for whom. That was enough to start.

Start with the situation, not the solution

Write down what is happening today, and why it has become urgent now. “We need a new website” is an output. “Our sales team re-explains the whole business after every website enquiry” is a problem worth designing around.

If you are building	The situation often sounds like
A website	The business has moved on and the site still describes the old one. Good enquiries come through personal contacts, never the site. Visitors arrive but cannot tell what you sell.
A product or portal	A critical workflow runs on spreadsheets and email. Staff send customers information by hand. Support requests show people finish the task, but only after getting lost.

Then add the trigger: a funding round, a new market, a regulatory date, a festive season. Deadlines change what a sensible first release looks like.

Name the people, not “users”

“Users” hides the interesting part. A membership platform serves an applicant, a member, an administrator and a finance team, each finishing something different. You do not need personas with invented names and stock photographs. A few accurate sentences beat them:

New members need to understand whether they qualify, then apply and pay. Our team needs to verify each application before access is granted. Existing members need resources and a renewal that nobody has to chase.

That paragraph is already the outline of a product. It is close to where our work on IVCA’s member platform began, a project that cut renewals from three weeks to four days.

Show what exists today, including the awkward parts

A studio needs to know where important data lives, which integrations cannot change, where manual work is quietly carrying the process, what has been tried before and what still works well.

Send the real artefacts: screenshots, a two minute screen recording, the actual spreadsheet. At our first workshop for that membership platform, the team brought a spreadsheet that used eleven colours to track the state of a renewal, and only two people knew what all eleven meant. No requirements document could have told us as much in as little time.

Share constraints early, including the budget

Every project has constraints. Hiding them only delays the moment they reshape the design. State the fixed dates, how much of your team’s time the project can have, required platforms and licences, legacy systems that must stay, languages and accessibility needs, approval and security reviews, dependencies on a vendor or payment provider, and a budget range.

Budget is not a negotiating card. It tells the studio which route is proportionate. We approach a ₹4 lakh website very differently from a ₹40 lakh platform, even when both briefs use the word “portal”. If you genuinely do not know, give a range you would not be embarrassed by. When the scope is unclear, the honest next step is often a Discovery Sprint: three weeks, from ₹3.5 lakh (US$4,000 or AED 15,000), covering the first three phases of the Ampersand Method.

Describe success without inventing precision

You may not know the final metric yet. You can still say what should be different:

• a prospective client understands the offer without a sales call;
• members renew without staff sending reminders;
• an administrator publishes a listing without calling a developer;
• the platform onboards its first 100 vendors without a special process for each.

“Increase engagement” is not an outcome until everyone agrees what engagement means. Precise targets can come later, in our Map & Measure phase, once there is a baseline.

Separate requirements from ideas

If you adopt one habit from this article, make it this one. A requirement is something the product must support. An idea is one possible way to support it.

Requirement: members need to know when a fixed deposit is nearing maturity and be able to request renewal.

Idea: a red badge on the dashboard.

The idea may be excellent, but it should stay open to testing. When every idea becomes a requirement, design is reduced to arranging decisions already made. Label each line instead:

Label	What it means	Example
Must support	The product fails without it	Members can renew and pay online
Important question	Nobody knows yet, and the answer changes the design	Does finance approve refunds above a limit?
Current idea	A possible answer, open to testing	A WhatsApp reminder seven days before expiry
Later possibility	Worth keeping, not worth building yet	A native app for members

This distinction sits at the centre of how we run UI and UX design projects. In Sketch & Shape, prototypes put the ideas in front of real people, while the requirements stay fixed underneath them.

Be honest about content and access

Content

Web projects look ready until someone asks who will write and approve the words. List what exists: approved company and product copy, case study evidence, legal pages, photography, testimonials with permission, translations. Then list what does not. A content gap can be planned for. An invisible one cannot.

People

A project loses weeks when the people in workshops cannot answer the questions and the people who can never attend. Name the project owner, the final decision maker, the person who understands the current system, the people who will run the new one, any compliance reviewers, and whoever controls the domain, hosting and credentials. That last one has delayed more launches than any bug. We learned it in our hosting years, usually on a Sunday.

A worked example: one brief, rewritten

Here is a composite of several briefs we have received, details changed. The first version arrived as one paragraph:

We need a mobile app for our clinics. iOS and Android. Booking, payments, video consultations, chat, loyalty points, reports and an admin panel. Please send your best price.

Nothing in it is wrong. It simply gives a studio nothing to think with. Here is the same brief after one conversation:

Section	Before	After
Situation	“We need a mobile app”	Six physiotherapy clinics in and around Mumbai take bookings by phone. At peak hours the front desks miss about one call in five, and patients who miss a follow-up rarely rebook.
People	Not mentioned	Returning patients; new patients referred by doctors; front desks juggling six diaries; physiotherapists who need the day’s list.
What exists	Not mentioned	Clinic software under a licence that must stay; a WhatsApp number patients already message; a spreadsheet of treatment packages.
Success	Not mentioned	Fewer missed calls, more follow-ups kept, and front desks spending less of the day on the phone.
Requirements and ideas	Seven features, all mandatory	Must support: booking and rescheduling against the real diaries. Current ideas: video consultations, loyalty points. Later: native apps.
Constraints	“Best price”	Live before the seventh clinic opens in March; a budget of ₹10 to 15 lakh; the clinic software’s API allows reads but limited writes.

The first version invites seven quotes for seven features. The second invites a better question: could a fast web booking flow and WhatsApp reminders solve most of the problem before anyone builds a native app? That question leads to a phased plan that fits both the March date and the budget.

A one page brief template

Copy these headings. Each feeds a phase of how we work, which is why a good brief shortens the early weeks so noticeably.

Heading	What to write	Feeds
About you	Two or three sentences on the organisation	Listen & Learn
Why this, why now	The situation and the trigger	Listen & Learn
Who it serves	Each group, and what it needs to finish	Listen & Learn
What exists today	Systems, data, workarounds, and evidence of what hurts	Map & Measure
What should be different	Outcomes in plain words	Map & Measure
Constraints, budget and timing	Dates, platforms, compliance, team time, a range	Map & Measure
Requirements and ideas	Labelled: must support, question, idea, later	Sketch & Shape
Systems and integrations	What must connect, and what cannot change	Sketch & Shape
Content and assets	What exists, and what does not	Launch & Land
People and decisions	Owner, decision maker, experts, credentials	Every phase
What you want from the studio	A route, an estimate, a sprint or a second opinion	Every phase

A page or two is enough. Attach the evidence that makes it real.

Ask for a route, not only a price

A useful response tells you what the team believes the problem is, what remains uncertain, the proposed phases, who will actually do the work, what you must provide, which assumptions move cost or timing, how it will be tested and what happens after launch. Our page on product and UX design shows what that looks like in a Discovery Sprint. A low quote on a vague scope is not a saving. It is an argument scheduled for month three.

A checklist before you send it

• The problem fits in two sentences. (My co-founder Saurabh will not start without this.)
• Every group of people is named, with what each needs to finish.
• Real evidence is attached: screenshots, recordings, the spreadsheet.
• Constraints and a budget range are stated, not implied.
• Success is described as a change, not a feature.
• Requirements and ideas are labelled separately.
• Content gaps are listed honestly.
• A decision maker and the person holding the credentials are named.

The brief is where the conversation starts

A good studio will push back on parts of your brief. That is not a sign it ignored the document. It is often the first sign that the team is treating your project as a product decision rather than a production order.

The goal is not to arrive with every answer. It is to make the important questions visible while there is still time to change the answer. If you have a brief half written, send us the rough version. We reply within one working day, and we will respond to the problem before we respond to the formatting.