This is where the gritty details live - the main working hub of the platform alongside Co-Hunter. Given how dense the hunt list gets, I added overview widgets above the table itself: counts for activity in the last 24 hours and 7 days, suspicious hunts, threats found, and clean results. The goal was for a hunter to glance at the top of the screen and instantly understand what's going on - status, risk, volume - without having to parse rows of data first. It turns a wall of information into something scannable in seconds.
The depth of the table view meant we needed a way to help hunters narrow in on exactly what they're investigating. By adding sortable columns for timestamp, hunt name, type, status, outcome, severity, findings, source, and version, plus multi-select filtering with active filter chips we were able to achieve that goal. We also provided a multiple selection function for Sources which shows a count badge (e.g. "+3 Source") alongside individual chips, so it's always clear what's active without digging into a dropdown. The Status and Outcome filters got priority placement, since they were the fastest path to the question that mattered most: does this hunt need action right now. History and Scheduled live as separate tabs here, each with filter and sort logic tuned to its own intent - reviewing what happened versus planning what's coming next.
The Head of Product's initial list had eight options - Run Hunt, Schedule Hunt, View Details, Delete Hunt, Pause/Resume, Duplicate, Archive, and View in Intelligence Hub. I pushed back: that many choices - in a single dropdown - is known to create decision overload, especially for an action users take frequently. I narrowed it to the four that carried the most value - Run Hunt, Schedule Hunt, View Details, and Delete Hunt.
Cutting “Duplicate” from actions was one of the clearest changes due to its main use case - re-running a hunt with the same parameters - was already covered by Run Hunt, which re-executes the existing hunt against the same campaign with no extra input required. A separate Duplicate action would have just created redundancy without adding real value. It's a decision I'd revisit if the need shifted toward cloning a hunt to modify it independently (different sources, tags, or hypothesis) - that's a distinct enough use case to justify its own flow later.
This wasn't something leadership had planned - I pushed for it myself once I recognized the product was missing a visual layer that could ease the information overload of sifting through raw hunt data. Instead of forcing execs to interpret rows and columns, the Dashboard translates hunt activity into charts: status, type, method, outcomes, origin over time, and severity, all filterable by time range. Below the charts, a list of the underlying hunts lets anyone drill from a high-level trend straight into the specific data behind it. It wasn't something I'd seen competitors offering either, which made it feel less like a nice-to-have and more like a real point of differentiation for the product.
Designing Hunts Hub also meant designing for what happens when the data isn't clean or complete - I mapped six of these scenarios before handoff. Here's one example: a new user with zero hunts would normally see six broken or empty charts on the Dashboard. Instead, I designed placeholder states paired with a clear "Create your first hunt" call to action, so a user's first experience with the feature is a next step, not a dead end.
When the Dashboard was deprioritized, I still wanted its presence felt rather than erased. A disabled state with a hover tooltip reading "coming soon" kept the design minimal and didn't pull focus from the hunt lists. Just as important, it stayed entirely within existing design system components - which meant preserving the vision cost almost no extra development or design time against a deadline that didn't have room to spare.
Hunts Hub replaced a buried, multi-click flow with one dedicated space built for both analysts and executives. Every decision - from the Actions menu to the dashboard's edge cases - was considered against real trade-offs before reaching engineering. I left the company before the feature shipped to production, so these reflect the design outcome, not live usage data.