SixFifty · 2026
AI Interaction Framework
A documented system for how AI shows up across the SixFifty product. Four surfaces, one rule for how they connect.
- Tags
- AI · Framework · Design System
The problem
AI features were getting bolted on left and right. Different teams were solving the same UX questions in different ways, and there was no central place that defined what we should be using when. Some of it was fine. Some of it was the worst possible version: heavy AI overlays that covered the content the user was actually trying to work with.
Nobody had a map of what AI looked like in the product, and we were about to need one badly. SixFifty is in the middle of becoming a fully AI-driven HR platform. You can’t make that transition if you can’t even agree on what an “AI feature” looks like in your own UI.
I just started writing it
Nobody asked me to do this. I saw the chaos coming and figured someone needed to put a stake in the ground before AI patterns got even more fragmented. It started as a Figjam I jotted down between other work, and it kept getting longer because the gaps kept getting more obvious.
The framework defines four AI surfaces. That’s it. It’s deliberately not about loading states, streaming, error handling, or any of the deeper interaction mechanics. It’s about where AI shows up. Once you know which surface a feature belongs in, the rest of the design conversation gets ten times easier.
The four surfaces
The framework is exactly four surfaces, ordered from lightest to heaviest. Each has a clear job. Once you know which surface a feature belongs in, the rest of the design conversation gets ten times easier.
Inline AI
The smallest surface. Lives directly inside an existing UI element. Used for atomic actions like rename or reorder, where the AI is doing one thing on one piece of content and then getting out of the way. No new real estate, no context switch.
Banner AI
A search-style bar that sits at the top of the site. The entry point. A user types intent into the bar, and the bar kicks off whatever agent is needed. It almost always opens a sidecar from there. Think of it as the door, not the room.
Sidecar
Slides in from the side and pushes the page content rather than covering it. Conversational. This is where most agent work actually happens. The user can keep working with the rest of the app while the sidecar is open, and they can expand it to fullpage if the task gets bigger.
Fullpage
The ChatGPT-style experience. Center conversation, left and right rails for tasks, generated documents, and history. Used when the AI conversation is the task, not a side concern.
How they connect
There’s one rule for how the surfaces relate.
Bars open sidecars. Sidecars open windows.
The escalation rule
That’s the whole escalation logic. A user starts in the lightest surface (a Banner) and only moves to a heavier one (Sidecar, then Fullpage) as the task gets bigger. The framework isn’t just four boxes sitting next to each other. It’s a path.
What I cut
The product had a bunch of overlay-style AI surfaces that covered the content underneath. Those went. If a user is trying to work on something, you don’t get to slap an opaque AI panel on top of it and call it helpful. Pushing content (sidecar) or replacing it (fullpage) respects what the user is doing. Covering it doesn’t.
That cut alone tightened the rest of the framework. Once “drop a panel on top” is off the table, you’re forced into clearer choices about where AI actually belongs.
Where it lives now
The whole thing is a Figjam doc right now. Stakeholder feedback is open, and I’m waiting on the round of reviews that turns this from a one-person opinion into the team’s shared reference.
Nothing has shipped using the framework yet, but it’s the basis of the entire new AI platform we’re building at SixFifty. Every AI feature that comes after this is going to land in one of these four surfaces and follow the bars-to-sidecars-to-windows path. That makes this document the load-bearing piece for a lot of upcoming work.
Why I did this without being asked
The honest answer is that documentation like this rarely gets prioritized until the lack of it has already cost a team six months. By the time someone says “we need a framework for this,” the inconsistency is already shipped, and now you’re writing the doc and untangling the mess at the same time.
I’d rather write the doc first.
Next case study
Design System
Built a 50+ component design system from scratch. Figma library, tokenized React components, and a working bridge between design and engineering.