Designing a search experience teams could trust
Turning a request for binder automation into the collaboration problem hiding underneath it
Role: Sole designer
Type: Core workflow enhancement
Released: May 2024 (2 weeks from problem to final designs)
Collaborators: PM, engineering
Impact at a glance
Fundamentally changed a core platform workflow used across litigation teams
Improved collaboration and iteration in search building, a task previously done via hacky workarounds
Early feedback signals strong resonance across litigation teams — “hugely impactful” and “better than Christmas” on launch day
Overview
Search on Everlaw was powerful but siloed, forcing teams to rely on workarounds to collaborate at scale. I led the redesign of how litigation teams build, share, and rely on queries together — by solving the need behind the request, not the request itself.
PROBLEM
It started with a cry for “dynamic binders”
Search is one of Everlaw's most-used workflows, yet teams couldn't easily build and refine queries together.
To collaborate more seamlessly, teams asked for binders that would auto-add new results over time.
Both search and binder cards open a document set, but searches are used to filter documents, while binders are meant to organize finalized results.
At face value, a request for automation. Findings from interviews with legal experts told a different story:
Confusion around searches and binders
Both felt similar but were conceptually different. Users wanted the flexibility and permanence of binders with the power and dynamism of search.
No notion of a single, synced search
Sharing a search distributed a copy of it. Edit your version and collaborators kept the stale one.
Search was unforgiving
Every fix spawned a new search that cluttered the homepage, losing its history and collaborators.
Insights
Seen this way, the binder request made sense. Binders already worked the way search needed to: one shared, synced object that survived every change instead of fragmenting into copies. Pointing at binders was simply the safer, lighter fix.
However, the real problem was that search couldn't be shared or trusted — and the opportunity was the inverse: bring binders' shared, synced, forgiving behavior to search itself, without collapsing the two.
SOLUTION
The interface barely moved. The behavior changed completely.
These changes decimated friction in workflows that were previously solved with manual or external coordination—directly elevating the platform’s core utility.
Collaborate in real-time in a shared workspace
No more re-sharing fresh copies of a search. Toasts keep users updated on each others’ changes.
Iterate with ease with flexible editing and save options
Tweaking a typo in your search query no longer creates a new search card that clutters the homepage and requires re-sharing.
Trace changes and recover from mistakes via version history
Version history shows how a search evolved for easy reporting; restore or branch from any prior state.
STRATEGIC DECISIONS
Three trade-offs that respected mental models
Each call balanced collaboration against usability and real technical constraints — without breaking the mental models teams already had.
📒 1. Keep searches and binder objects distinct
Zooming out, users naturally think of binders as static sets and searches as dynamic filters. Merging the two would violate established mental models and further confusion on Everlaw.
Decision: Improve search collaboration without blurring that boundary.
Trade-off: Users benefit from improved coordination without disrupting familiar structures or core data models.
✏️ 2. A hybrid of live edits and manual saves (query changes)
Fully live edits risk confusing teammates.
Fully manual saves slow iteration and create version conflicts.
Decision: Use a hybrid model: live updates for small tweaks (e.g., filter tweaks) and explicit commit for larger query changes.
Trade-off: Enables real-time collaboration while maintaining predictable, recoverable workflows, keeping teams aligned without disruption.
👀 3. Decouple personal views from the shared search (layout/presentation)
Originally, we proposed to keep search result table views fully synced across collaborators so everyone sees the same layout in real time.
Constraint: Views include personal settings (e.g., column widths). Forcing full sync would introduce technical complexity, create noisy version history, and disrupt individual workflows.
Decision: Decouple views and add a search-level default instead: a shared starting point for collaborators with personal flexibility on top.
Trade-off: Collaborators might not always see identical views, but they gain control, stability, and clarity about what’s shared versus personal.
Users begin with the creator’s view, can make personal adjustments,
and reset to the default whenever needed.
RESULTS
Impact beyond metrics
Search is ubiquitous, so adoption and retention numbers don’t isolate this change well. We measured success through ecosystem-level signals instead. Across power users, reviewers, and litigation teams, feedback has been overwhelmingly positive:
The update was “hugely impactful”
It “opens a significant level of differentiation between Everlaw and its main competitor.”
Launch day felt “better than Christmas” 🥳 🎁
These reactions confirm that the redesign meaningfully elevated precision, ease of use, and trust in one of the platform’s most critical workflows, strengthening both day-to-day efficiency and Everlaw’s broader competitive position.
TAKEAWAYS
Great workflows emerge from respecting how people think, not from taking requests at face value. 🧠
Question the ask, find the need underneath, and design for the mental model that already exists. It’s the discipline behind every reframe I run now.