CASE 02 / ENTERPRISE WEB APP — BRIDGESTONE · VIA ATOS

Tescam

Client: Bridgestone · via Atos
Year: 2022
Role: UX Designer & Product Owner
Scope: Enterprise web app · Research → delivery
Outcome: A structured tool where spreadsheets used to be

The screens below are a demonstration build, made for this portfolio to show the kind of surfaces this work produced. They are not Bridgestone’s application. The delivered work is under NDA: it is not shown here, and nothing about it — its design, its data, or its behaviour — should be inferred from these images.

FIG. 0 — TESCAM · PRODUCT WALKTHROUGH DEMONSTRATION BUILD — NOT THE DELIVERED UI

OP 10

Context

Bridgestone’s mechanical engineers test tires — a rigorous, regulated process with real safety weight behind every result. The work was being coordinated through scattered Excel sheets and workflows that lived in people’s heads.

I designed the web application from scratch and carried it as product owner. Research, definition, design, and the decisions in between.

Demonstration screen — a testing dashboard: the day’s scheduled diagnostic sessions, facility utilisation and active sensor counts, and a daily queue listing each test by time, subject, protocol and status — FIG. 02A — Daily queue · every procedure scheduled, with its state on the row DEMONSTRATION BUILD — NOT THE DELIVERED UI

OP 20

Problem

Scheduling, data collection, and approvals each lived in a different file, and none of them knew about the others. There was no single structured record of what had been tested or who had signed it off, so proving the trail after the fact meant chasing documents and the people who kept them.

OP 30

Process

I sat with the engineers to understand the testing procedures as they actually happen, not as an org chart imagines them. From there I structured the tool around the real sequence — scheduling, execution, data capture, and approval — with the states and permissions that a regulated process needs.

Demonstration screen — parameter entry for a test run: angles, surface temperature and ride heights entered on the left, with the computed load distribution and derived values held beside them — FIG. 02B — Parameter entry · values captured against a named procedure, not a cell DEMONSTRATION BUILD — NOT THE DELIVERED UI

Demonstration screen — a procedure library: a searchable list of standard operating procedures beside the open document, showing its objective, its pre-requisites, and a critical safety notice — FIG. 02C — Procedure record · the standard beside the run it governs DEMONSTRATION BUILD — NOT THE DELIVERED UI

Demonstration screen — live tyre telemetry: the vehicle drawn as a wireframe with one tyre lit as a heat map, its sensor readings tagged on the wheel, and surface temperature, pressure and variance tracked against target beside it — FIG. 02 — TESCAM CLIENT UI UNDER NDA — SYSTEM SHOWN AS SCHEMATIC

OP 40

Outcome

Testing moved off improvised spreadsheets and onto a purpose-built application. A single structured place to schedule procedures, collect data, and manage approvals — with a clear, auditable trail of what happened and who signed it.

Demonstration screen — a live telemetry view: a wireframe vehicle with a heat overlay on one tyre, surface temperature and wear diagnostics alongside, and current pressure read against target — FIG. 02D — Live telemetry · readings tied to the test that produced them DEMONSTRATION BUILD — NOT THE DELIVERED UI