Outlook add-in

Context

Email is where a lot of legal case work happens. When firms receive an email, they file it and its attachments to a case in the product for safe keeping. The legacy Outlook add-in was supposed to handle this, but it lacked core workflows, was inconsistently buggy, and expensive and risky to change, which crippled adoption. This wasn't a secret either. We had received tons of negative feedback about it over the years.

The Outlook integration was the product's most-voted feature request and its single largest support category, roughly 133 votes in our client-facing ideas portal at the time and around 71 tickets a month, with feedback as blunt as "garbage." It's also table stakes, as the main competitors all ship deep Outlook plugins. About 30% of firm emails were going untagged. And this was all before we revamped our ideas portal - it's the largest feedback area, and its top request is the most-voted idea of any kind.

Votes per Outlook add-in request in the product's ideas portal, Oct 2025 to Sep 2026

Show the data

Request	Votes
Default search type	147
Tag whole thread	28
Attachment types	13
Bill time	9

Once our discovery process started, all these ideas and feedback were turned into a ranked problem set. Every finding went into the team's atomic research repository as an observation, and the observations rolled up into insights with a confidence level, so the redesign started from weighted evidence that matched our expectations for the project.

The add-in insights in the research repository, Mar to May 2026, weighted by evidence

Insight	Status	Confidence	Evidence
Reliability failures erode firm-wide trust and outweigh feature gaps as the adoption barrier	EstablishedEstablished insight	HighHigh confidence	18 observations
Renaming attachments while tagging is the gateway feature for adoption	EmergingEmerging insight	HighHigh confidence	8 observations
Case matching fails on closed-case clutter and shared parties; matching on the sender alone is not enough	EmergingEmerging insight	ModerateModerate confidence	7 observations
Tag and send, or forward, is a missing high-frequency workflow	EmergingEmerging insight	ModerateModerate confidence	6 observations
No visibility of what is already tagged drives duplicate tagging	EmergingEmerging insight	ModerateModerate confidence	4 observations

Act 1: the attachment section

An Outlook add-in lives in a narrow vertical pane. Even a modest set of fields forces scrolling which is further exaggerated when accounting for attachments. Emails often have multiple attachments, each needing the same full set of controls. Some attachments always come with long machine-generated names, so users need to rename them. They also need to select which attachments to tag, and the right folder in the product to file them. On top of that, it wasn't uncommon for users to receive over a dozen photos for a motor-vehicle-accident case that all needed to be tagged with as few clicks as possible.

The legacy add-in let users choose which attachments to include and set a Type and Category on each, but every file sat in a fully expanded block with a fixed filename and no way to set anything in bulk. Besides no bulk controls and that three attachments filled the whole pane, the machine-generated names couldn't be changed, and that was the key failure in the workflow. Users never used the add-in for attachments because they nearly always needed to rename them. As such, the workaround for everyone was to drag attachments out of Outlook, onto their own machines to rename, then drag into the case-management product in a separate window to file them to the correct case and folder. That workaround was the thing to kill and my main focus early on.

I tackled it by designing each attachment as a type of accordion that collapses by default showing the following: a select checkbox, the filename inline and editable with its extension split off, a document-type icon, and a control for the accordion itself. Collapsed, the row is a one-line summary, so a long list costs about one line per attachment and only the row you're working on expands. A Bulk Assign control sets filing details across every selected attachment at once, which is the primary move for a set of dozens rather than expanding thirty rows by hand.

The field layout came out of what the fields mean. In the product a document's Type is its folder and its Category is a sub-folder inside that, both single choices, so they sit paired on one row. A Tag is a multi-select label, so it needs the full width and sat below the folder fields. All three decide where the document lands in the product.

Legacy

Rebuilt

Of course I didn't one-shot this with Claude Code, but rather through multiple rounds of iteration outputting HTML prototypes to get a hands-on feel for the interactions as I went, then later adjusting to the live dev build once we had more exposure to Outlook add-in requirements and limitations. For example, I initially placed Type, Category, and Tag on a single row trying to lean into vertical space savings which worked in the prototype, but failed miserably in the early dev build.

You don't have to open up the document and download it to your computer, rename it, and then drop it in [the product]. So it's taking a couple of steps away.

Legal assistant, insurance-defense firm

Act 2: showing an email is already tagged

The second decision looks small and did more for trust than anything else in the beta.

The legacy add-in only showed that an email was already tagged once you opened it on that email. Nothing in the inbox said so, and nothing stopped a second tag. So firms tagged the same email twice. In one firm four secretaries each checked every email by hand, opening the product to see whether a colleague had already handled it. Duplicate tags then piled up as data someone had to clean up.

Legacy

Rebuilt

I designed a layered set of signals that never blocks the user. A badge on the Outlook email shows it's already tagged. Opening the add-in on that email surfaces the case it's tied to with a "Tagged" status. Pushing further raises a warning. At no point is anyone hard-blocked from tagging again, as blocking a legitimate action to prevent a mistake breaks a basic rule of our design system. The signals scale in urgency as users get closer to duplicating a tagged email, and they cost no extra clicks, where any one of the signals is enough to stop the redundant work without alarming them unnecessarily.

The payoff is threefold. It saves the time of re-tagging, it prevents the duplicate data that needed cleanup, and just as important, it restores confidence in the product for users. It became the feature users named most often. One described it plainly: "I really like how the little box shows up when you know other people have already put it in. That is so helpful." In roughly the first month of the beta, the already-tagged signal fired over 6,000 times.

A smaller call: cutting a feature users asked for

Users had requested a Favorites tab for pinning cases, so initially I included it in designs. Interviews and a closer read of the workflow showed it was rare for anyone to return to the same case often enough, or long enough, to make favoriting worth the effort to build. The real problem driving the request was finding cases fast enough, a mix of weak search and nothing helping users find the right case before searching. I cut Favorites and put the effort into a Suggestions view that proposes the right case from the email's addresses, plus new cached filters that provided more relevant search results. It was a want-versus-need call, and despite the users wanting favorites, they really just needed better access to their cases.

Outcomes

• The beta cohort scored CSAT 8.4 across 8 firms during a two month period, above the 7.5 bar set for general availability. Scores ranged from 6 to 10.
• Several firms stopped falling back to the legacy add-in entirely and used the beta for everything.
• 17,432 core tags were logged across 11 firms between mid-July and late September 2026, alongside roughly 61,300 case suggestions shown and over 23,400 already-tagged signals fired. Weekly volume went from 149 tags across 3 firms to about 5,000 across 10.
• One firm began rolling the add-in out to itself, with its administrator giving access to staff members that weren't originally part of the beta. It was the beta's first firm-led expansion, and the clearest signal that the tool had earned its keep.
• The strongest signal came from leadership. They chose to widen the rollout beyond the controlled beta while it was still missing planned features, on the strength of how enormous the time savings were for users and how much more stable the beta was compared to the buggy legacy add-in. By late September the add-in was live in 11 firms, up from the 7 tagging in mid-August, with two more onboarding in the final week of the window.
• Despite our best efforts, the beta still had bugs, some we addressed quickly, some I wasn't able to see fixed as I left the company. A legacy-parity send feature carried a bug on Outlook Classic, and once that fix landed its success rate went from 62% in mid-August to 89.8% by late September. Search was not good enough for large firms, and a lack of native Mac compatibility was critical enough for one firm to pause its beta testing.

Core tags submitted per week across customer firms, Jul to Sep 2026

Show the data

Week of	Tags	Firms tagging
Jul 12, 2026	149	3
Jul 19, 2026	145	4
Jul 26, 2026	406	7
Aug 2, 2026	538	6
Aug 9, 2026	527	6
Aug 16, 2026	562	7
Aug 23, 2026	840	8
Aug 30, 2026	1,672	8
Sep 6, 2026	2,395	8
Sep 13, 2026	5,090	8
Sep 20, 2026	5,078	10

Reflection

The trust win was the cherry on top, not the sundae.

When starting this whole project, discovery interviews were defined unanimously by "don't bother with new features, just give me something without bugs". User trust was completely broken, and the firms that opted to participate in the beta initially treated it like a gamble... and it paid off. The beta completely smashed their expectations. A lot of the restored trust is down to the stability of the beta and other smaller enhancements, but most of the CSAT climb came from a flow that feels as easy as the old one despite doing more, with the time savings designed in and named back to us in testimonials.

Another lesson for me was about working with AI. I couldn't have done all of this as quickly as I did without the help of AI from the research to the design. My early experience with AI was one-shotting prompts and hoping for the best, but that quickly ran its course and I learned that in order to get the best out of AI, I needed to build systems for it. My research for this project was almost entirely analyzed by our atomic research repository which freed up tons of time for more user interviews and outreach. And designing became much more accurate and helpful once I built out a design system built for Claude Code to guide our prototype skill. My favorite part was asking it to produce different concepts to tackle specific problems and doing that over and over until I landed on frankly amazing solutions. AI didn't make any of these decisions for me, but it did expedite and facilitate navigating through my standard design process and that ultimately unlocked more time for more research and a quicker iteration cycle for validation.

I go into that setup in my case study: Designing with AI.

---

Method: a problem and gap list built from years of support tickets, the customer ideas portal, and PM interviews, which I synthesized and then confirmed in unbiased discovery. The design was validated in a ten-session wave in March 2026 with the same firms that later ran the beta from July 2026, so the shipped tool went back into the hands that had tested it. Usage figures are a Pendo pull from 2026-09-27; CSAT is from the beta-hub scored calls to mid-August.