EASYBITS:
extractor web app
Designing for Complexity: The Data Extraction Platform That Put AI Pipelines in Customer Hands
Role:
Senior Product Designer
TIMELINE:
august - december / 2025
TOOLS:
Figma, FIgjam, Confluence
Overview
From Infrastructure to Self-Service Product
Easybits had powerful AI infrastructure capable of extracting structured data from virtually any document. But accessing it required direct involvement from the engineering team — there was no way for customers to build, test, or own their own pipelines independently. The Extractor App changed that.
My role: Solo product designer. Responsible for UX strategy, information architecture, interaction design, visual design, prototyping, and contribution to the Bits Design System. Working closely with Ivan Afonchenko (CTO/Tech Lead) in a design-led, engineering-informed process — weekly syncs, async Figma reviews, and continuous iteration shaped every major decision.
Timeline: May – December 2025
Over seven months, I designed a self-service platform that allowed insurance companies and other regulated industries to configure custom AI-powered data extraction pipelines, test them against real documents, and integrate outputs directly into their systems via API — all without writing a single line of code.
The core transformation: from engineering-dependent pipelines to customer self-service
Context & Origins
The Bottleneck Between Great Tech and Customer Access
Easybits was positioned as a secure, open-source AI-native data platform for regulated industries — insurance companies, consultancies, technology partners. Their core strength was building custom data extraction pipelines: feeding documents (PDFs, images, emails) into AI models and returning structured JSON outputs usable by any CRM or backend system.
The problem was access. Every new pipeline required direct engineering involvement. Sales calls were the only entry point. Onboarding was slow and manual. Potential customers who wanted to test the technology had no way to do it independently.
Two pressures converged to make this the right moment to build a self-service tool:
Sales Bottleneck
The team was generating around 5 demo calls per week but converting them required significant hands-on time from dev team. A self-service tool would let prospects validate the product themselves.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
The initial brief was straightforward: build an interface where users could configure a data extraction pipeline, upload a sample document, and get structured JSON output they could connect to their systems via API.
But underneath that simplicity was significant complexity:
01
Users would range widely
From technical developers integrating APIs to non-technical insurance operations staff who had never interacted with AI tooling.
02
The underlying technology was flexible but abstract
Users needed to define the exact data fields they wanted extracted, which required them to understand their own data needs before the tool could help them.
03
The output had to be reliable and consistent
Insurance companies and regulated industries could not afford unpredictable or malformed outputs.
03
There was no existing playbook
No competitor product existed that solved this in a way that felt approachable for non-developers.
Early discovery included reviewing the existing Easybits infrastructure with Ivan, mapping the technical constraints, and exploring how tools like OpenAI's API playground and Gemini's visual editor handled structured configuration — drawing inspiration without copying their complexity.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 1 - Mapping the Core Journey Before Any UI
The first step was getting the core user journey right before touching any UI. Using FigJam, I mapped the end-to-end flow:
1 - User creates an account (social sign-in)
2 - User uploads a sample doc & creates a new pipeline
The Cognitive Leap
3 - User defines the fields they want to extract
This step revealed an immediate tension: users had to define what they wanted before understanding what was possible. This became the central UX challenge of the entire project.
4 - System processes the document and returns extracted data
5 - User validates the output against their document
6 - User accesses the API endpoint to integrate into their system
7 - User sends real documents through the API for automated processing
This flow revealed an immediate tension: step 4 required users to think abstractly about their data before seeing any results. They had to define what they wanted before understanding what was possible. This became the central UX challenge of the entire project.
Early user flow validation sessions were run with colleagues and potential users to stress-test the logic before any UI was built — catching structural issues before they became expensive design problems.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 2 - From Tables to Contextual Configuration
Initial designs explored a table-based layout for field definition — rows and columns mapping document fields to extraction rules. It was familiar (spreadsheet-like) but felt cold and disconnected from the actual document being processed.
The pivot was to a single-view approach — keeping the document preview and field configuration in the same visual space, so users could look at their document and define fields simultaneously. This grounded the abstract configuration task in something tangible.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 3 - Making Nested Data Structures Human-Friendly
One of the most technically complex design challenges was representing nested data structures in a way non-technical users could understand.
Data extraction outputs are often hierarchical — an invoice might have a top-level date and vendor, but also a list of line items, each with their own name, quantity, and price. This is straightforward in JSON but deeply confusing to visualize in a UI.
Several approaches were explored and the final direction used color-coded indentation with a maximum of four nesting levels for the initial release — a deliberate constraint based on the insight that 60–70% of real use cases only needed flat or one-level-deep structures. Complex nesting was deferred until user behavior data could inform the right approach.
Data types were consolidated into three categories:
Primitives — strings, numbers, booleans
Objects — containers for multiple fields
Lists — arrays of consistent types[id41]
Ivan's discovery of Gemini 2.5's visual editor approach — a property name + type selection with a single array toggle — directly influenced how we simplified the type system, replacing two separate type paradigms with one unified system.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 4 - Building Trust Through Interactive Completeness
A consistent pattern throughout the project was ensuring interactive completeness — every clickable element needed hover states, every action needed feedback, every transition needed to feel intentional.
This led to a dedicated phase focused entirely on interactive states:
Dashboard cards with hover indication;
Menu items with selected and hover states distinct from each other;
Button states at 80% opacity on hover for consistency;
Toaster notifications for every successful action;
Toggle between JSON output and original document preview.
These weren't decorative — for a tool that asked users to trust AI with their business-critical documents, every moment of feedback was a trust signal.
Accessibility was a baseline requirement throughout. Color contrast ratios, keyboard navigation, and clear focus states were built into the design system components from the start — ensuring the Extractor met foundational WCAG standards without needing separate passes later.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 5 - Reframing API Integration as the Core Value
One deliberate design decision was how to present the API integration section. Early drafts treated it as a technical afterthought — a code block with an endpoint URL.
The reframe: the API section is the product's core value proposition. Without it, the Extractor is just a manual extraction tool. With it, it becomes automation infrastructure.
The final design presented the API endpoint prominently, with clear authentication token display, integration instructions, and a documentation page with left-side navigation and content area — structured to feel like a professional developer tool, not an afterthought.
Discovery & Brief
Understanding the Gap Between Simple Brief and Complex Reality
Step 6 - Contributing to and Building on the Design System
This app wasn't designed in isolation. It was built on and contributed to the Bits Design System — Easybits' component library developed in parallel across all products.
Every component built for the Extractor — pipeline cards, field mapping rows, JSON preview panels, interactive states, icon library — was documented and added to the design system, making future products faster to design and easier for developers to build consistently.
Components were built with accessibility baked in — contrast-compliant color tokens, consistent focus states, and semantic labeling — so every product inheriting from the system got these foundations for free.
The Extractor contributed [X] components and [X] variants to the Bits Design System. This bidirectional relationship (Extractor informs system, system informs Extractor) was intentional from the start and became one of the most valuable long-term contributions of the project.
Challenges & Pivots
Designing Under Pressure and Uncertainty
Challenge 1 - Designing for Ghost Users
For most of the design process, there were no real users to test with — only hypotheses about who would use the tool and how. The target ranged from insurance operations managers to developers at consultancy firms. Designing for both simultaneously meant avoiding assumptions that would alienate either.
The response was to design for progressive disclosure — simple entry points that didn't overwhelm beginners, with depth available for advanced users who needed it. The pipeline creation flow, for example, could start with a direct file upload or from a top-level dashboard view — both paths merging at field mapping.
Flow validation sessions with internal colleagues and early contacts helped pressure-test these assumptions before launch, catching edge cases in the entry point logic early.
Challenge 2 - The Fundamental UX Paradox
The nested data structure problem never fully went away. Even with color-coding and level limits, early validation sessions revealed that the concept of "defining what you want before you see what's possible" remained the hardest part of the experience.
The partial solution was adding sample document previews alongside configuration at all times, and designing a JSON/image toggle so users could constantly cross-reference their configuration against real output.
Full resolution of this challenge was deferred to post-launch iteration, informed by real usage data.
Challenge 3 - When Technical Constraints Become Design Features
Several engineering realities directly shaped design decisions. Rather than treating these as obstacles, each constraint became a design prompt — forcing cleaner, more deliberate solutions than an unconstrained brief might have produced.
01
Processing time up to 1 minute
Replaced progress bars with spinners and set user expectations through copy rather than false precision.
02
One example per pipeline
In early versions — designed the flow to make this feel intentional (focused testing) rather than limiting.
03
Nesting depth limits
Maximum 3 levels enforced at UI level by disabling nesting buttons at the third level, avoiding the need for complex overlay solutions.
04
Daily bot purging in dev environment
Led to the design of clear status indicators and save confirmations to prevent user data loss.
Challenge 4 - Shipping Smart Under Financial Pressure
The Extractor App was being built against a backdrop of company financial pressure and investor timelines.[id43][id50] This created constant tension between shipping fast and shipping right.
The response was a clear prioritisation framework agreed with Ivan: ship the flows that cover 60–70% of use cases first, defer edge cases, collect data before adding complexity.[id40] This discipline is visible in the final product — intentionally constrained in its first version, not because of lack of thinking, but because of deliberate restraint.
A FigJam or designed visual showing features plotted on a simple 2x2 matrix (impact vs complexity, or must-have vs nice-to-have). Mark which features shipped in v1 and which were deferred.
Impact
From Engineering Bottleneck to Self-Service Success
One of the most technically complex design challenges was representing nested data structures in a way non-technical users could understand.
Sales enablement
The tool gave the sales team a live, hands-on product to share with leads, shifting demos from presentations to real interactions.
Lead nurturing
Prospects could test the technology independently, accelerating qualification and reducing time-to-decision.
Investor narrative
Self-service usage data became a key part of the funding story, demonstrating product adoption beyond custom contracts.
Design System contribution
[X] components and [X] variants contributed to the Design System, reducing design and development time across subsequent products
Pipeline usage
[X] pipelines created, [X] API integrations completed in the weeks following launch (placeholder)
Reflection
Constraints as Design Tools
The Extractor App was the most technically complex product I worked on at Easybits — not because of the visual design, but because of the challenge of making genuinely abstract technical concepts feel approachable without dumbing them down.
The biggest lesson: constraints are design tools. The 3-level nesting limit, the 60–70% use case focus, the progressive disclosure approach — none of these were compromises. They were the design. Knowing what to leave out, and defending that decision, was as much a part of the work as knowing what to include.
Working as the sole designer in a fast-moving, engineering-led startup sharpened a skill I hadn't fully developed before: making design decisions stick under pressure. Without a design team to validate ideas internally, every decision had to be well-reasoned and well-communicated — to a CTO, to stakeholders, and to myself.
If I were to continue the project, the next phase would focus on onboarding — specifically addressing the core tension of asking users to define fields before seeing results. A guided first-run experience, or a template library of common extraction schemas, would dramatically reduce that initial cognitive load and accelerate time to first successful pipeline.