Serving two different audiences
Rather than splitting the Hunts Hub into separate features, I proposed a single screen with two views: a Table view built for Threat Hunters and Security Analysts who'd work with the data and investigate, and a Dashboard view built for CISOs and CTOs who'd primarily view the high-level hunt activity - giving the product a new UI component to motivate and engage all our users.
Deliberate control capability
Solving for "missing depth" meant getting specific about how threat hunters actually work, not just adding more unclear controls. I defined filter and sorting capabilities so hunters could quickly see and adjust exactly which sources they were investigating, like most relevant hunts to most prioritized, so a user could immediately tell whether a suspicious hunt needed action - turning a dense table into something a hunter could actually triage from, instead of just browse.
Rather than splitting the Hunts Hub into separate features, I proposed a single screen with two views: a Table view built for Threat Hunters and Security Analysts who'd work with the data and investigate, and a Dashboard view built for CISOs and CTOs who'd primarily view the high-level hunt activity - giving the product a new UI component to motivate and engage all our users.
Navigating ambiguity and purpose
Deciding whether Hunts Hub should focus on archiving hunts or managing them was a main misalignment among stakeholders. I stepped in to help mediate by flagging that without aligning on intent, we risked shipping something that satisfied neither use case and left both types of users underserved. In order to hit development deadlines without forcing a premature decision, I suggested we use an existing design system tab component by splitting the Table view into History and Scheduled to let both intents coexist. This would give hunters a dedicated space for past activity and a separate one for what's ahead, rather than compressing both into a single cluttered view.
Deciding whether Hunts Hub should focus on archiving hunts or managing them was a main misalignment among stakeholders. I stepped in to help mediate by flagging that without aligning on intent, we risked shipping something that satisfied neither use case and left both types of users underserved. In order to hit development deadlines without forcing a premature decision, I suggested we use an existing design system tab component by splitting the Table view into History and Scheduled to let both intents coexist. This would give hunters a dedicated space for past activity and a separate one for what's ahead, rather than compressing both into a single cluttered view.
Deliberate control capability
Solving for "missing depth" meant getting specific about how threat hunters actually work, not just adding more unclear controls. I defined filter and sorting capabilities so hunters could quickly see and adjust exactly which sources they were investigating, like most relevant hunts to most prioritized, so a user could immediately tell whether a suspicious hunt needed action - turning a dense table into something a hunter could actually triage from, instead of just browse.
Protecting the vision
When the Dashboard view was deprioritized, I made the case for it directly to leadership that part of our audience would lose value and motivation to stay engaged. Ultimately we landed on a compromise by keeping the Dashboard button visible in a disabled state instead of cutting it. While it may seem like a small detail, it would solve scalability and motivation in one.