Designing AI Products, Systems & Ecosystems
Design Lead
Product Strategy · Product Design · AI UX · Developer Experience · Design Systems · Brand · Design Leadership
Overview
From designing products to designing an ecosystem
Sahara AI was evolving from an early-stage AI product into a broader ecosystem connecting AI, data, developers, contributors, and users, with blockchain infrastructure supporting ownership, attribution, and traceability.
As the ecosystem expanded, the design challenge changed.
It was no longer simply:
How do we design an AI product?
It became:
How do we create a coherent experience across multiple AI products, audiences, and layers of infrastructure?
As Design Lead, I worked across product strategy, product design, design systems, brand, and team leadership, helping the organization move from individual product experiences toward a scalable design ecosystem.
My Role
Leading design across the ecosystem
The Context
From an AI Product to an AI Ecosystem
The Product Ecosystem
The Design Challenge
How do we turn a complex AI ecosystem into a coherent product experience?
As the product ecosystem expanded, three design challenges became increasingly important.
01 — Fragmented Products
Different products were evolving at different stages.
This created inconsistencies across:
Information architecture
Navigation
Components
Interaction patterns
Visual language
Users moving between products could experience them as separate tools rather than parts of the same ecosystem.
Design question
How might we create a shared experience without forcing every product into the same mold?
02 — Increasing Complexity
The products involved increasingly complex concepts:
AI · Data · APIs · Agents · Projects · Tasks · Contributors · Blockchain
The solution was not simply to remove complexity.
Some complexity was inherent to the product.
Design question
How might we make complex systems understandable without oversimplifying them?
03 — Invisible Infrastructure
Blockchain was an important part of the underlying infrastructure.
But most users did not need to understand:
Transactions · Smart Contracts · Hashes · Gas · Blockchain Architecture
They needed to understand:
What did I contribute?
Where did it come from?
Was it recorded?
Can it be verified?
Can it be traced?
What is my role in the ecosystem?
Design question
How do we design blockchain without designing for blockchain?
Design Principles
01 — AI Marketplace
Designing an Economy for AI Assets
From an AI catalog to an AI asset ecosystem
Sahara AI Marketplace was not designed as a traditional marketplace for browsing AI products.
The larger product model connected multiple participants:
Knowledge Providers
provide knowledge and data
Developers
create AI assets
Users
discover, access, license, and use AI assets
Sahara Toolkits
provide the tools for creation
Sahara Blockchain
records ownership, attribution, transactions, and value exchange
This created a fundamentally different marketplace problem:
How do we design an experience that connects AI creation, distribution, consumption, and value attribution into one coherent system?
The Ecosystem Model
Sahara Blockchain
It records key activities across the ecosystem, enabling:
Attribution · Ownership · Verification · Traceability
The Design Challenge
How do we make a multi-sided AI economy understandable?
The challenge was not simply to help users find AI.
It was to make the relationships between:
People × AI Assets × Transactions × Value
clear and intuitive.
My Design Approach
02 — Developer Portal
Designing the Creation Layer of an AI Economy
Sahara AI was not building a traditional developer platform.
The goal was to create an ecosystem where developers could build AI, distribute AI assets, and participate in the value generated by them.
This made the Developer Portal more than an interface to infrastructure.
It became the creation layer connecting developers to the AI economy.
The Strategic Shift
From a Web3 Ecosystem to an AI Ecosystem
The traditional Web3 growth loop was largely driven by infrastructure and transactions:
Infrastructure → Developers → Users → Transactions → Revenue → Incentives → More Developers
Sahara AI was exploring a different loop:
Developers → AI Assets → Consumers → Revenue → Developer Value → More AI Creation
The product question therefore became:
How do we make developers want to build valuable AI, rather than simply use our infrastructure?
The AI Ecosystem Flywheel
The key shift was from a traditional Web3 transaction model to an AI-driven creation loop: developers use Sahara infrastructure to create valuable AI assets, consumers use them, and the resulting value feeds back into developers and the ecosystem.
This helped frame the Developer Portal not simply as a developer tool, but as a key entry point into the AI ecosystem—connecting creation, distribution, consumption, and value.
The Design Opportunity
This changed how I thought about the Developer Portal.
A traditional developer portal optimizes for:
Documentation → API → Integration
Sahara's product needed to support a broader journey:
Discover → Build → Create → Release → Distribute → Capture Value
The Developer Portal therefore had to connect creation with what happens after creation.
Product Architecture
The Developer Portal is only the Application Layer
The underlying system was structured across four layers:
Application Layer
Sahara Agent · Sahara Toolkits · AI Marketplace · Sahara ID
The layer developers interact with.
↓
Transaction Layer
Sahara Blockchain
Records interactions and transactions.
↓
Data Layer
Data Storage · Data Access
Provides the data required by the ecosystem.
↓
Execution Layer
AI Execution Protocols · AI Execution Abstraction
Handles the execution of AI tasks.
The Design Problem
The architecture was technically complex.
But exposing the architecture directly would make the product harder to use.
A developer shouldn't have to think:
Application → Transaction → Data → Execution
every time they want to build something.
They should be able to think:
What do I want to build?
and let the platform handle the underlying complexity.
This became one of the core design principles:
Design around the developer's intent, not the infrastructure's architecture.
Designing the Developer Journey
From Developer Tool to Creator Platform
This led to an important product distinction.
Traditional Developer Portal
How do I use the API?
Sahara Developer Experience
What can I build, who can use it, and how does it create value?
The second question required the product to connect developer tooling with the broader Marketplace and ecosystem.
Designing the Creation Model
My Design Approach
03 — Data Services Platform
Designing for Enterprise Complexity
A multi-role, workflow-driven data platform
Data Services introduced another level of complexity.
Unlike a consumer product, the platform supported multiple roles working on interconnected processes.
Different Users. One System.
The Design Challenge
Different users interacted with the same underlying platform, but had very different goals.
This led to a fundamental design principle:
One platform does not mean one experience.
The experience needed to provide a shared system while adapting the interface, information, and actions to each role.
Make the System Visible
Complex systems can feel confusing when users cannot tell what is happening.
The interface therefore needed to make visible:
Current status
Progress
Ownership
Dependencies
Next actions
Data state
Progressive Disclosure
The platform contained complex capabilities, but exposing everything at once would increase cognitive load.
I used progressive disclosure to reveal complexity at the moment users needed it.
Complexity still exists. It just doesn't need to appear all at once.
04 — Design System
Designing the Infrastructure Behind the Products
As the number of products increased, solving individual UI inconsistencies one screen at a time was no longer scalable.
The organization needed shared design infrastructure.
The Design System
The system was structured across three levels.
One System. Multiple Product Types.
The Design System supported fundamentally different experiences:
Consumer
AI Marketplace
Developer
Developer Portal
Enterprise
Data Services
The goal was not to make every product look identical.
The goal was to make different products behave coherently.
Design System as Infrastructure
The system became a shared layer connecting:
Product
↕️
Design System
↕️
Engineering
It provided a common language across design and engineering while allowing individual products to maintain their own needs and contexts.
From Components to Patterns
A scalable Design System cannot stop at UI components.
Reusable product logic was equally important.
For example:
Navigation
Onboarding
Search
Data Management
Status
AI Interaction
These patterns could be reused across products without recreating the experience from scratch.
Governance
I also helped establish principles around:
Design quality
Design reviews
Pattern consistency
Documentation
Cross-product adoption
Design–Engineering collaboration
The objective was to make the Design System a living product infrastructure rather than a static component library.
05 — Brand & Product Experience
Connecting Brand to Product
A user's relationship with Sahara AI did not begin when they opened a product.
It could begin with:
Website
Campaign
Social Media
Event
Product Launch
Landing Page
That meant brand and product could not be treated as completely separate experiences.
Design Scope
My work across brand included:
Website
Product launches
Campaigns
Landing pages
Social media
Product storytelling
Visual identity
The goal was to create continuity between how Sahara AI was communicated and how it was experienced.
06 — Design Leadership
Building a Design Organization That Scales
As Sahara AI grew, my role evolved from individual product design toward design leadership.
I led an 8-person design team supporting:
Product
Platform
Brand
Marketing
Direction
I helped the team move beyond:
What screens do we need to design?
toward:
Why are we building this product, and what problem are we solving?
Quality
I established a broader definition of design quality across:
Product logic
User experience
Interaction
Visual quality
Scalability
A visually polished interface was not enough if the underlying product logic was unclear.
Collaboration
I worked across:
Product
Engineering
Business
Operations
Marketing
The role of design was to connect these functions rather than operate as a downstream execution team.
Design Review
Design reviews focused on five dimensions.
Problem
Are we solving the right problem?
Experience
Can users understand what is happening?
Logic
Does the product model make sense?
Scalability
Can the solution evolve with the product?
Quality
Does it meet the design standard?
Growing Product Thinking
A major part of my leadership role was helping designers move from:
UI / UX Execution
to:
Product Thinking
I encouraged the team to ask:
What problem are we solving?
Who are we solving it for?
Why does it matter?
Can it scale?
How does it connect to the ecosystem?
What I Built
A connected design ecosystem
My work at Sahara AI was not limited to individual product interfaces.
I worked across multiple layers of the organization.
Products
AI Marketplace
Discover AI.
Developer Portal
Build with AI.
Data Services
Create and contribute data.
Infrastructure
Blockchain
Record · Verify · Attribute · Trace
Design System
Shared language · Patterns · Infrastructure
Brand
Website · Campaigns · Launches · Social · Storytelling
From awareness to adoption.
Organization
8-person design team
Direction · Quality · Collaboration · Product Thinking