Work
About
Let’s Talk!
Back to all work
Lead designer
Sefaria Library Assistant
Reframing an AI assistant as a learning layer within Sefaria's reading experience, and discovering the real design problem wasn't the assistant at all.
Role
Product Designer, contract
Duration
6 months
Type
AI Product · UX Research · Nonprofit
Tools
Figma
FigJam
Figma Make
ChatGPT
Claude
The . brief
Sefaria is one of the most trusted Jewish text libraries in the world. When I joined on contract, the organization was under board pressure to ship an AI assistant, and they needed someone to figure out what that actually meant. There were no designs. No prior research. And until recently no product designer, the work had been carried by a graphic designer whose instincts had taken the product far, but the product had grown beyond what instinct alone could support.
My job was to build the foundations.
The . tension
Starting with users, not features
When I arrived, the conversation was: how do we make this look like a mature, polished AI experience? The focus was on UI details and feature capabilities. There was pressure from the board, stress in the organization, and a strong pull toward shipping something that felt competitive with other AI products.
Nobody had actually spoken with users yet.
I pushed for a research phase before any design work began. The PM understood immediately and backed me fully. I didn't wait for formal permission, I built the research plan, wrote the scripts, found participants myself, and looped in marketing for contacts.
Research was not originally part of the plan. I advocated for incorporating it early, and the findings ultimately influenced both the product direction and several MVP decisions.
Throughout the project I kept bringing conversations back to user behavior. When discussions drifted toward feature parity with other AI products, I redirected toward what we'd heard from users. When there was pressure to move quickly on onboarding, I pushed for simpler interventions grounded in what was actually causing confusion. The research gave us a shared language for those decisions.
Research findings
11 interviews. 3 findings that changed everything.
Taking what I learned from my research, combined with my understanding of the product and team priorities, I synthesized repeated patterns from interviews and survey responses. Referring back to these findings helped me stay aligned with user goals throughout the design process.
01
Trust comes from Sefaria, not from AI
Users weren't adopting the assistant because it was impressive AI. They were trying it out because they trusted Sefaria. One participant said he trusted it more than any other AI tool, because its sources came from Sefaria's library. That's the differentiator.
02
Users saw it as a study tool, not a chatbot
Users weren't just looking for answers, they were reading, verifying, gathering sources, and continuing their learning. This drove almost every major design decision: source links, readability, docking, onboarding, and future thinking around source sheets.
03
Nobody knew it was beta
Multiple users couldn't calibrate their expectations because the product wasn't communicating its own status. Their trust in Sefaria extended to the assistant, which made any AI errors feel more surprising than they should have.
Therefore
These findings pointed to the same conclusion: users weren't looking for a chatbot. They were looking for something that understood how people actually study. The assistant needed to behave like a learning layer, grounded in Sefaria's texts, embedded in the Reader, and designed for the way people actually use it.
The reframe
From "look like AI" → "behave like Sefaria"
The research shifted the product direction in two concrete ways. First, the design language, copy, and interaction patterns needed to feel like a natural extension of a trusted library, not a generic chat product. Source links became the core trust mechanism, not a nice-to-have.
Second, the assistant wasn't a standalone product. It lived inside Sefaria's Reader. And that realization became the most important design insight of the project.
Parallel workstream
While designing the assistant, I was also helping mature the design foundations and token structure. This meant cleaning up inherited variables, introducing semantic tokens, and establishing module-specific modes so new AI surfaces could integrate consistently with the broader product rather than become a one-off surface.
The core insight
It wasn't an assistant problem. It was a Reader problem.
The Reader is Sefaria's primary reading experience, where users engage with texts, translations, commentaries, and sources for extended periods. Adding an AI assistant might seem like simply placing a panel beside the text. In practice, introducing a persistent secondary workspace forced us to reconsider how the Reader itself should behave.
Once the assistant was docked, horizontal space had to be shared. Simply compressing the layout made long-form reading uncomfortable. This led to broader questions: When should docking be available? At what screen widths does it harm the reading experience? What content should always stay prioritized?
The project shifted from 'where do we put the AI panel?' to 'how should a reading environment behave when AI becomes part of it?'
This realization influenced every major interaction decision that followed, panel sizing, breakpoint rules, docking behavior, resizing constraints, and content prioritization.
Left: floating mode below 1280px. Right: docked mode at 1280px and above.
What I designed
Interaction design across the full assistant experience
Supporting different learning behaviors
Floating vs Docked panel behavior
Users needed flexibility, some wanted a persistent workspace while reading, others wanted something lightweight and temporary. Rather than forcing a single model, I designed both floating and docked experiences, with a 1280px breakpoint determining when docking became available. Below that threshold, forcing a docked state would have compressed the Reader to the point of breaking the reading experience.
Below
1280px
Above
FLOATING
Below 1280px
Library Assistant
Reader uses full width. The assistant floats as an overlay, lightweight and temporary. Docking is hidden below this threshold because compressing the Reader would break the reading experience.
DOCKED
1280px and above
Library Assistant
Reader and assistant share horizontal space.
Reader and assistant share horizontal space. Docking becomes available, the assistant is persistent and integrated, supporting side-by-side study without overlapping the text.
Panel resizing behavior
Constraints and resize rules
The panel is anchored to the bottom-right of the viewport, right and bottom edges never move. Users resize by dragging the bottom-left handle, expanding the panel left and upward. This directional constraint protects the reading surface while giving users meaningful control over how much space the assistant occupies.
VIEWPORT
Library Assistant
~560px
content
max width
Ask a question...
expands left
expands upward
Resize handle
bottom-left
Anchor
bottom-right
fixed
CONSTRAINTS
Min width
300px
Max width
720px
Min height
456px
Max height
80vh
At max height
Message area scrolls
panel stays in viewport
Calibrating trust and expectations
Onboarding and welcome states
I distinguished between 3 distinct entry states: first-ever open, new session, and post-restart, each needing different copy and a different level of cognitive load. The beta clarity finding from research directly shaped this work, I explored low-effort tooltip walkthroughs and onboarding patterns that could set expectations without requiring heavy engineering lift.
Various explorations to help both onboard the user and demonstrate usage
Preserving readability during long-form study
Response layout and content constraints
Constrained message content to ~560px at maximum panel width. Long line lengths reduce readability, especially for explanation-heavy, source-heavy, multilingual responses. I also considered hierarchy carefully, after submission, the AI response is the primary reading material, not the user's original prompt.
Library Assistant
✦ AI
~560PX MAX CONTENT WIDTH
UNUSED PANEL SPACE
↔ Content constrained even at max panel width — long lines reduce readability
At maximum panel width, response content is constrained to ~560px. Additional width becomes empty space , preserving comfortable reading.
Supporting exploration without losing context
Restart, stop generation, and feedback
Designed a lightweight confirmation popover for new chat, clear enough to prevent accidental conversation loss, light enough not to interrupt the learning flow. The Send button converts to Stop during generation, with partial content preserved and the composer rehydrated so users can edit and resend. Thumbs up/down with hover tooltip labels and clear post-click states.
Library Assistant
↑ anchored to overflow menu
Start a new chat?
This will clear the current
conversation.
Cancel
Start new chat
Popover anchors to the overflow menu — keeping the interaction close to its source. Clearing a conversation is potentially destructive so it deserves confirmation, but a full modal would feel too heavy for a learning context.
Tradeoffs and constraints
Real decisions made under real constraints
Flexibility over simplicity
Users wanted different ways to interact with the assistant, some preferred a persistent workspace, others something lightweight. Rather than forcing a single model, we designed both floating and docked modes. That decision cascaded into breakpoint rules, resizing logic, and a rethink of the Reader layout.
Trust before feature breadth
Rather than shipping every expected AI feature, we focused on source grounding, readability, and onboarding first. The research told us trust was the differentiator, so we protected it, even when that meant a smaller MVP.
Deferring what we knew users wanted
Copy, export, and source sheet creation emerged clearly from research as high-value future features. Engineering constraints made them unrealistic for launch. We shipped the foundation and documented the direction, so the next phase had somewhere to build from.
Outcomes
What shipped...and what’s next
Shipped @ MVP
Library Assistant in the Reader
Floating + docked panel
Onboarding + welcome states
Restart + stop generation
Feedback controls
Response readability system
In progress
Hebrew string support
(currently shipping)
Research findings influenced multiple MVP decisions before launch. Source grounding became a core design principle rather than a secondary consideration. The interaction patterns established for floating, docking, resizing, and onboarding created a foundation for future AI work within the Reader. And the thinking around source sheets, saving, and learning workflows is already informing post-MVP direction.
What I wish I had time to tackle next
These themes kept coming up in research and kept coming up in conversations with the team. They weren't cut because they were unimportant. They were deferred because trust had to come first. But they represent the next natural layer of the product:
Source sheet integration
Users repeatedly asked when they could turn assistant responses into source sheets. That workflow would connect the assistant directly to one of Sefaria's most loved features and deepen the learning-layer thesis significantly.
Save and share workflows
Copying, exporting, and sharing responses with a chavruta were among the most requested features. Building those would shift the assistant from a query tool to a genuine study companion.
Contextual onboarding and guidance
The beta clarity finding points to a bigger opportunity: an onboarding system that surfaces capabilities in context rather than upfront. Suggestion chips, progressive disclosure, and text-aware prompts could all help users understand what the assistant can do without front-loading cognitive load.
Reflection
Designing AI inside an existing product is less about adding chat and more about fitting intelligence into existing user workflows. In a knowledge product, answer quality is only one part of trust, source grounding and verification paths matter just as much.
And sometimes the most valuable thing a designer can do is stop the conversation, go talk to users, and come back with a better question.
Back to all work