ZETAGON

I built this entirely in Figma, from scratch. There was no existing design system, no previous version to reference, no hand-off from another designer. Every decision, from the type scale to the navigation structure, had to be made and justified from the beginning. The goal was a platform that felt coherent and easy to use, even as the feature set grew.

Making the same decision twice is how inconsistency creeps in. So before touching a single screen, I defined the foundations: typography, colour tokens, spacing, buttons, inputs, cards, tables and navigation patterns.

It cost time upfront. It saved more later. Once a component existed in the system, I never had to design it again.

I started with the login flow and a few supporting screens. Not because they were the most important, but because they forced early answers to visual questions: how dense should the layout feel? How much contrast between surface levels? What does hierarchy look like in practice?

I revised these more than anything else before the direction felt settled.

It went through more revisions than any other part of the product.

Cards were added, then cut. Chart types changed. The quick-action row moved three times. I kept pulling up older versions beside newer ones. Not to go back, but to understand what each change actually improved. That comparison drove most of the progress.

With the dashboard stable, I moved to the remaining pages: site management, anomaly detection, the map view and reports. Each introduced its own layout challenges, but the rule stayed constant: reach for an existing component before building a new one. That constraint kept the interface coherent as the page count grew.

The work wasn't one big design moment. It was a long sequence of small corrections, each one moving things slightly closer to right:

• Tightening spacing until the layout breathed correctly
• Dropping a heading weight to reduce visual noise
• Reworking a table so the most important column read first
• Removing an element that looked fine in isolation but competed in context
• Trying a completely different layout for a section, then going back
• Revisiting a decision from two weeks earlier with clearer eyes

I never treated buttons, forms or tables as isolated UI elements. Each one was designed in the context of where it would actually appear, with at least one other context already in mind. If a component couldn't justify being reused, it didn't get built.

That discipline kept the component count manageable and the interface consistent.

After connecting everything into a working prototype, I found a handful of things that hadn't been visible while designing individual screens. Navigation that felt slightly off once you moved through it. Transitions that didn't communicate what was happening. A few more passes later, the experience held together.

Looking at the final prototype, no single screen stands out as the moment it came together. The system, the components, the layouts and the interactions grew alongside each other, each one shaping the others.

Almost every page changed more than once. That wasn't a sign of indecision. It was the process. I kept comparing, questioning and adjusting until the product felt like one thing, not a collection of screens designed separately.