Role: Lead Product Designer
Company: Steadi Technologies
Timeframe: September 2025 - January 2026
Steadi.ai is an AI-enabled freight spend and workflow platform designed to help freight and transportation operators gain control over their budgets and modernize fragmented supply chains. It acts as a unified system of action, bridging data and insights to specific workflows to prevent cost slippage. When I joined, the platform was a few months out from its initial go-to-market date. Core functionality like a digital route guide and basic ticket management was in place, but the experience felt cumbersome and it was becoming clear that the product didn't yet fully match the operational mental models of the people it was built for. Before the platform could find traction with users, it needed to feel intuitive to them.
The strategic problem ran deeper. Steadi’s vision depended on AI-powered insights sitting on top of routing data, but the platform lacked the semantic structure to make that possible. Without clear status definitions, consistent terminology, and workflows that generate labeled data, an AI layer would have nothing meaningful to reason about. The work required building that foundation without losing sight of the more immediate problem: making the product something teams would actually use.
Impact 1: Information Architecture as AI Infrastructure
The Problem
Limited filtering, no meaningful sorting, and no ability to customize views meant operators couldn’t surface what was relevant to them. Beyond usability, this meant the system had no structured way of representing what “relevance” even meant, which is exactly the concept an AI layer needs to understand.
The Design Decision
After conducting interviews and monitoring usage, the filtering and sorting architecture was redesigned so operators could customize their own views and create saved filter groups. This was a foundational architecture decision rather than a feature addition. Every filter selection, saved view, and sort preference now generates structured signal about what matters to that user in that context. This unlocked a meaningful schema that the AI layer will use to contextualize recommendations, understanding not just what a lane looks like but what the operator considers important about it.
Why It Matters
When an operator eventually asks the AI, “What carriers can cover this lane?”, the system immediately references the operator's mental model: what filters they typically use, what lanes they prioritize, what patterns define their workflow. The filtering architecture built doesn’t just help users find things faster; it teaches the system what “relevant” means for each user.
Impact 2: Ticketing Workflow and Status Architecture
The Problem
The workflow for initiating, assigning, approving, and closing changes to the routing guide was disjointed. Users didn’t know what state their work was in, who was blocking progress, or what needed to happen next. Inconsistent terminology made it impossible for the system to reliably label the state of any given issue.
The Design Decision
This required a comprehensive rethinking of the ticket workflow: establishing a ubiquitous language for statuses, defining when and why issues transition between states, and designing assignment and approval logic. Contextual work buckets were introduced. Views that surface only actionable items depending on the current phase of work, were created so users see what’s relevant to their next action. The multi-actor workflow supports distinct roles: the person who opens a ticket, the assignee, the approver, and the implementer.
Why It Matters
Every status label and transition becomes a data point the AI can use to match current problems with historical patterns. The status architecture creates the semantic layer that lets the AI triangulate what’s relevant and offer optimization advice. Without this structure, the AI has nothing meaningful to reason about.
Impact 3: Detail Page Redesign and Decision Support
The Problem
The ticket detail page, the primary workspace where operators evaluate what needs to be done and take action, was cluttered and poorly structured. Key information was buried, primary actions weren’t prominent, and the page surfaced no contextual intelligence: no similar past issues, no related changes, no decision support.
The Design Decision
I restructured the detail page to lead with the proposed change and its rationale, followed by clear primary actions. I introduced a similar-issues feature that surfaces past tickets where comparable changes had been made, helping operators recognize patterns and avoid duplicate work. I also integrated the initial AI chat interface alongside the workspace, allowing operators to query the system about alternative carriers, lane coverage, and historical context without leaving their workflow.
Why It Matters
This is where the AI layer becomes tangible to users. By embedding decision support directly into the task context, the platform shifts from a system of record to a system of intelligence. The similar-issues feature and AI chat are only as good as the underlying data architecture , which is exactly what the filtering, status, and workflow work made possible.
Impact 4: Team Architecture, Notifications, and Scalability
The Problem
There was no meaningful team management, no notification system, and no ability for users to manage preferences across different teams. The system had no mechanism for understanding role-based context, such as which team a user was operating in, what notifications they should receive, or how responsibilities varied across teams.
The Design Decision
Team management and individual preference pages were designed to let users switch between teams, set notification preferences per team, and manage their profile. The notification logic defined which status changes, assignments, and approval decisions should trigger alerts, along with the email notification templates. A design system was also initiated with a Storybook instance to document components, ensuring consistency and scalability as the platform grows.
Why It Matters
Role-based context is essential for personalized AI. When the AI eventually delivers recommendations, it needs to know not just who the user is, but what team they’re operating in, what their role is on that team, and what kind of changes they’re responsible for. The team and notification architecture provides this context layer. The design system work ensures that as AI features are added, they integrate seamlessly into a consistent, professional interface.
Outcome
My work at Steadi.ai was not a surface-level redesign. I came into a product that had the bones of something useful but was difficult to adopt and impossible to layer intelligence onto. I recognized that before AI could add value, the platform needed a structured semantic foundation: clear terminology, well-defined workflows, labeled statuses, and role-aware architecture.
By treating every UX decision as both a usability improvement and a data architecture decision, I built the infrastructure that makes AI implementation not just possible but inevitable. The filtering system teaches the AI what relevance means. The status architecture gives it a language for understanding work states. The workflow design generates the labeled data it needs to find patterns. Lastly, the team architecture provides the role-based context for personalized recommendations.
The result was a product that operators can actually use and an intelligence infrastructure that makes the AI layer a natural extension rather than an afterthought.
