Off-Limits for One Search: Designing a Restriction Nobody Can Miss

Some restrictions apply to just one search, and Thrive had no way to handle them. Teams worked around it by hand, which led to errors, and getting a restriction wrong can cost a client relationship. Off limits was already the most complex feature in Thrive, in the legacy app and the updated one, so this had to be designed with care.

This was one of the first large projects after the team moved past migration parity, the point where the updated Thrive started doing things the old one never could. I designed how the restriction is set up, where it shows up, and what recruiters can still do, working with the PM, building it out in a code prototype, and carrying it through review and handoff to dev and QA.

Executive search firms mark companies and people off limits across their whole Thrive account for many reasons: a contract with a client, a placed candidate, someone who asked not to be contacted for a year. That small red flag means a person could be off limits, and the recruiter should look into it before reaching out.

A project-specific restriction is different. It applies to one search and no other, for two common reasons. A VC or PE firm recruiting for one of its portfolio companies may want some or all of its other investments left alone for that search. Or a client simply doesn't want candidates from a particular company. Search firms take on hundreds of clients, so marking those companies off limits everywhere would be wrong, and the old workaround, entering the investor as the hiring company, broke other restrictions that depended on the real hiring company.

The hardest part wasn't any single screen. A restriction like this has to say the right thing in every place a recruiter meets it: inside the project and outside it, for the team on the search and for everyone else, and for confidential projects that can't be named. I mapped each context to one signal and one action before settling any of the screens.

On a project board, plenty of people already carry the small red flag, and that flag asks the recruiter to check whether it applies. A project-specific restriction asks for something else entirely: the person has to come off the search now. Clients can also change their minds mid-search, deciding after fifteen weeks that nobody from a company should move forward, and the team then has to reject and process every one of those candidates and follow up with anyone they've already spoken to.

So restricted people get a red strip across their card and a bold banner across their side panel, while the regular flag stays small. Regular restriction types all share one light treatment, and logic orders them automatically and surfaces the most relevant one in each place, so priority comes from order and placement rather than a growing set of colors. I argued the banner was a lot, and worth it if it keeps a recruiter from the kind of mistake that loses a contract. We considered making it sticky; I argued against it, because on a 13-inch laptop it would eat too much of the screen.

The warning follows the person outside the project. If a recruiter adds someone from a restricted company to that search from the people list, the add-to-project dialog shows the project-specific banner the moment they select the project it applies to. Clear that project or pick a different one, and the banner goes away, because the restriction only matters for that search. The dialog shows one banner in place of its usual one, rather than stacking two.

Blocking the add was the obvious option, and the wrong one. Teams sometimes add a restricted person on purpose so they can reject them with a note and keep a record. If the client later changes course and opens the search back up, those notes show exactly who was set aside and why, and the team can move them out of rejected and back into the process. There are too many edge cases to hard-code a block, so the design gives the right information at the right moment and leaves the call to the recruiter.

"Project-specific off limits" was our shorthand, not something a recruiter should have to decode. Inside the project, the message says "restricted for this project." Everywhere else it names the project and the hiring company, "not eligible for Chief Financial Officer, Cedarbrook Health Network," unless the project is confidential. Every message also says what is still allowed: the person can be recruited for any other search.

A project can name its investor: the firm making the hiring decisions, separate from the hiring company where the placement happens. That fixed the old workaround at its source. On the project's Off Limits tab, project-specific restrictions get their own section, apart from contractual ones. In edit mode, a recruiter can include all of the investor's companies or pick specific ones, add any other company the client wants to avoid, and leave a note. Changing the hiring company clears the investor, so stale data can't linger.

I built the flows in a code prototype on a copy of the real app, so the PM, a group of client recruiters, dev, and QA could click through real states instead of static screens. We worked through the edge cases before handoff: a company removed mid-search, investors with more than a hundred portfolio companies, and what happens to the record either way. Project-specific restrictions are also included in data access request exports, and the release included tracking for project-specific actions.

Thrive Apply, handed off in August 2026, was where we started handing off with code alongside Figma. Off-Limits, handed off after it, went further: it was the first project I handed off as a full code prototype, with no Figma file as the source for the UI.

• Questions before screens. Before building, I had AI read the brief and list what it left open, then the PM and I answered each one. That is where we settled checking restrictions live instead of precomputing them for investors with a hundred or more companies.
• Options, not one answer. I worked through several directions in the prototype and kept iterating the one that held up across every place the restriction appears.
• Test data at real scale. I had the mock data sized like a real investor portfolio, so the screens were tested against long lists, not three tidy rows.
• Clear about what the prototype is. The acceptance criteria and the prototype were the source of truth. Notes AI generated in the code were only a helper for developers, and when one disagreed with a ticket, the ticket won. I also told reviewers which parts were prototype artifacts, like invented data and footers that didn't stick, so nobody read them as design decisions.

• Off-limits flags, spring 2024. The first red flags on avatars and cards, so recruiters could spot a possible restriction at a glance.
• Reliability and clarity, January to June 2026. Restrictions consolidated by company, every card naming its restriction type, and messages for moments that used to change restrictions silently. Shipped June 2026.
• VC and PE updates, April to July 2026. Off-limits updates for VC and PE clients and their portfolio companies, now in production.

It shipped in October 2026, shortly before I left, so I don't have post-launch numbers. Here is what changed, where the evidence is thin, and what I'd measure.

• A risk teams carried by hand now lives in the product. Missing a restriction like this had cost clients before. Now it shows up everywhere someone could act on it, and the person stays eligible for every other search.
• Compliance came with it. Project-specific restrictions are included in data access request exports.
• Tracking shipped with the release. Project-specific actions are tracked from day one, so adoption can be measured instead of guessed.
• The earlier release held up, on thin evidence. After Reliability and Clarity shipped in June 2026, a product analytics read showed no rage clicks or dead clicks on the off-limits screens. That is the absence of a bad signal, from analytics only a few months old, not proof the screens are easier to use.

We tried handing this off as one or two very large tickets. It was hard on QA and a little harder on dev too, because I had to break the work into smaller pieces anyway, and nothing could be tested until every pull request had merged into that one ticket and reached the dev environment. Going back closer to our original story breakdown in Jira worked better: each piece could be built, tested, and fixed as problems came up.

It also showed me when a prototype alone isn't enough. This restriction isn't one self-contained feature. It shows up across many surfaces, with conditions that change what appears where: turn one setting on and something shows here, turn another on and something else disappears. Work like that needs Figma screens alongside the prototype, so reviewers, dev, and QA can see every state side by side. Not every project does. Next time I'd decide that at the start, and put the context map in front of reviewers from the first round.