Reimagining a product with a Prototype First approach.
The idea
In design we were used to building user flows, wireframes and layouts in Figma before finding a good way to prototype, if prototyping happened at all.
I was lucky enough to get the freedom to work differently: to reimagine the most crucial part of a product I had previously been designing the classic way.
The workflow
No wireframes, no user flows, no Figma layouts.
01Brief
I had already been working on the same product and user persona for a good while, so the brief wasn't about detailed requirements or industry-specific information. It was basically a blank check: gather intel and reimagine how a Security Operations Center analyst or a threat hunter goes through a threat report.
The complexity of this step was the wide spectrum of stakeholders and aligning their visions: the Chief Product Officer, CTO, Product Owner, Global Design Lead, Design System Lead, the Analysis Engine team, backend and frontend developers and the Malware Laboratory team.
02Research
I like to start deep, so I collected data from four directions before touching anything visual.
Customer support
Support tickets never lie (almost never). They weren't tagged or grouped, so I went through 500 tickets. The conclusion was clear: single data types were shown in an easy-to-understand way, but the correlation between data types was hard to find. A user could easily see the list of Indicators of Compromise, and the extracted and downloaded files in another view — but not which indicator came from which file.
Sales
Our Solution Engineers know what customers look for when they compare us to other solutions. Beyond the classic feedback on price and speed, they were looking for ways to extract the unique identifiers of an attack faster and more precisely — which again depends on understanding how the data connects.
Logged data
Most customers run air-gapped systems, so there's no usage data from them — but our public, community-facing version gave us Google Analytics and Coralogix data. Besides the usual metrics, I found data-type pairings users often checked one after another in different report types.
User interviews
Our in-house malware analysts do the same work as our users every day. Instead of a fictional example, they worked on real threats they had to investigate anyway, sharing their screen and thinking out loud. That surfaced a behaviour nobody would report as a problem: they all spent a lot of time connecting the dots between data types — memorising the first characters of hashes, or keeping several windows of the same report open and jumping back and forth.
The variety of these flows was too big to handle with one or two new views, or by adding a few details from other data types to existing pages.
03Information architecture
In this field random sample data isn't a good enough base. Real reports contain thousands of data points in 20+ groups, all cross-connected, and you don't know in advance which combination or filter will be useful. Building one realistic structure and wireframe could take hours just to collect and filter the data — and a working prototype multiplies that effort.
A resource-heavy method leads to trying fewer things, which leads to safer versions and missed solutions. This is where AI was a game changer. It took two steps:
- Teaching Claude to fetch data from real-life reports.
- Teaching it the connections and relationships between data types — some of which weren't even made in the product yet.
As a result I could very quickly research data connections in the database, check them against real samples, and wire them under the prototype — no data adaptation needed after every prototype or layout version.
04Prototype frame
In the background we put together a prototyping frame for all our products. It started as a classic Figma style guide with tokens and components; developers then built the key foundations and components in Storybook.
Then came the idea to build it with AI, so complex prototypes wouldn't need a developer. After trying a few options we settled on Claude Code with a simple GitHub workflow, rebuilding the full style guide from the Figma and Storybook pieces. We fed it our company vision, product specifics, personas, industry know-how and copywriting policy, so every product prototype used the same components and knowledge.
The process: pull the latest version locally, work there, push to staging at the end of a topic to show stakeholders and run user tests, and merge to main once it reached a certain maturity. For my product it started as an empty frame — colours, styles, fonts, navigation and common functions like the user menu and login.
Empty prototype frame based on the Design System
05Ideation and prototyping with Claude Code
No user flows, no wireframes, no Figma layouts. Prototype first.
This method came with a learning curve: understanding how to slice tasks for Claude, what needs more detail in a prompt, and in what order to do things. I focused on three areas identified in the research.
Focus area 01Connecting data types that constantly vary
Even in a simple 2D matrix it matters whether you show data row by row or column by column — like browsing shoes by style or by sport. Here, information from different data types was connected by random metadata, and users collected it from various tabs and tried to connect the dots in their heads. In the shoe example, that's a list page with a basketball shoe, a sneaker, three slippers and a bag of potatoes — because they were all packaged on the same date.
Solution
Click any attribute in the report and see everything we know about it without navigating away — context, related items from every data type, and trend information from other reports. From there the user can pick any further attribute and continue the flow.
Focus area 02Mapping which finding came from which step and file
A scan has three main layers: threat intelligence, static analysis and dynamic analysis. It isn't linear — if the scan finds new files (downloaded during execution, or extracted from an archive), the whole process runs again for them. So when users saw a finding, it was hard to trace where in the chain it was found and what triggered it.
Solution
An Indicator of Compromise map that shows the process of the scan and what was found at every stage.
Focus area 03Comparing similar reports to start threat hunting
After a scan we can search our database for similar reports — the threat hunting use case, where users look for patterns across attacks. The hard part was explaining in what way another report is similar to the original.
Solution
A similarity indicator showing all 10+ similarity categories at once:
- the percentage of similarity in each category
- the importance of each category, shown by size
- which category group it belongs to, shown by grouping
06User testing
Our malware analyst experts were the testers. The big difference: I could give them real reports generated in the new prototype — ones they had to work on anyway. No made-up use case; I let the professionals do their threat analysis and hunting, and listened.
All three focus areas performed very well and proved to be a big improvement over the previous version and way of working.
07Prototype update
After the user tests, I got feedback from the product owner about the business use cases: the new flows also had to make the product easier to sell in sales demos. So the goal grew from easy to use to easy to show. Since the prototype ran in Claude Code on real report data, I could make these changes directly in the prototype instead of going back to static layouts. Each update went to staging, where the product owner could review it right away. This kept user needs and business needs in the same loop.
08Hand-off
The hand-off was really easy, since the developers could click through the working prototype themselves instead of interpreting static screens. Next to it, I generated a hand-off document with the details they needed. Because the prototype was built on the same style guide and components as the product, much of the behaviour was already defined. The developers could check any interaction in the prototype instead of asking about it. All of this made the information flow much faster and clearer.
Summary
Working prototype first changed both the speed and the courage of the design process. Instead of static layouts, every idea became a working screen built on real report data, so analysts and stakeholders could click through it rather than imagine it. Because every prototype was built in Claude Code on one shared style guide and one source of product knowledge, each new version stayed consistent without extra design or development effort. That speed let us try more directions instead of settling for the safest one. Testing with real reports and real analysts confirmed the approach: all three focus areas proved a clear improvement over the previous version and the old way of working.