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.
Results and business impact
AI reads consistently across the product
Users now meet one visual language for AI wherever it appears. That consistency is what lets someone know when to trust an output and when to check it, which was the trust problem the guidelines were written to solve.
AI features ship faster
Designers and developers build from a documented component library instead of re-deciding colours, icons, and naming for every new feature. Studies of mature design systems show meaningfully faster builds, with IBM's Carbon measuring 47% in a controlled comparison.
Decisions don't get re-litigated
Every rule ships with its reasoning, so the team resolves edge cases themselves instead of escalating. That is what keeps a guideline in active use as the product grows, rather than quietly drifting out of date.