Run Your Case Management Software on a Phone, One-Handed, Before You Approve It

The test: one phone, one hand, average signal

Before you sign off on any new system — intake form, client portal, case status tool, internal dashboard — do this. Pick up a normal phone. Not your firm-issued device on office wifi. A regular phone on a regular connection. Hold it in one hand, the way someone actually holds a phone while walking out of a courthouse or sitting in a car.

Now run the entire workflow start to finish.

You are looking for four specific failures:

• Does it launch without maintenance? If you have to clear a cache, re-authenticate, update something, or ask IT a question before the thing opens, it has already failed. Nobody does maintenance to answer a lead.
• Are the buttons unclear? On a 6-inch screen, "Submit" and "Save" and "Continue" all look the same. If you hesitate for even a beat about which one advances the case, your staff will hesitate too — every time, forever.
• Is feedback delayed? Tap a button. Count. If nothing visibly changes within a second, the user assumes it didn't work and taps again. Now you have duplicate records, duplicate intake entries, duplicate everything.
• Is there unnecessary typing? Every free-text field on a phone is a place where the workflow stops. Dates, phone numbers, case types, referral sources — these should be taps, not typing.

Fifteen minutes with a phone will tell you more about whether a system gets adopted than an hour of demo screenshots on a conference room monitor.

Why desktop reviews lie to you

The people approving software at a law firm — partners, the operations lead, the marketing director — almost always review it on a desktop. Big screen, keyboard, mouse, fast connection, two hands free, sitting down, no interruptions. In that environment, almost everything looks fine.

The people who actually use the software are in a completely different posture. An intake coordinator fielding a call. An attorney checking a status between hearings. A paralegal confirming a document while standing. These are one-handed, interrupted, impatient sessions.

Mobile friction is invisible to the people reviewing the system on a desktop. That's the whole problem. The approval happens in the easiest possible environment and the usage happens in the hardest one, and nobody ever sees the gap until adoption quietly fails six months later and someone says "we never really used that."

The approval happens in the easiest possible environment and the usage happens in the hardest one. Nobody sees the gap until adoption quietly fails.

The adoption window has collapsed

Here's why this matters more now than it did five years ago. The JPMorganChase Institute found that businesses founded in 2025 reached a 10% paid-AI adoption rate within six months — versus more than six years for the 2019 cohort.

Read that again. Six months versus six years. The same adoption milestone, compressed by more than an order of magnitude.

That's not a story about AI specifically. It's a story about how fast new businesses now absorb new tooling as a default. Newer firms aren't deliberating for years about whether to adopt a system. They're adopting, testing, and either keeping or discarding inside of two quarters.

The strategic implication for an established firm is uncomfortable but simple: your competitive advantage is no longer being first to a tool. Everyone gets to the tool now. Your advantage is whether the tool actually gets used in your firm, under real conditions, by people who have other things to do. Adoption is the moat, not acquisition.

And adoption dies on a phone screen, in the first thirty seconds, when a button is ambiguous or a form demands typing that nobody wants to do.

Write the workflow before you look at screens

The phone test catches bad implementations. But the more expensive mistake happens earlier — when a firm starts a software conversation by looking at interfaces instead of defining what the system is supposed to do.

Before anyone shows you a screen, write down five things:

1. The current steps

Not the idealized version. The actual version, including the sticky note, the shared inbox, the "and then Maria checks it" step that exists nowhere in any documentation.

2. The owners

Who is responsible for each step. If two people are responsible, nobody is. If a step has no name attached to it, that step is where things rot.

3. The data

What information needs to exist at each stage, where it comes from, and what format it's in. Most software projects fail here — the workflow assumes clean data that the firm doesn't actually have.

4. The exceptions

The cases that don't fit the happy path. In a law firm, exceptions aren't rare edge cases — they're a meaningful share of volume. A system that only handles the clean 70% creates a shadow process for the other 30%, and the shadow process becomes the real process.

5. The desired outcome

What is measurably different when this works. Faster intake response time. Fewer dropped follow-ups. Fewer status calls from clients. If you can't name the metric, you can't tell whether the build succeeded.

Write those five things first. Then look at screens. The order matters, because once you're looking at an interface, the conversation becomes about the interface — and you'll end up optimizing the appearance of a workflow you never defined.

What this means for how you buy

Most law firm software decisions are made backwards: a vendor demos a polished desktop interface, the firm imagines their process fitting into it, and six months later the firm has reshaped its operations around someone else's assumptions about how a law firm works.

The alternative is to define the workflow first and build to it. That's the case for custom software — not because custom is inherently better, but because when you've already written the steps, owners, data, exceptions, and outcome, you have a specification. And a specification is the thing that makes a build predictable instead of a guessing exercise.

It also makes the phone test meaningful. If you know the five steps the workflow is supposed to take, you can time them on a phone and find out exactly where the system adds friction instead of removing it.

Your next step

Pick the one system your firm uses most — intake, case status, document requests, whatever gets touched daily. Open it on a normal phone, one-handed, and run a complete workflow end to end. Write down every moment you hesitated, every button you weren't sure about, every field you had to type into, and every tap where nothing happened fast enough.

That list is your fix list. It's also your buying criteria for the next system.

If the list is long enough that patching it isn't realistic, that's the signal to define the workflow properly and build to it. See how Bosseo approaches custom software.