Role
Product engineer, for software people use all day
Support says the system is slow. The traces say every request is fast. Both are true, and the gap between them is where the actual product problem lives.
How I fit
I build the parts people touch, and I design them rather than implementing somebody else's design. That combination matters most in operational software, where the person using it is doing a repetitive job under time pressure and the difference between six interactions and two is an hour of their week.
A challenge from this role
Support reports that the system is slow. Every trace shows requests completing in well under a second. Nobody is lying. The requests are fast and the workflow is long, and the users have no vocabulary for that distinction, so it arrives as a performance complaint and gets routed to the wrong person.
How I approach it
Watch somebody work for an hour before touching anything. That single hour reliably produces more than a week of analytics, because it surfaces the workarounds people have stopped noticing, and a smooth workaround never generates a complaint. Count the interactions in the most frequent task and time it end to end, then optimise for the tenth repetition rather than the first impression, because in operational software that is the trade that matters. Be suspicious of the instinct to add whitespace and remove things, which is correct for consumer software and often exactly wrong here.
What proves it
Operational interfaces designed and implemented, cutting the most frequent task from six interactions and two page loads to two and none.
Density, tables, forms and the three states every demo skips, as working rules rather than opinions.
A primary answer served in one request because the audience is on the worst connections available.
Client sites built so the owner can update them from a phone in under two minutes, which is what keeps them from going stale.
The person designing the screen also knows what the query can return cheaply, which changes what the screen should ask for.
Users report symptoms, not causes
They report them in the vocabulary of speed, because slow is the only word available for a bad experience with a computer.
Sometimes it means the request is slow. More often it means the workflow is long, the screen has moved under them, they lost their place, or they had to hold a number in their head across a page load.
Telling those apart cannot be done from a dashboard. It requires watching somebody work, which is an hour that repeatedly turns out to be the highest value hour in the project.
The instinct that misleads
Most widely repeated interface advice is written for software people visit occasionally. Remove things, add space, simplify.
Apply that to a screen somebody lives in and you push content below the fold and add a scroll to a task performed sixty times a day. The screenshot improves and the job gets slower, which is the exact trade nobody would make deliberately.
Questions people actually ask
- Do you need a designer alongside you?
- For brand and marketing work, yes, and gladly. For operational interfaces I would rather own it, because the constraints are mostly about the data and the workflow, and those live with the person building it.
- What is the most under rated part of this job?
- Empty, loading and error states. They never appear in a demo so nobody asks for them, which means building them is always an unprompted decision, and that is exactly why they signal something about the engineer.