Designing a Confidential AI Platform
Designing a Confidential AI Platform
Designing a Confidential AI Platform
case study
interaction design
AI
AI conversational & infrastructure
2026
Making confidential AI understandable
Making confidential AI understandable
OODA was building a platform where AI workloads could run on distributed infrastructure with hardware enforced privacy. Behind the experience were complex systems for confidential execution, verification and compute management.
OODA was building a platform where AI workloads could run on distributed infrastructure with hardware enforced privacy. Behind the experience were complex systems for confidential execution, verification and compute management.
My role was to turn that complexity into usable products.
My role was to turn that complexity into usable products.
As the sole Product Designer, I worked alongside Product and Engineering to design five interconnected product surfaces in three months, from conversational AI to infrastructure workflows, while establishing a shared design system.
As the sole Product Designer, I worked alongside Product and Engineering to design five interconnected product surfaces in three months, from conversational AI to infrastructure workflows, while establishing a shared design system.
The challenge was not to explain every technical detail. It was to understand which details mattered to each user, and when.
The challenge was not to explain every technical detail. It was to understand which details mattered to each user, and when.
01
The conversational Interface : Private AI
The conversational Interface : Private AI
For someone asking a question, confidential AI should not feel more complicated than any other assistant.
For someone asking a question, confidential AI should not feel more complicated than any other assistant.
I designed PrivatAI around familiar conversational patterns, from starting a conversation and attaching documents to managing messages and accessing previous interactions. The underlying infrastructure was complex, but using it did not need to be.
I designed PrivatAI around familiar conversational patterns, from starting a conversation and attaching documents to managing messages and accessing previous interactions. The underlying infrastructure was complex, but using it did not need to be.
Welcome
Draft
Attachment
Voice Input
Preparing
Generating
Complete
A simple starting point introduces the selected assistant and helps users begin a conversation without unnecessary complexity.
Welcome
Draft
Attachment
Voice Input
Preparing
Generating
Complete
A simple starting point introduces the selected assistant and helps users begin a conversation without unnecessary complexity.
DESIGN DECISION
How much of the infrastructure should users need to understand?
Very little when they are simply trying to get something done. I kept the conversation familiar and the technical complexity out of the primary flow, while allowing users to access relevant information when needed.
DELIVERY
What did I bring together?
I designed the composer, document attachments, conversation history and message controls as one connected experience, using shared interaction patterns across the main conversational flows.
DELIVERY
Could privacy become another barrier?
The infrastructure offered a different approach to protecting sensitive data, but introducing technical concepts too early risked making a familiar task feel unnecessarily difficult.
DECISION
What should remain familiar?
The composer, message history, attachments and conversation controls. I used established interaction patterns so users could focus on their requests rather than learning a new interface.
DECISION
What should remain familiar?
The composer, message history, attachments and conversation controls. I used established interaction patterns so users could focus on their requests rather than learning a new interface.
LIMITATION
Can a familiar interface explain confidentiality?
Not by itself. A simple interface makes the product easier to use, but users still need a way to examine what the infrastructure can actually verify.
LIMITATION
Can a familiar interface explain confidentiality?
Not by itself. A simple interface makes the product easier to use, but users still need a way to examine what the infrastructure can actually verify.
02
Pal Selection
Pal Selection
Most people know what they need help with. They do not necessarily know which language model is best suited to the task.
Most people know what they need help with. They do not necessarily know which language model is best suited to the task.
I designed the Pal selection experience around what each assistant could help users accomplish. Each Pal had its own purpose, capabilities and scope, giving people a way to choose based on their task rather than model specifications.
I designed the Pal selection experience around what each assistant could help users accomplish. Each Pal had its own purpose, capabilities and scope, giving people a way to choose based on their task rather than model specifications.
Welcome
Browse Pals
Pal Details
Select Pal
Pal Selected
The Pal selector in the composer allows users to choose a specialised assistant based on what they want to accomplish.
Welcome
Browse Pals
Pal Details
Select Pal
Pal Selected
The Pal selector in the composer allows users to choose a specialised assistant based on what they want to accomplish.
design decision
Should people choose a model or describe what they need?
I made the task the starting point.
Selecting a Pal gives users a more familiar way to approach AI, without making model specifications the first decision they encounter.
DECISION
How do you make each Pal understandable?
By defining its purpose, expected behaviour and scope. The distinction between assistants should come from what they help users accomplish, not simply their names or personalities.
DECISION
How do you make each Pal understandable?
By defining its purpose, expected behaviour and scope. The distinction between assistants should come from what they help users accomplish, not simply their names or personalities.
trade off
Does hiding model selection remove useful control?
Potentially. Task based selection simplifies the first interaction, but experienced users may still want to choose a specific model. The challenge is deciding when that control becomes useful.
trade off
Does hiding model selection remove useful control?
Potentially. Task based selection simplifies the first interaction, but experienced users may still want to choose a specific model. The challenge is deciding when that control becomes useful.
limitation
What if someone's task does not fit a category?
Real requests rarely follow perfect boundaries. A specialist assistant needs a clear purpose without implying that every question belongs neatly to one Pal.
limitation
What if someone's task does not fit a category?
Real requests rarely follow perfect boundaries. A specialist assistant needs a clear purpose without implying that every question belongs neatly to one Pal.
03
The Explorer
The Explorer
Confidential execution produces technical verification information. But a cryptographic attestation means little to someone who does not work with this technology.
Confidential execution produces technical verification information. But a cryptographic attestation means little to someone who does not work with this technology.
I designed the Explorer around the idea of an audit trail rather than a conventional blockchain explorer. The aim was to make verification records easier to find, interpret and inspect without removing the underlying technical detail.
I designed the Explorer around the idea of an audit trail rather than a conventional blockchain explorer. The aim was to make verification records easier to find, interpret and inspect without removing the underlying technical detail.
View Verification
Block Details
How It Works
Once a response is complete, users can open its associated verification record in OODA Explorer without cluttering the conversation with technical details.
DESIGN DECISION
What does verification actually mean to the user?
A transaction identifier alone does not explain much.
I organised the experience around the verification result, the associated activity and the information needed to examine the underlying evidence.
decision
What should people see first?
The outcome of the verification and the context surrounding it. More technical information remains available for people who need to investigate further.
decision
What should people see first?
The outcome of the verification and the context surrounding it. More technical information remains available for people who need to investigate further.
trade off
How far can technical language be simplified?
An attestation has a specific meaning. Making it readable should never involve changing what it proves or suggesting guarantees beyond the underlying technology.
trade off
How far can technical language be simplified?
An attestation has a specific meaning. Making it readable should never involve changing what it proves or suggesting guarantees beyond the underlying technology.
trade off
How far can technical language be simplified?
An attestation has a specific meaning. Making it readable should never involve changing what it proves or suggesting guarantees beyond the underlying technology.
LIMITATION
What cannot be verified?
Evidence about the execution environment is not evidence that an AI generated answer is factually correct. The interface needs to preserve that distinction.
LIMITATION
What cannot be verified?
Evidence about the execution environment is not evidence that an AI generated answer is factually correct. The interface needs to preserve that distinction.
04
Compute Providing
Compute Providing
Sharing compute involves more than connecting a computer. Users need to understand which models they can provide, when their machine is available to the network and how their contributions translate into earnings.
Sharing compute involves more than connecting a computer. Users need to understand which models they can provide, when their machine is available to the network and how their contributions translate into earnings.
At OODA, I initially prototyped a worker connection and contribution tracking experience. I later revisited the concept to explore a clearer desktop workflow, from configuring models and activating compute sharing to monitoring activity and earnings. The screens below represent this retrospective refinement, not a released feature.
At OODA, I initially prototyped a worker connection and contribution tracking experience. I later revisited the concept to explore a clearer desktop workflow, from configuring models and activating compute sharing to monitoring activity and earnings. The screens below represent this retrospective refinement, not a released feature.
Welcome
Configure
Activate
Available
Processing
Limited
An introduction to compute sharing, explaining how users can contribute their computer's resources, the requirements for participation and how earnings are generated.
Welcome
Configure
Activate
Available
Processing
Limited
An introduction to compute sharing, explaining how users can contribute their computer's resources, the requirements for participation and how earnings are generated.
DESIGN DECISION
How do you make compute sharing understandable without hiding how it works?
I structured the experience around distinct decisions and system states: model selection, sharing permissions, security verification, availability and active processing.
Rather than treating connection as a single successful step, each stage makes it clear what the user has enabled, what the system has verified and what the computer is actually doing.
DESIGN DECISION
How do you design for two very different audiences?
By keeping the design language consistent without forcing the same information hierarchy onto everyone.
The conversational product prioritised accessibility. The provider experience needed operational clarity and access to technical detail.
problem
When does connected actually mean working?
A computer can be connected and available without processing any requests. I separated Available, Processing and Limited to make that distinction visible, so users do not confuse network readiness with active work or guaranteed earnings.
problem
When does connected actually mean working?oes simplification become a problem?
A computer can be connected and available without processing any requests. I separated Available, Processing and Limited to make that distinction visible, so users do not confuse network readiness with active work or guaranteed earnings.
problem
When does connected actually mean working?oes simplification become a problem?
A computer can be connected and available without processing any requests. I separated Available, Processing and Limited to make that distinction visible, so users do not confuse network readiness with active work or guaranteed earnings.
decision
What should users control before sharing compute?
The setup lets users select installed models, define which organisations can send requests and explicitly activate compute sharing. Security eligibility is communicated separately, while the option to stop providing remains accessible.
decision
What should users control before sharing compute?
The setup lets users select installed models, define which organisations can send requests and explicitly activate compute sharing. Security eligibility is communicated separately, while the option to stop providing remains accessible.
trade off
How much technical detail is actually useful?
I prioritised model availability, live activity, completed requests and verified earnings over advanced infrastructure metrics. The interface provides enough detail to understand contributions and make decisions without turning a single computer workflow into a complex operations console.
05
What OODA Taught Me
What OODA Taught Me
Designing across different needs
Designing across different needs
OODA reinforced how much product design happens before the interface takes shape.
OODA reinforced how much product design happens before the interface takes shape.
The same underlying infrastructure served people asking everyday questions, users looking for verification evidence and operators managing compute resources. Each needed a different level of technical understanding.
The same underlying infrastructure served people asking everyday questions, users looking for verification evidence and operators managing compute resources. Each needed a different level of technical understanding.
What connected the work was not a single interface pattern, but a consistent approach to deciding what information belonged in front of each user.
What connected the work was not a single interface pattern, but a consistent approach to deciding what information belonged in front of each user.
One design system, five product surfaces
One design system, five product surfaces
As the sole designer, I had to establish shared foundations while designing the products themselves.
As the sole designer, I had to establish shared foundations while designing the products themselves.
I built a common design system across five interconnected experiences and used working prototypes to explore interaction details with Product and Engineering before development.
I built a common design system across five interconnected experiences and used working prototypes to explore interaction details with Product and Engineering before development.
Consistency mattered, but so did flexibility. A component should be reused because it solves the same interaction problem, not simply because it already exists.
Consistency mattered, but so did flexibility. A component should be reused because it solves the same interaction problem, not simply because it already exists.
What I'd revisit
What I'd revisit
There are still questions I would want to investigate further:
There are still questions I would want to investigate further:
How much technical information do users need before they feel comfortable trusting a confidential AI service?
Does selecting an assistant by task help people make better choices, or does it introduce new ambiguity?
Can people interpret verification results correctly without specialist knowledge?
Where this led
Where this led
The conversational work on OODA raised further questions about how interfaces handle unpredictable AI behaviour.
The conversational work on OODA raised further questions about how interfaces handle unpredictable AI behaviour.
I explored those questions separately, looking more closely at response generation, latency and the limits of AI generated answers.
I explored those questions separately, looking more closely at response generation, latency and the limits of AI generated answers.
That independent study builds on the questions I encountered at OODA, but its prototypes are not presented as features delivered within the product.
That independent study builds on the questions I encountered at OODA, but its prototypes are not presented as features delivered within the product.
UX EXPLORATION
AI
Q1 2026
Designing for LLM Behaviour
How should an interface behave when AI responses arrive progressively, take longer than expected or lack sufficient evidence?
UX EXPLORATION
AI
Q1 2026
Designing for LLM Behaviour
How should an interface behave when AI responses arrive progressively, take longer than expected or lack sufficient evidence?
Raphaël.D
Senior UX & Product Designer
Pages
© 2026 Raphaël.D. All rights reserved.
Raphaël.D
Senior UX & Product Designer
Pages
© 2026 Raphaël.D. All rights reserved.
Raphaël.D
Senior UX & Product Designer
Pages
© 2026 Raphaël.D. All rights reserved.