Requirements for a Sharing Service People Actually Adopt

"Add a classification dropdown." "Manager approval for anything over ten megabytes." "Can we keep it on the VPN?" Forty minutes into the requirements review, and nobody has yet said the word "user". Most internal file sharing projects begin with a requirements document. Most of those documents are written facing the wrong direction: toward the security team, the audit committee, and the procurement checklist. The result is a service that satisfies everyone except the people expected to use it. They take one look, find it harder than attaching a file to an email, and go right back to attaching files. The service is then "live" in the sense that a treadmill in a garage is exercise equipment.

This article writes the requirements facing the user first. It distills the analysis from why users default to attachments into two lists you can copy into a project charter. One is an adoption bar the service must clear before anyone will switch to it voluntarily. The other is a security floor that must hold underneath, invisibly, so the easy path is also the defensible one. This article is part of our Person-to-Person Sharing series, and it is the article to bring to the forty-first minute of that meeting.

By the end you will have the full checklist and an honest section on requirements that look important and quietly kill adoption. You will have a set of acceptance tests, run with a stopwatch and a real user. They tell you whether a candidate service passes before you commit to it. The stopwatch is not a figure of speech. Find one.

Two Lists, Both Non-Negotiable

The core discipline is refusing to trade the two lists against each other. The adoption bar comes from users' revealed preferences: everything the attachment habit does well, the replacement must match. The security floor comes from your obligations. Everything the habit does badly — no authentication, no audit trail, no control over where copies land — the replacement must fix. A service that clears the bar but lacks the floor is a liability with good usability. A service with a solid floor that misses the bar is shelfware, and the organization's real sharing system remains email. Both outcomes waste the budget; only one of them shows up honestly in a status report.

Watch for the committee drift that afflicts these projects: with every review meeting, the floor grows a new requirement and the bar loses one. Nobody in the room represents "the user in another department with a deadline," so their requirements are the ones traded away. Appoint someone to be that voice on purpose — ideally someone who recently hit an attachment size bounce and still remembers the feeling. The feeling fades in about a week, so appoint them quickly.

The Adoption Bar, Part One: The Sender's Seat

Works in the browser, nothing to install. The sender may be on a locked-down corporate laptop, a shared workstation, or a personal phone. The moment the instructions include "first, install…", you have excluded contractors, kiosk users, and everyone without admin rights. You have also added a deployment project to what should have been a URL. A web portal over HTTPS meets people where they already are. The mechanics of how a browser moves a file are covered in how web upload works. Those mechanics require nothing from the user but a page and a button.

Signed in on day one, with the account they already have. Adoption dies quietly at the provisioning step. If using the service requires requesting an account, the moment of need will be served by an attachment instead. That moment is when all sharing decisions are made. In that case, the person will never come back to try again. Back the service with your existing directory so that every employee's normal username and password already works. This is one of those rare requirements that serves both lists at once. It removes a user-facing step. It also means joiners and leavers are handled by processes you already run, including the offboarding that closes the account. Both lists get a tick and nobody had to argue. Savor it.

Three clicks or fewer from file to link. Treat this as a real, testable number. Measure from "I have a file and a recipient in mind" to "a share link is in my clipboard": choose file, confirm, copy. Sign-in does not count against the budget when the browser session persists or single sign-on carries it, but every options screen does. Defaults do the heavy lifting here — expiry, permissions, and notifications should be pre-chosen sensibly so the routine share asks the sender nothing at all. Power options can exist; they must never stand between a normal user and the link. Every options screen is a small exam the sender did not study for.

The handoff is a link that pastes anywhere. The output of the service must drop into the message the sender was already writing — email, chat, ticket comment. It must go exactly where the attachment would have gone. Sharing lives inside conversations; a service that demands the conversation move to it has misunderstood the job.

The Adoption Bar, Part Two: The Recipient's Seat

Senders judge a sharing service by their recipients' experience, because a stranded recipient becomes the sender's problem within the hour. Requirements for the far end are therefore adoption requirements, even though your users never see them directly.

Outside recipients need no account and no software. The person-to-person case lives or dies on this. The outside lawyer, the auditor, the freelance designer — they will not register, they will not install, and your users know it. A private link that downloads in any browser is the whole requirement. (When outsiders must send files to you at scale — customers submitting documents, say — that is a related but distinct design problem. It is covered in our customer-facing file exchange series.)

The download page earns trust in two seconds. Recipients have been trained by years of phishing warnings to distrust unexpected links. A bare address at an unfamiliar domain, an unbranded page, a clutter of ads — any of these and the recipient hesitates. They email back "is this legit?", and the sender quietly concludes the old way was less embarrassing. The download page should carry your organization's name, state plainly who shared what, and offer one obvious button. Served from a domain recipients can associate with you, over HTTPS with a valid certificate, it reassures instead of alarming. Two seconds is not long, and the phishing training bought you none of them.

Works on a phone. A substantial share of downloads happen wherever the recipient happens to be standing. Sending from a phone matters less, but receiving must just work. That means no plugins, no layout that hides the button, no file so mangled by the journey that a tablet cannot open it.

Big-File Capable: Relieving the One Visible Pain

The attachment habit's single user-visible failure is the size bounce, so file capacity is your recruiting sergeant. The first time the service swallows a file that email refused, you have converted someone. Set the ceiling far above the mail system's — think in gigabytes, not tens of megabytes — so users stop doing arithmetic before sharing. Our guide to attachment size limits explains why the effective email ceiling is even lower than the configured number. Make sure your service's honest ceiling is dramatically, unmistakably higher. The first time I watched a portal swallow a file that mail had bounced twice, the sender asked for the address. She wanted to write it on a sticky note. That is what conversion looks like.

Large uploads bring their own experience requirements. One is a visible progress indicator (an upload that looks frozen gets canceled and reported as broken). Another is tolerance of a flaky connection. There must be a clear message when a file genuinely exceeds the limit — stated upfront, not discovered after twenty minutes of uploading. The engineering behind moving big files through a browser, including where it gets difficult, is covered in large files over HTTP. For requirements purposes, the summary is: pick a service whose upload experience was designed for the file sizes you are promising. A progress bar that stops moving is broken, whatever the server thinks.

The Security Floor: Invisible, and Solid

Everything above is what users will judge. The floor is what your auditors, your lawyers, and your future self will judge — and the design goal is that users never notice any of it.

• Encrypted in transit, always. Every upload and download travels over HTTPS — TLS, the same encryption that protects web banking — with no plain-HTTP fallback. How that protection actually works is explained in how TLS protects transfers.
• Every sender is an authenticated individual. Shares must be attributable to a person, not to a shared login or an anonymous form. Directory-backed authentication gives you this for free; the options and tradeoffs are surveyed in authentication methods compared. As a concrete example, Sysax Multi Server authenticates each account individually and can use Windows/Active Directory accounts. That lets the sharing service inherit the identity lifecycle you already manage.
• Every action leaves a record. Upload, share creation, each download — logged with who, what, when, and from where. This single property converts sharing from an unanswerable mystery into a queryable system; what to log defines the fields that matter. Multi Server, for instance, logs every user action to both a log file and a database. That is the kind of record that survives an auditor's follow-up questions.
• Files live on infrastructure you control. When the service runs on your own server, shared files sit where your retention, backup, and legal-hold processes already operate. They are not scattered across consumer services under terms you never reviewed. This is the requirement that quietly decides the build-or-buy shortlist.
• Shares are time-bounded and revocable. A share should have an ending by default. An administrator (or the sender) should be able to kill a specific link in seconds when it escapes. Expiry defaults, revocation, and the design details behind them get their own article: share links, expiry, and access control done right.
• Cleanup is automatic. Lapsed shares must not accumulate into an ungoverned archive. Whether the platform sweeps them itself or a scheduled job does, "the share area empties itself" is a floor requirement, not a nice-to-have.

Nothing on the floor adds a step for the sender. That is the test of a well-chosen floor requirement: it constrains the service, not the user.

The Copyable Checklist

Here is the full requirements list in a form you can paste into a charter, an evaluation scorecard, or a request to vendors. Judge every adoption item from the user's chair, with a stopwatch; judge every floor item with evidence, not vendor adjectives.

ADOPTION BAR - every item must pass, judged from the user's chair
[ ] Works in any modern web browser; nothing to install for sender or recipient
[ ] Every employee can sign in on day one with the account they already have
[ ] File to link-in-clipboard in three clicks or fewer, sensible defaults chosen
[ ] The share travels as a link that pastes into a normal email or chat message
[ ] Outside recipients need no account and no software to download
[ ] Download page is branded, plain, and trustworthy at a glance
[ ] Handles files vastly beyond the email limit; ceiling stated upfront
[ ] Upload shows progress and fails loudly, never silently
[ ] Works acceptably from a phone, especially for receiving
[ ] No visible quotas, counters, or per-use costs for routine sharing
[ ] A first-time user succeeds unaided in under two minutes

SECURITY FLOOR - every item must pass, invisible to the user
[ ] All transfers encrypted in transit over HTTPS; no plaintext fallback
[ ] Every sender authenticated as an individual; no shared or anonymous sending
[ ] Accounts backed by the existing directory; joiners/leavers handled automatically
[ ] Every upload, share, and download logged: who, what, when, from where
[ ] Shared files stored on infrastructure the organization controls
[ ] Shares time-bounded by default; any link revocable in seconds
[ ] Lapsed shares cleaned up automatically; the share area is not an archive
[ ] An administrator can answer: who shared what, with whom, and when

If a candidate service — bought, built, or assembled — fails an adoption item, expect users to route around it. If it fails a floor item, expect to regret it during your first incident or audit. The point of writing both lists down early is that later, under schedule pressure, someone will propose cutting exactly one item from exactly one list. You will want the charter to answer for you. The charter does not get tired in week eleven. You will.

Requirements That Look Important and Are Not

Some requirements appear in every first draft because they sound rigorous, and each one measurably suppresses adoption. I have put at least three of the rows below into a first draft myself, with a straight face. This is the section to share with your security team — not to argue for weaker security. The point is to relocate it from gates (which users feel) to defaults, logging, and retention (which they do not).

Bluewater Bank's first charter had two of the rows below in it: manager approval for any external share, and a password on every link. The pilot ran for ten people in one department for a month. At the end of it the portal log showed six approved shares. The mail filter showed forty-one attachments from the same ten people. Several of those messages had the password for a portal link pasted into the same message as the link. Nobody had broken a rule; the rules had made the portal slower than the thing it was replacing. The team dropped the approval step, made the password optional and recommended, kept the logging, and re-ran the month. The two numbers traded places.

Acceptance Tests: Prove It Before You Commit

Requirements on paper are cheap; candidates should pass live tests. Four are enough, and none takes an hour:

1. The deadline test. Hand a busy, non-technical volunteer a real file and a real recipient, say "share this," and watch silently with a stopwatch. No coaching. Under two minutes to a sent link, unaided, is a pass. Where they hesitate is your friction map. Fix those spots before rollout, because the article on rolling out the sharing service assumes a service that already passes.
2. The recipient test. Send a share to a personal address and open it on a phone, off the corporate network. Count taps to a usable file, and honestly assess: would a stranger trust this page?
3. The big-file test. Share a file several gigabytes in size over ordinary wireless. Watch the progress behavior, interrupt the connection once, and read the error handling like a recipient would.
4. The audit test. The morning after the other three, ask the administrator to produce — from logs alone — who shared what with whom, and when each download happened. Include timestamps and source addresses. If the answer takes more than a few minutes or arrives with gaps, the floor has a hole in it.

These tests also make excellent procurement questions in reverse. Ask a vendor to perform them in front of you, on their standard edition, and much marketing evaporates on the spot.

From Requirements to Design

Hold two lists honestly. One is an adoption bar set by the attachment habit — browser-based, nothing to install, day-one sign-in, three clicks, link-shaped handoff, stranger-proof downloads, big files. The other is a security floor set by your obligations — HTTPS, individual authentication, complete logging, controlled storage, expiry, revocation, cleanup. Refuse trades between them, delete the gate-shaped requirements that masquerade as rigor, and verify the survivors with a stopwatch and a real user. The same argument, made from the training side, is in making the secure path the easy path.

The next step is turning the checklist into an architecture. That means where the portal runs, where shared files live, how insiders and outsiders authenticate, and how the service coexists with your managed transfer estate. That is the subject of designing the internal sharing service. Whether you assemble it on a transfer server you run or evaluate a commercial service against this checklist, the broader make-or-buy reasoning lives in our build vs buy for transfer infrastructure series. And if you want the requirements story one level up — rules for the whole organization rather than one service — there is another article. The approved and forbidden transfer methods article shows where a sharing service slots into policy.

Frequently Asked Questions