Document Detail Design for an AI IDE.

Product Immersion and AI Learning

Before designing anything, I spent a significant amount of time understanding the product and the underlying AI concepts behind it.

AI agent workflows rely on complex terminology and logic. To design responsibly, I had to learn concepts such as embeddings, chunking, and retrieval flows almost from scratch. This phase was essential. Once I had a clear mental model of how the system worked, I could design in a much more structured and intentional way.

Without this foundation, any UI decision would have been arbitrary.

Competitive Research

I reviewed both direct and indirect competitors, including tools like Airbyte (especially around ingestion and setup flows), LangSmith (for evaluation patterns), Latitude, and others.

Rather than focusing on visuals, I analyzed how these products handle external data sources, guide users through complex configuration, and present dense information without overwhelming the user.

This helped me identify common patterns, user expectations, and recurring points of confusion that I wanted to avoid.

Architecture and Low-Fidelity Thinking

I started by defining the core structure of the system: Sources → Collections → Documents.

I first built a sitemap that represented the full structure of the knowledge base. This gave me a foundational understanding of everything this area of the IDE needed to include and how, at a high level, all parts connected to each other.

User Flow

Once I had a rough idea of the content, I started mapping the paths users would follow for the main actions within each primary section. I created simple user flows to help me define what I would later need to build.

Wireframing

Once the structure felt solid, I translated these ideas into wireframes. The focus here was not visual polish, but hierarchy, layout, and relationships between elements. This step helped confirm that the system made sense before committing to styling decisions.

High-Fidelity Design and Visual Direction

To move quickly while staying grounded, I decided to use Shadcn components and adjust their tokens to achieve a clean and visually appealing result.

Given the two-day constraint, I prioritized visual clarity and overall impact over technical cleanliness. This resulted in trade-offs such as detached styles, font overrides, and potential accessibility gaps. In a real production environment, these would be cleaned up and systematized.

I also chose to validate the visual direction specifically on the Document Detail view. While other flows involved more navigation, this view represented the greatest design challenge, as it required organizing high information density while maintaining clarity and ease of use.

Solving this view well set the foundation for the rest of the system.

To design this, I defined a main content area divided into all the necessary functional spaces:

• Chunks, showing all document segments along with their scores, tokens used, previews, and related metadata.
• Preview, allowing the full document to be read quickly.
• Evaluations, displaying all evaluations grouped by type: human-in-the-loop, LLM-as-a-judge, or programmatic rules.
• Activity, providing full visibility for compliance and auditing purposes, including edits, views, and changes.

In addition, the experience is complemented by a right-side panel inspired by tools like Linear or Notion. This panel allows users to inspect detailed document information, including core properties, a timeline of recent changes, retrieval accuracy metrics, and the collections and agents linked to each document. All elements are fully clickable and navigable.

Prototyping

I created a basic interactive prototype focused on component behavior, states, and navigation. It does not cover every edge case, but it demonstrates the main happy path and how the system is intended to be used.