Fieldtrix
FieldTrix is a field-sales management app that gives companies real-time visibility, automated reporting, and a structured way to run on-ground operations.
Built for teams that spend most of their time outside the office, FieldTrix helps managers track activities as they happen, standardize daily workflows, and improve productivity without micromanagement
Role :
UI/UX Designer
Duration :
4 Months
Industry :
Context
Field teams work differently from people sitting behind a desk.
Sales representatives need to plan their day, visit customers, record activities and keep moving. Managers need to plan their teams, monitor activity and understand performance.
Fieldtrix already supported these workflows, but as the product grew, its complexity began to surface across navigation, planning, terminology and everyday interactions.
My opportunity was to bring structure to that complexity.
Where I Came in :
I started by understanding the existing product across its core workflows rather than jumping straight into UI redesign.
Before touching any screen, I ran a discovery pass to force clarity on what we were actually solving and for whom. This became the reference point for every IA and navigation decision that followed.
Opportunity :
The discovery pass reframed what "fixing" the product actually meant. A Couple of opportunities came out of it, and they set the brief for everything that followed:
Design for three distinct roles, not one generic user: Zonal Managers, Sales Managers, and Reps needed navigation and permissions shaped around their actual jobs, not one menu trying to serve all three.
Fix the structure before the surface. A visual refresh wouldn't hold if the IA and language underneath it were still confusing. The product needed structural changes to information architecture and terminology before a design system would matter.
As a result an expert audit was conducted on the platform which identified :
What I found :
The audit revealed one recurring pattern: the interface reflected how the product was built, not how users needed to use it. That showed up in three areas.
Structure
Users had to interpret the relationship between modules and workflows themselves
Interaction
Important actions didn't communicate their consequences or resulting state.
Complexity
Dense screens exposed too many decisions at once.
Instead of treating these as isolated UI problems, I worked backward to the UX models underneath them.
Structure: rebuilding the information architecture :
Problem.
Navigation had evolved around features, not user intent. Users had no way to tell where they were within the platform and defaulted to the browser back button, while the Sales module was split into five separate destinations, with Approvals sitting outside the workflow it belonged to and Dashboard overlapping with Analytics.
Reasoning.
Users needed a persistent, always-visible answer to "where am I," not a browser action that could take them somewhere unpredictable. For Sales, I mapped every screen against the actual sales lifecycle instead of its technical origin, asking what belonged together and what was reporting versus action.
Decision.
I introduced breadcrumbs across the platform, scaled to the complexity of each level, so users could always see their path. I also reorganized Sales into three destinations, Primary Sales and Secondary Sales with Approvals built into each workflow, and Sales Config, while moving Analytics into Reports and renamed the Sales Dashboard module to Overview as it gave more precise understanding into what that submodule was meant for.
Result.
Users could see exactly where they were and move within a module with confidence instead of relying on the browser to get back. The Sales module went from five fragmented destinations to a structure that matched how a sale actually moves through the system, with reporting consolidated where users already expected to find it.
Interaction: fixing the flows people actually run
Problem.
Users could build out an entire month in Monthly Planner, but locking it froze the whole month instantly with no indication of what that action did or that it couldn't be undone, leaving the plan in a locked state with no visible path forward.
Reasoning.
I looked at Lock Month as a full lifecycle, not a single click. Does the user understand what will happen before they act? Can they tell what changed afterward? Do they understand what happens next? The gap wasn't the locking mechanism itself. It was that the system stayed silent at every point a user needed feedback.
Decision.
I introduced a confirmation modal before the action completes. It clearly warns that locking the month is irreversible, and explains what happens next: the plan is sent for review once locking is confirmed.
This gave users a deliberate checkpoint before an unrecoverable action, instead of an instant, unexplained state change.
Result.
In review with the stakeholder, the business analyst, and the developers involved, it was confirmed that the confirmation step resolved the earlier confusion by giving the user clear feedback on exactly what the action would do before it happened.
Complexity: from dense screens to a system built to scale
Problem.
High-use screens exposed too many competing actions at once, Secondary Sales alone had seven CTAs, while many other screens had inconsistencies like tabs that looked like filters, unlabeled icons, and non-semantic chart colors kept repeating across the product.
Reasoning.
For dense screens, I ranked existing actions by frequency and importance instead of removing functionality. But the repeating pattern issues told me this wasn't a per-screen problem, it was a missing system, and every individual fix would eventually drift without shared foundations underneath it.
Decision.
I kept primary actions visible on dense screens, grouping or progressively disclosing the rest, and narrowed Secondary Sales to three primary actions up front. At the product level, I designed and built FieldTrix's design system from scratch, covering foundations, components, and patterns, with every piece carrying the same Explain → Confirm → Show state → Recover logic used in the Lock Month fix.
Result.
Screens kept their full functional breadth without asking users to process every action at once, and the design system became reusable infrastructure rather than a one-time visual pass. It's already proving that out: FieldTrix is expanding into a Distributor Management System, a second product in the same ecosystem, and it's being built on the same design system foundations, components, and patterns established here.
Redesigning the Fieldtrix Website
Problem.
Fieldtrix had evolved significantly since the original website was launched, but its digital presence hadn't kept pace. Much of the content was outdated and no longer accurately reflected the platform's capabilities, features, or value proposition.
At the same time, Fieldtrix was expanding its offering with new capabilities and preparing to launch a Distribution Management System (DMS) alongside its existing Sales Force Automation (SFA) solution. However, the website had no dedicated way to communicate these new offerings, making it difficult for potential customers to understand the full scope of the platform.
Decision.
Restructured the website, refreshed the content and messaging, introduced dedicated product/solution pages, and created a clearer information hierarchy.
Result.
The redesigned website showed a measurable shift in engagement after launch. According to Wix Studio Analytics, Fieldtrix saw a 196% increase in site visitors within the first 30 days, while visitors viewed an average of 2.1 pages per session.
Beyond increasing reach, the higher browsing depth suggests that visitors were exploring more of the website rather than leaving after their initial landing page. This provided an early indication that the clearer information architecture, messaging, and navigation were helping users discover more of the Fieldtrix offering.
