It runs field service operations end to end. Managers schedule and dispatch jobs, track technicians live on a map, optimize routes, review job evidence and clock-in logs, and invoice from the same system. It connects to the accounting and ticketing tools companies already use.
Product URL
fieldservicely.com
The technology was fine. The interface was from an earlier version of the company, and it had started costing money.
Two words kept coming back from users: "clunky" and "dark." People couldn't find basic tools. On demo calls, prospects assumed a dated interface meant dated technology underneath, sales told me that objection came up more often than any missing feature.
So this wasn't a re-skin. The job was to make the product look as capable as it actually is, and make the daily work faster for the people already paying for it.
My working theory was that visual credibility was gating trial conversion, that people were judging the engine by the dashboard. I designed against that assumption. I never got the data to prove it, and I'll come back to that at the end.
Make the frequent tasks fast. Managers live in this tool for eight hours a day. Every extra click is a real cost.
Make it look current. Not for its own sake, but because it was gating trials.
Build it once. A component library, so that new features wouldn't drift away from each other over time.
My Role
I was the only designer on FieldServicely, working with a product owner and the engineering team. Every design decision here was mine, and so was every argument I lost.
In practice that meant deciding what got built and what got deferred, since there was no one else to escalate scope questions to. It meant running my own research, with the limits I've described. And it meant that whenever the design was wrong, it was wrong because of a call I made.
The part that took the most time wasn't drawing screens. It was getting agreement, walking the product owner and lead developer through prototypes early enough that we found the technically expensive ideas before I'd designed around them.
I couldn't run the process I'd have wanted, so I ran the one the timeline allowed: pull what I could from the people who talk to users daily, map the whole product on paper before touching a screen, test the riskiest flow with whoever I could get, then hand off a system rather than screens.
We didn't have the budget or the runway for field research. The MVP date was fixed and I was the only designer on the product. So I used the next best source: the three teams inside the company who speak to field service managers all day.
Support kept hearing the same question, and it wasn't how does this work. It was where is this. People weren't confused by the features — they couldn't find them. That's a navigation problem, and no amount of onboarding fixes it.
Sales told me the interface was their hardest objection on demos. Not price. Not a missing feature. Prospects were reading a dated UI as dated technology underneath, and deciding the engine was as old as the dashboard.
Marketing said the layout made the product look harder to use than it actually is, which was costing them on the website as much as it was costing us in the app.
I also spent real time inside Jobber, Connecteam, ActivTrak and ServiceTitan. Not collecting screenshots, working through how each one handles the core jobs of this industry (scheduling, dispatch, time tracking, invoicing) and how they package and price them. Which capabilities sit in the base tier, which are gated, what they're betting people will pay more for.
That gave me a clear read on what's table stakes in this market, and a sense of where design effort was worth the most, because the screens tied to revenue are the ones a buyer judges you on.
What this method can't do. None of it is observation. It's secondhand, filtered through people with their own incentives, sales wants an easier demo, support wants fewer tickets, and neither is the same as a manager wanting to finish a dispatch faster.
It's good for locating pain and unreliable for explaining it. I knew that going in, said so to the team, and treated everything here as a lead to design against rather than a conclusion to design from.
Before touching a screen I mapped the whole product on paper, navigation, the flows underneath it, and every integration and feature that had come up in research. Some of it made the build. A lot of it didn't
The starred items are the ones I marked "review later": AI-assisted job matching, dynamic pricing based on job difficulty, skill-gap analysis feeding performance reviews. Good ideas, none of them MVP. I also mapped a field technician app and deliberately left it out of scope, this release was manager-side, and splitting focus across two very different users would have cost us the launch date.
What did make it was the spine: navigation, job creation through technician assignment through status tracking, and the integrations we already had customers asking for. I built the IA so the deferred items had somewhere to go later rather than needing a rebuild.
Previous Dashboard
Ambiguous Data Visualization: First metric cards displayed human names and numbers without context or labels. This forced users to use extra mental effort just to decipher what they were looking at.
Mental Model Friction (Jakob’s Law): Critical user and organization settings were floating at the bottom of the sidebar. This unconventional placement broke user expectations and cluttered the primary navigation.
High Interaction Cost: Meaningless color palettes and "noisy" data clusters created a heavy atmosphere, making it difficult for managers to prioritize urgent field tasks.
Visual Inconsistency: Outdated icons, mismatched typography, and poor spatial balance made the platform feel "backdated" and unreliable compared to modern competitors.
The Verdict: The dashboard was a collection of data points rather than a functional tool for a Field Service Manager. It failed to provide the "at-a-glance" clarity required for high-stakes workforce management.
New Improved Dashboard
Previous Schedule Organizer
Improved Schedule Screen
Previous Tasklist
Improved Task List Screen
Gallery
Route optimization screen
Tasks in map
Task creation form
Invoice creation form
Task details
Weekly schedule view
I ran two rounds, three to five people each. Small, fast, and I want to be straightforward about what that can and can't tell you.
The first round used colleagues who'd never seen the product. I watched them try to create a job and run a route optimization with no help from me. They aren't field service managers, so this could only tell me whether things were findable, not whether the workflow matched how a manager actually reasons about a half-finished job.
In the job creation flow, people couldn't find the assignee selector. They'd fill in the job details, then stall, looking for where to assign a technician, which is the entire point of creating a job. It made sense to me because I'd designed the layout. It made no sense to someone seeing it cold. I moved the selector, ran the flow again with fresh participants, and it stopped being a stumbling point.
That's a small fix. But without those three to five people, it ships, and every manager hits it on the single most frequent task in the product.
The second round, after the build, put the product in front of active field service managers. The two things they raised unprompted were spacing and readability on tablets. Both about how it feels. Neither about whether they finished faster.
That's the gap. I know the product feels better. I don't know whether dispatching a job takes less time, and that's the number that would have mattered.
I've seen enough redesigns die between Figma and production that I treated handoff as part of the design, not the end of it.
I delivered a component library rather than screens, buttons, inputs, cards, tables, each with hover, active and disabled states defined. New screens get assembled from it instead of drawn.
I built the file to be machine-readable, which mattered because our developers were pulling context through Figma's MCP server. In practice that meant named variables instead of raw hex values, auto-layout everywhere rather than absolute positioning, and consistent component and layer naming. The 8pt spacing system was part of it, but the naming and structure did most of the work.
For the interactions that don't survive a static mock, task list expansion, filter behaviour, I sent prototypes instead of writing documents about them.
Redlines and notes covered spacing, edge cases and accessibility, so the questions that usually arrive at build time were answered before it started.
What I can and can't tell you
The analytics are confidential, so there's no retention chart here. What I have is people's accounts, and I'd rather label them as that than dress them up as measurement.
Sales stopped raising the interface as a blocker on demo calls.
Support saw fewer "where do I find X" tickets, the exact category of question that started this project.
What I'd instrument if I could start again: time from job creation to technician assignment, approval cycle time on tasks, and navigation-related ticket volume. Three numbers, defined before launch instead of asked for after. Those would have told me whether the redesign did what I claimed it did.
Six months on, we started adding features from customer requests. They went into the system Is built, which is the real test of a design system, and one most case studies never get to run.
Internal proxies find problems but can't explain them. Sales, support and marketing all told me the interface was the issue, but each meant something different by it, and I couldn't reliably separate a problem users had from a problem sales had selling. Those aren't the same problem and they don't have the same fix.
I treated contrast as if it were accessibility. High-contrast text genuinely helps a manager reading a tablet in daylight, and I was pleased with it. But for a data-dense app, the accessibility work that matters most is keyboard navigation and table semantics, and I didn't go deep enough there.
