Scaling client-side UX from one firm to three hundred

Picture the person who actually decides whether a document collection tool works. It is not the audit manager who lives in the software eight hours a day. It is a company director standing in a car park, phone in one hand, who got an email saying his accountant needs four things by Friday. He logs in maybe twice a year. He has forgotten everything about the last time. He has about ninety seconds of patience before he gives up and replies to the email with “can you just tell me what you need.”

That person is the hardest user in the whole system, and the entire product lives or dies on whether he succeeds. When you’re serving one firm, you can paper over his confusion with a phone call. When you’re serving a few hundred, you can’t. The design has to carry the occasional user on its own, at scale, with nobody standing next to him.

The occasional user is the real constraint

Most software is designed for its power users, and reasonably so — they’re the ones present every day, filing feature requests. In document collection the incentives point the other way. The firm’s staff will learn whatever they have to; it’s their job. The Client User will not. They arrive rarely, under time pressure, often on a phone, with no memory of the interface and no appetite for learning one.

So the constraint that matters isn’t “what would delight a firm’s power user.” It’s “can a director who last logged in six months ago upload the right file, to the right item, in under two minutes, without asking anyone for help.” Every decision on the client side gets measured against that sentence. If a feature makes the occasional user hesitate, it’s the wrong feature no matter how much a power user would appreciate it.

What designing for that user forces

Once you accept the occasional user as the constraint, a surprising amount of the product stops being a matter of taste and becomes forced:

• Passwordless entry. Every password you ask an occasional user to create is a password they’ll forget and a reset that will fail before a deadline. Magic-link access means there’s nothing to remember and nothing to reset at 9pm. It’s the single largest lever on whether the portal gets used at all.
• A portal that states what’s needed. The client shouldn’t have to infer their to-do list. The Portal shows, per Engagement, what needs action, what’s awaiting the firm, and what’s done — and a plain “what’s still missing” summary read from stored per-item status, not derived from whichever files happen to be present.
• Self-explanatory asks. Each Request Item carries its own instructions and, where useful, a sample format. The occasional user can’t ask a clarifying question quickly, so the ask has to answer the question before it’s raised.
• Bulk upload for the dumpers. Plenty of clients won’t answer item by item; they’ll send everything at once. Drag-and-drop bulk upload lets them, and the matching sorts the pile back to the right items with the firm confirming.
• Pause instead of nagging. A client who genuinely can’t get to something this week can acknowledge and pause a reminder. The cadence quiets, the item stays open, and it returns on its own. You keep both the relationship and the record.
• English and Greek. A Cyprus firm’s team works in English; many of its clients are more comfortable in Greek. Browser-language detection and a bilingual portal mean the same Request Item is clear to whoever opens it.

None of these are flourishes. Each one removes a specific reason the occasional user would otherwise give up and fall back to email. We wrote about the portal-adoption problem in more depth in giving clients a portal they’ll actually use.

Why the two sides reinforce each other

Here’s the part that took us a while to see clearly. Designing for the occasional user doesn’t come at the firm’s expense. It’s the thing that makes the firm’s side work.

The firm wants clean Evidence and a defensible trail: files matched to the right item, versions retained, acceptance recorded with a name and a timestamp. All of that depends on the client uploading the right document to the right Request Item in the first place. If the client is confused, they upload to the wrong item, or they don’t upload at all and send an email instead — and now the firm is back to reconciling attachments by hand, with no trail worth the name.

So client-side simplicity is upstream of firm-side rigour. A portal the occasional user can navigate produces structured input the firm can rely on. A portal that confuses them produces the email chaos the whole product exists to replace. The two sides aren’t competing for attention; the harder one carries the easier one. Many of these patterns were the same lessons that surfaced across our first firms — the client-side friction always showed up before the firm-side value did.

Scaling is holding the line

Going from one firm to three hundred didn’t change the design. It changed how unforgiving the design had to be. At one firm, a rough edge on the client side is a support call. At three hundred, the same rough edge is a pattern — a steady trickle of clients bouncing off the same confusion, each one quietly reverting to email and eroding the record for their firm.

So scaling client-side UX isn’t about adding features as you grow. Mostly it’s about refusing to. Every addition is one more thing the occasional user might trip over, and the occasional user doesn’t get more capable as you add firms. The discipline is to keep the client’s path to “here’s what you need, here’s where it goes, done” as short as it was on day one, no matter how much structure accumulates behind it for the firm. You can see how that structure fits together in the product.

The firm is the customer. The client’s client is who you’re really designing for.