Dockit • Events & Requests
Dockit is an internal application that supports case managers in handling claimant data, medical record requests, and case preparation for litigation. “Events & Requests” is a redesigned workflow that consolidates legacy tools to streamline how users collect and act on claimant-provided information.
Type
Case Study
Timeframe
3 weeks
Toolkit
Figma, FigJam, Thoughtspot Analytics
Year
2024
Problem
Dockit’s Medical Events and Document Requests workflows were tightly connected but existed in separate areas of the UI, with no shared interaction model. Users had to toggle between screens to reference event data and create accurate document requests, increasing cognitive load, manual tracking, and the risk of delays or errors. This fragmentation slowed record retrieval, a critical step in proving legal claims, costing time, money, and trust.
Solution
We merged Medical Events and Document Requests into a single, contextualized workflow that keeps data input and actions closely aligned. The redesign reduces errors and support burden, accelerates accurate document requests, and scales across different lawsuit types.
Understanding the Project Goals
Business Goals
Reduce time to create accurate, complete document requests
Decrease internal errors and support burden caused by toggling
Improve scalability across different lawsuit types
UX Goals
Merge both tools into one seamless, contextualized experience
Preserve clarity between data input and action, while improving proximity
Allow flexibility for diverse data types and request workflows
Clean up the UI for better readability and focus
My Process
As a core designer on this initiative, I worked closely with the other product designer, the PM, and engineers to fully understand the problem space.
Stakeholder Input
We spoke with operations specialists who use Dockit daily, gathering key pain points and workflow examples
Understanding how both userflows work independently of one another today.
Legacy Code Audit
Collaborated with engineers to understand which components could be reused vs. needed rework, and which areas would need check-ins to confirm feasibility due to legacy code.
Takeaways:
Medical Events
Where internal users logged specific information given by claimants—such as facility visits, medication usage, job history, etc.—to build a case profile.
Document Requests
Where users acted on those events to request official records from medical providers, employers, or other third parties.
Given that record retrieval is critical to proving legal claims, this inefficiency was costing time, money, and trust.
Key Design Decisions
Organized by Facility
Events and Requests are grouped by facility to reflect how requests are handled operationally
Claimants often visit multiple locations for treatment. This structure helps retrieval specialists stay organized
Stacked Layout: Events Above Requests
Each facility section displays Events first
Below is a Requests table showing what’s been sent.
This reinforces the cause and effect logic: Add Events → Send Request
Event Details in a Drawer
Clicking an event opens a right-side drawer
Drawer shows a structured, read-only summary of injury, facility, physician, care type, and notes
Event status is clearly marked (“Ongoing”, “Ready for Request”, “Complete”)
Dual Action Path
Users can:
Add new Events
Send Requests directly from the table
Enables flexibility and reduces unnecessary navigation
Scalable Table Design
High-level overview in tables for scanning
Deeper detail on demand in drawers
Future-proofed to support additional metadata
Outcomes
Improved Workflow Efficiency
Users can complete the end-to-end task in one place, reducing toggling and rework
Cleaner Handoff to Operations
Better event/request linkage reduced back-and-forth communication internally
Positive Team Feedback
Operations team members noted how much easier it was to manage cases without jumping screens.
“This makes my life so much easier”
Scalability Win
The new layout structure is extensible for future case types
Engineers were able to preserve important legacy logic while benefiting from a restructured interface
