AI Visual Guidelines
Defining visual standards for AI-related components, ensuring consistency across the product.
Company
ecoPortal
My role
Product designer
Tools
Figma and Research
Context and process
As AI features multiplied across ecoPortal's platform, such as smart assistant, AI-generated summaries, smart form fields, language translation, there was no shared visual language to tie them together. Each feature risked expressing AI differently: different colours, different icons, different logic for when to signal AI involvement at all. The guidelines were created to change that, giving the whole product team a consistent, documented foundation to build from.
Defining when AI should be visible
Not every AI-powered interaction needed a visual signal. One of the first decisions was establishing a clear rule: AI visuals are applied when a feature is powered or enhanced by AI, and withheld from standard UI elements and actions, even when AI is working behind the scenes. That distinction alone prevented a lot of over-signalling.
Building a system, not a style
The guidelines went beyond colour and icons. They covered gradient construction and application, icon design principles, naming conventions for AI features in copy, and a full component library across web and mobile, so any designer or developer could apply the language without guessing.
Designed to scale with the product
The document was structured to serve as a living reference: examples across real product components, do/don't comparisons, and rules specific enough to be actionable but flexible enough to cover new features as they were built.
Design question
How to make sure the design team will continue creating consistent icons?
By elaborating a proper documentation that highlights the icons' creation and its rules.
Key takeaways
Visual consistency is a product decision
The guidelines existed because inconsistency across AI features would have eroded user trust, if AI looks different everywhere, it's harder to know when to trust it and when to question it. Framing this as a trust problem, not just a style problem, made the case for investing in documentation that went beyond a colour swatch.
Rules need to explain their reasoning
A do/don't without a "why" gets ignored or misapplied. Every rule in the guidelines was written with its rationale, so the team could make judgment calls on edge cases rather than coming back for answers.
Designing for other designers
Unlike a feature project, the audience here was internal, other designers and developers applying the language to new work. That changed the design challenge entirely: clarity, completeness, and usability of the documentation itself were the deliverable.