Design System for AIMS Virtual Asset Assessment
A scalable foundation for geospatial tools
How It All Started
In 2020, I worked on AIMS Virtual Asset Assessment, a web-based tool that enables utility companies to remotely inspect pole-top assets using aerial imagery and GIS data. As a company focused on building geospatial products for the utilities sector, we were already working on multiple tools that shared similar interaction patterns: 2D map interfaces, dense data filtering, asset selection, and layered visualisation.
For AIMS Virtual Asset Assessment, our most complex, map-driven tool at the time, we made the decision to establish a shared design system upfront. This would not only streamline our UI development for this tool, but also lay the foundation for future geospatial products to reuse components, patterns, and styles in a consistent way.
Defining Our Goals
I took a step back and spent time with the people who’d be using or building with this system - our engineers, product owners, fellow designers, and QA testers. Some questions were raised like, "What slows you down when building new features?" and "Where do we see the most inconsistency between products?"
I also reviewed past project handovers, engineering tickets, and Figma files to spot patterns in layout, interactivity, and pain points.
These conversations and collaborations shaped the four key goals for the system.
01
Support Geospatial Interfaces
The system needs to support map-first layouts with flexible side panels, overlays, and dense data interactions, without feeling cramped or causing fatigue.
02
Enable Reuse Across Products
Since we are a geospatial platform company building multiple tools, components need to be modular and adaptable and not tied to any one tool’s logic.
03
Balance Density and Clarity
Users worked with large datasets and need to make decisions fast. The system has to present complex data clearly, with careful use of hierarchy, spacing, and typography
04
Accelerate Collaboration
Devs need specs and guides. Designers need reusability. The system has to include clear variants, documentation, and a naming convention that scales.
Design At Altavec
To kick off the system, I audited our existing tools, mapped out repeating UI patterns, and collaborated with developers, testers, and POs to define what needed to be standardised. Below are some highlights from the system we built.
Foundation
Components
Outcome
The system we built didn’t just streamline design but it also gave our product, engineering, and QA teams a shared language. And it scaled beyond this one tool.
