CASE 05 / WHERE THE PRACTICE CAME FROM — TEXA · TELEBIT
Low level interfaces
OP 10
Context
TEXA builds the diagnostic equipment a workshop plugs into a car. I joined in September 2019, with the job title UX/UI designer for low level interfaces. I worked next to the engineering and mechanical teams — requirements gathered at the bench, then tested on actual vehicles — and the applications I reviewed had to hold the safety standards set by whichever manufacturer’s car was on the lift.
OP 20
Constraint
No colour, because the hardware could not render it. The interface was drawn on top of the bus in a very low-level language, and what could be shown was set by the protocol: which data existed, which measures could be written, which could not. Colour was never a decision anybody made — it simply was not available, so everything colour normally does had to be done by structure instead.
That taught me the bones of design, by force. Not as a philosophy — there was no alternative. When the palette is empty, the only things left holding a screen together are hierarchy, order and behaviour, and you find out quickly whether yours are any good.
OP 30
Range
Telebit put all of it back, and then asked for the opposite skill. From January 2021 I designed and developed the frontend of every one of their web and mobile applications. I was also talking to technicians, HR, sales and marketing — four groups who wanted different things from the same product, which meant changing approach with whoever was in front of me. Nothing at TEXA had required that.
Telebit paid for the Google UX certification. I finished it after I had left. It gave shape to fundamentals I had been using without being able to name them, and it is the hinge between junior and everything after. An employer looked at a frontend developer and decided to pay for the theory underneath — the certificate is dated August 2022, months after I was gone. That is the rare kind of investment a company makes without ever seeing the return on it. I would not be doing this work without it.
- VALID — the pass is good, start your shift. Green, and a tick.
- NOT VALID — contact your manager now. Red, and a cross.
- NOT YOURS — the pass does not belong to whoever the one-time code was sent to. Orange, and a question mark.
- Every state carries an icon as well as a colour, so none of the three depends on colour vision.
- Every message says what to do, not what happened. A person holding a phone at a factory gate has no use for a status.
- The third state exists because a pass can be borrowed. Binding it to an SMS code was what made that checkable — and it is the state nobody asks for in the brief.
- Valido · Non valido · Non leggibile — the three ways a check can come out.
- SMS non inviato · GP non caricato — NOT failures. Nothing has happened yet, and they are kept apart from the failures so the administrator chases the right person for the right reason.
- Percentuali validità — how the completed checks came out.
- Percentuali verifiche — how much of the workforce has been checked at all. The grey 42% is the actual job, and it is the number the first chart cannot tell you.
- LEFT — the green pass check. For an employee at a gate, with no training, no patience and one thing to do. Bright, two buttons, one decision.
- RIGHT — the installation manager. For a field technician tracking 359 plants across northern Italy through an eight-state lifecycle, from quoted to installed to tampered with.
- Same designer, same company, same year. They do not look alike because the people holding them were not alike — and working that out for each one is what the year was for.
OP 40
Outcome
In January 2022 I went to Atos, on the Bridgestone tyre-testing platform. To SCM Group the year after. The industrial constraint set — manufacturer safety standards, technicians with their hands full, systems that cannot afford a pretty guess — was never a specialism I picked up later. It was the only environment I had ever designed in.
What it could have been
The finished screens argue for themselves. These are the forks — what was tried first, and what replaced it.
-
FORK 01
Was the plainness right, or just familiar?
Rejected
The richer visual language I turned up with. It was my first time doing most of this, and what I reached for was habit more than judgment.
Shipped
The grey buttons and the numbers. My colleagues argued the plain components were a statement by that point — a technician opening a diagnostic tool expects to see exactly that, and recognises it instantly. I gave in most of the time, and I gave in for the wrong reason: inexperience, not conviction. They were right anyway. The one thing I kept pushing where I could was card-like hierarchy, so a screen had an order to be read in. That was the part worth arguing for.
-
FORK 02
A calibration procedure as text, or as a drawing?
Rejected
Text — which is what the protocol documentation already was, and the cheapest thing to deliver.
Shipped
Sketching diagrams and putting them forward. A sensor calibration performed without the correct protocol is not a poor experience, it is a dangerous one, and a technician working across a whole vehicle range cannot follow prose. Some of the diagrams were approved. Where they were not, what shipped was text, and in those cases it was genuinely impossible to follow for every vehicle.
-
FORK 03
Wait for a clear requirement, or interpret one?
Rejected
Waiting. In automotive the needs are clear, the bounds are clear and the direction is clear — the protocol tells you which data exists, what you may write and what you may not. I carried that expectation into Telebit as though it were how work arrives everywhere.
Shipped
Interpreting. Apply automotive logic to any other field and it comes down like a sand castle. Asking for a detailed request is simply impossible outside a domain that hands you one — most of the time a designer has to reshuffle the cards and deliver what the user actually wanted rather than what they asked for.
-
FORK 04
One tool for everyone, or one main user per tool?
Rejected
Serving all four groups in every product. Technicians, HR, sales and marketing all wanted something from the same company, and the tempting answer is one tool that answers to all of them.
Shipped
A named main user for each product, and everyone else second. A COVID green pass scanner needed in three days went to the technicians who were not in the building. The intranet went to HR and marketing. The orders and shipments portal went to sales and the technicians who were. Working out who the main user is, and writing the personas, is the first step in winning.