Unidas, Grupo Vamos and Grupo 3 Corações · Internal products · Senior product designer · 2023 to 2025
Who gets held accountable for what
Three large companies, three internal products and a user who chose none of it. The people opening these screens are workshop mechanics, operations analysts and whoever runs the daily routine, with targets above them and the phone ringing. Nobody there asked for a new system and nobody there will read a tutorial.
The competitor of an internal product is not a competitor's software. It is the spreadsheet the team already keeps, the message group that already works and the way the person already does it. If the new screen costs more effort than the old way, the old way wins, and nobody tells you.
- Role
- Senior product designer, allocated by Triggo Labs inside each company's team. Field work with the people who run the routine, information architecture and the design of the operations screens.
- Context
- Three separate projects, one per company, not one product rolled out three times. Light vehicle rental, heavy vehicle rental and consumer goods manufacturing. In all of them, internal users, operational targets and an old way that already works.
- Method honesty
- The deliveries stayed inside the companies and I hold no screens, prototypes or reports from any of the three. Of the three, only the Unidas one is described here at the level of a screen decision. This page is short on purpose: it carries the framing and the method that repeated, and nothing beyond that.
From the field to the screen of the person doing the work
- 01
Context
Three separate projects, across three companies, with the same kind of user: the person who runs the routine and did not choose the tool.
- 02
Field
Understand the routine before designing a screen, with the people who run it, in the place where it happens.
- 03
The question
Who gets held accountable for what. The answer to that decides what the screen shows first.
- 04
Unidas
A maintenance MVP from the ticket to the workshop, with the vehicle's state visible to the people doing the work.
- 05
Adoption
A product the operation starts using with no formal training, because it fits the way they already work.
The competitor is the spreadsheet that already exists
A consumer product signals when it fails. People stop coming back, cancel the subscription, complain in the store. An internal product signals nothing. The person stays logged in, opens the screen when the boss asks, and keeps doing the real work wherever they always did it.
An internal product never loses a user, it gains a double. The parallel spreadsheet keeps running alongside, and the official dashboard stays correct and empty.
That changes what I look for in the field. In an internal product the most useful question is not what annoys the person about the current tool. It is what they do outside the tool, and why. The notebook, the message group, the spreadsheet they keep on their own, the phone call they make to confirm something the system should already answer. Each of those is a requirement nobody wrote down.
The same screen is read by three different accountabilities
In a large company, an operations screen is read at the same time by people who answer for different things. The person in the workshop answers for vehicles released. The person coordinating the operation answers for vehicles down. The person looking from above answers for cost. It is the same record on screen and three readings of it, and designing without knowing that means serving whoever asked last.
Before the screen, understand who gets held accountable for what. An internal product that ignores it becomes a parallel spreadsheet within two weeks.
At Unidas that had a direct consequence in the design. What sat in front of the people at the front line was the vehicle's state, not the ticket's progress. A ticket is the unit of whoever administers the process. A vehicle is the unit of whoever works on it. Both are legitimate views of the same fact, and choosing which one opens the screen decides whether the mechanic uses the system or picks up the phone to ask someone.
One caveat, because this is where an evaluator pushes. I will not list what was discarded in each decision across these three projects. The rest of this site carries the discard next to the decision on purpose, and a discard is not something I rebuild from memory two years later without the risk of telling a better story than the one that happened.
What repeated across the three
These are three different projects in three different sectors, not the same tool installed three times. That is what makes the part that repeated a method. What the person types has to come back useful to that same person, on the same day. If a field exists only to feed another department's report, it becomes unpaid work, and unpaid work gets filled in with whatever.
Data that only serves somebody else's report arrives wrong. People who type without getting anything back type anything, and the dashboard upstairs ends up pretty and false.
The second rule is about where the product enters. An internal product that needs a process change to work depends on a decision that is not a design decision and usually does not happen. What worked was entering the process that already exists, solving the annoyance of the people operating it first, and letting management's report come out as a by-product of real usage rather than the other way round.
What I have and what I do not
What I can state is the feedback that came back from the operation: the products started being used with no formal training, no manual and no internal adoption campaign. For an internal product that is a real result, because the normal outcome is the opposite, with training, chasing people, and the spreadsheet alive all the same.
What I do not have is measurement. There is no usage rate, no time from ticket to workshop before and after, and no count of how many parallel spreadsheets died. Those numbers, if they exist, stayed inside the companies, and I would rather leave the hole visible than fill it with an estimate.
This is the shortest case on the site because it is the one with the least material. Stretching the text to disguise a missing artefact is the first thing an evaluator notices.
The old way is the requirement nobody wrote down
Twelve years separate this case from the online to store project at CVC, and both end up in the same place by different routes. There it was the salesperson behind the counter, paid for what they sold themselves. Here it is the mechanic in the workshop, answering for vehicles released. In neither of them was adoption a training topic. In both it was a design topic.
That is where the way I build today comes from. When I put an AI agent to act inside a product, it ships with a trail of what it did and an off switch, because whoever operates it has to stay the owner of their own work. A tool that takes that away is not ignored out of stubbornness. It gets worked around, and the workaround becomes the real process.
