ArgusHack ─ Drill Scoring Redesign
Project Duration
About 3 months (2025 Q4, run in parallel with other projects)
Development Process
Agile
Company
Leukocyte-Lab
Role
UI/UX Designer
Responsibilities
Spec writing, wireframes, mockups
Tools Used
Figma, Notion
Background & Problem
Background
ArgusHack is a BAS (Breach and Attack Simulation) platform — like a fire drill, it simulates real attacks in an enterprise's environment to help them verify their defenses and find gaps before a real attack happens. The whole flow breaks down into three stages:
Drill results are the key basis users rely on to judge how strong their defenses are and plan what to reinforce next. But the product's users range from security engineers to managers with no technical background, and the old flow depended heavily on an engineer's expert judgment — leaving non-technical users unable to complete it on their own, and the resulting score could lose its value as a reference. So most clients had long been asking for a more automated way to get drill results.
That request only became feasible after a technical breakthrough — the system could now automatically determine whether an attack succeeded once a drill ended. My job was to turn that technical capability into an experience users could actually understand and use.
Role & Output
Teamwork
This was the first time I independently led the design of a large feature. In the past, the design team usually split up different parts of the same project between me and the Design Lead; as R&D started pushing a model where one person owns a single feature from requirements through to shipping, the design team adjusted how it worked too. This time I was the design owner for the feature — I drove everything from problem definition and design planning to the final solution, while the Design Lead served as a sounding board and did design review.
Given how complex the feature was, I first used a spec to clearly define the problem and design scope, then worked through wireframes and mockups in order — proposing design solutions and their rationale along the way, and discussing them with the Design Lead and front-end teammates to validate feasibility. With no user data to lean on, talking across roles became my main way of calibrating design decisions and making sure the solution actually fit real usage. This project also marked an important turning point for me — moving from an individual contributor to owning a feature outright, and starting to build a complete track record from problem definition through to shipped design.
Existing Problems
Focus on Problems
The product's original value proposition was built around accuracy. Early users were mostly government agencies and large organizations willing to invest time for precise results, so the flow for getting a score was designed around that assumption. But as the user base grew, that assumption stopped holding — new users mostly had no dedicated security staff and couldn't absorb the same operational cost. The team had tried using AI assistance to ease the burden, but given the technical constraints at the time, it was only a stopgap.
Those constraints showed up concretely in the two ways of getting a score. After a drill ends, the system first needs to know whether each attack step was detected by the defense equipment before it can calculate a score, and the old version's two paths each had their own barrier to entry:
Method one｜Manually upload logs and label detection status
Users had to cross-reference the drill's timing against the defense equipment's logs entry by entry, find the matching records and paste them back into the system, then judge from the logs what the defense equipment actually detected at the time. The whole process was like having to dig up the matching security-camera footage yourself just to confirm one thing, then interpret frame by frame what actually happened.
Users had to find the matching logs for each attack step and judge the detection status themselves
This method relied on technical knowledge and was tedious in itself. Most users couldn't complete it on their own, so scores often came out at 0 or low; and as drills grew more frequent and larger in scale, even technically skilled users started complaining it was time-consuming and easy to miss things in. To ease the burden of cross-referencing and interpretation, the team later introduced AI-assisted labeling to let the system handle most of the work up front.
Method two｜AI-assisted bulk status labeling
Once third-party defense equipment was connected, the system could auto-match the whole batch, and users only had to check whether the AI pulled the right time window and got the detection status right — a much lighter load than doing it manually. But this feature's ideal spot would have been during the drill itself; given the dev timeline at the time, it ended up tucked into a single tab on the drill results page. The entry point wasn't obvious, so most users never even knew it existed, and reviewing the AI's output still took some technical judgment, which remained hard for users without a technical background.
User Profile
Users
The product's later-stage clients were mostly small and mid-sized businesses. For these companies, security usually isn't the core business, and they rarely have dedicated security staff in-house — what actually drives them to deal with it is mostly regulatory compliance. How they respond also varies — some build a small internal security team, others outsource the whole thing to a service provider.
That also means there's no way to predict in advance who's actually going to open the product — it could be a technical security person, a manager handling compliance, or an outside service provider. Looking at it by purpose, two clearly distinct needs emerge:
*Security products rarely have direct access to users, so this segmentation is distilled from feedback relayed by sales and AI-assisted scenario modeling
These two needs conflict directly — one wants a result with zero effort, the other wants to dig into every detail. Rather than splitting the difference, this redesign used audience-tailored design so users with different needs could each get what they came for.
Audience-Tailored Design
Segmentation
How It's Split
The new version splits drill results into two scores to meet different users' needs for speed versus precision.
Once a drill finishes, the system automatically produces a Defense Score, quickly answering whether the attack succeeded, so most users get a result with no extra effort at all. Users who need deeper analysis can then upload logs via AI or manual labeling to get a more precise Detection Score. Since automatic judging can only tell whether the attack succeeded, the two have to be shown separately, so users don't mistake it for their defense equipment not working.
The two scores represent different cost trade-offs: the Defense Score trades some precision for zero operational cost, while the Detection Score takes an extra labeling step but delivers higher analytical accuracy. By splitting the flow this way, users can freely choose the effort they're willing to put in against the precision they get back, based on what they actually need.
Naming Decision
The two scores aren't a hierarchy — they're two different lenses on the same drill. For naming, I looked at how competitors handled this and used “Defense” and “Detection” to distinguish the two analytical angles, so users wouldn't mistake the automatically generated initial result for a lesser one, or read the two scores as a ranking.
Design Docs
Spec
Once the segmentation direction was set, the next challenge was getting this design to actually ship well. In the past, the design team had only two people working in a highly collaborative mode with R&D, so design files never covered every detail — if front-end had a question during implementation, they'd usually just leave a comment on the design file or talk it through with the designer directly.
But this plan spanned multiple stages before and after a drill, involving two user scenarios and multiple flow branches — well beyond what real-time communication could effectively cover. Relying on design files and verbal discussion alone made it hard for R&D to grasp the full design intent, and it also made QA's verification process harder.
So I referenced R&D's existing documentation structure and put together the design team's first complete spec, folding the flow, user stories, and requirements into one shared document that design, development, and QA could all communicate off of.
Design Output
Focus on Problems
Before the Drill: Confirming Whether a Scenario Supports Automatic Judging
Since automatic judging didn't yet cover every scenario, and its coverage would keep expanding as scenarios were updated, users needed to be able to confirm in advance which scenarios supported it when choosing one. So I added a support-status indicator to the scenario list and detail page, along with a sort option to help filter, so users can confirm before starting a drill whether that scenario will produce a Defense Score.
During the Drill: Focused on the Execution Process, No Extra Steps Needed
The in-progress drill screen focuses purely on the process itself: the technique used at each attack step, and the system's automatic judgment of the outcome. Users can look at the details one by one, or just let the drill run automatically without touching anything; labeling detection status was moved to after the drill ends, with a hint on the right side of the screen noting that a Detection Score becomes available afterward — keeping all results information consolidated on the Results page.
After the Drill: Presenting Overall Results, With Deeper Analysis Available on Demand
Once a drill ends, the system consolidates the automatic judgment results and shows the Defense Score on the Results page; if deeper interpretation is needed, users can label detection status with AI or manually on that same page to get a Detection Score. Since the old AI-labeling entry point wasn't obvious and users rarely noticed it, this time AI and manual labeling became a primary action on the page, guided by explanatory text — letting users choose whether to label further based on their needs, without forcing them to.
Providing the scoring rationale so users understand where results come from
Since the old interface never explained how scores were calculated, users often had to ask separately to understand where a score came from after getting their results. So I added explanations during the drill, on the Results page, and in the drill report, laying out the definitions for each judgment status and the formulas behind them — so users can check what makes up a score whenever they're viewing the drill in progress, the results, or looking back afterward.
*This feature was originally planned to ship after Design System v2 was complete; a later change in company decisions meant it ultimately shipped on schedule using the old design system instead, so the designs shown in this case study are the original v2-planned version — see [Design System v2 Redesign] for more on that plan. This case study's content has also been shared with my former company's consent; some details are omitted here — happy to go deeper in an interview.
Results
Results
Automated judging shipped, giving the product a competitive edge
After the feature shipped, it filled a long-standing gap in the product's automation, and the audience-tailored design gave sales a stronger story in competitive comparisons — strengthening the product's position in the market.
Learnings & Reflections
Takeaways
A document's value is in communication, not just specification
Building the spec gave me a new understanding of what a design document is for. It's not just a record of the requirements — more importantly, it becomes the team's shared reference point. When R&D or QA had questions about the flow, they could align quickly through the document instead of relying on memory or individual interpretation. That also changed how I write documents going forward: rather than trying to record every single detail, it matters more to clarify the parts most prone to ambiguity, so the document actually helps the team make consistent decisions.
Naming rarely lands on the first try — balancing precision and clarity
Naming the Defense Score took a fair amount of time. Since the result comes from the system's automatic judgment, I initially wanted the name to convey where it came from, so I picked a name that reflected the calculation method (Auto-Evaluation Result) to help users understand the logic behind the number. But after the feature shipped, some users still said the name was hard to understand. That experience confirmed for me that product naming has to balance technical precision against user comprehension — lean too technical, and you raise the barrier to understanding; lean too colloquial, and you might lose the information you meant to convey. A name isn't something you can nail down purely at the design stage — it needs continued validation and adjustment against how it's actually used.