Case study · Dimark
Redesigning a maintenance app that technicians chose themselves
DiMS is Dimark’s maintenance system for airport baggage-handling lines. I redesigned how technicians report faults, plan their work and run line service, and built the design system behind it. When the team’s version and my prototype were tested side by side, the technicians picked mine, and it went to production.
8–10 h
Before the redesign
One baggage-line service took a full working day.
~40%
Less time
As estimated by the technicians who ran the service.
3
Technicians
Involved from the first interview to the final test.
Company
Dimark
Domain
Industrial B2B, airport baggage systems
Timeline
May 2022 – Jan 2024
My role
UI/UX designer, the only designer on the team
Team
Team leader, front-end and back-end developers, tester
Platform
Tablet and desktop (mobile designed)
01 · Context
Airports can’t wait for a fix
Dimark designs, installs and services baggage-handling systems for airports. When a line stops, bags stop and flights can be delayed, so maintenance runs under time pressure.
DiMS is the app technicians use for this work: reporting faults, planning tasks and running scheduled service on the line. Over almost two years at Dimark, I worked on DiMS and on other apps in the same product family, including the SCADA monitoring system.
02 · Problem
Two needs, one tool
Business need
One consistent set of apps, faster delivery of new features, and accessibility good enough for markets with stricter requirements (WCAG).
User need
Technicians didn’t know how to use some features, couldn’t easily go back a step, and struggled with small buttons and low contrast on the tablet.
The harder problem: the team and I understood the service process differently. Before drawing screens, we had to agree on how a line service actually runs.
03 · My role
The only designer on the team
I worked with a team leader, front-end and back-end developers and a tester.
What I did
UX/UI audit, interviews and tests with technicians, process mapping, the design system, UI for the company’s apps, and handoff in Figma.
What I started
The audit as a starting point, accessibility (WCAG) as a team standard, and a design system built from scratch, all together with the team.
04 · Direction
Fix the foundation first with one design system. Then design the service process around how technicians actually work on the line.
05 · Impact
What changed
For technicians
Clear steps instead of guessing. A service that used to take 8–10 hours became, in their own estimate, about 40% shorter.
For developers
A documented design system, so new screens were built from existing parts instead of being designed from zero every time.
For the business
One consistent product family and a base ready for accessibility requirements.
The full story
How we got there
06 · Research
Talking to the people on the line
I worked with three technicians and stayed in regular contact with them for the whole project. We talked face to face, next to the working app, in a place where testing was practical. I turned what they told me into Figma prototypes and tested clickable versions with them.
Mapping the process
Before designing screens, I mapped the full fault lifecycle in four flows: reporting a fault, defining it as a task, accepting the finished work, and the service report. Each flow started with a user story and a goal, and listed every decision point, required field and status.
Report
The technician picks the device by scanning a QR code, choosing it from a list or typing its name, then adds symptoms, priority, location (arrivals, departures, out-of-gauge) and a description.
Define
The manager turns the report into a task. Instructions, parts and tools for that device are attached automatically, and the task lands in the planner.
Confirm
The manager accepts the fix or sends it back. A rejected fix returns to the top of the list.
Statuses
Six statuses, each with its own colour: Undefined, Not planned, Planned, In progress, Done, Unsolved.
Fragments only. Because of the NDA, I can’t show the full process.
Insight → Action
→ A persistent back action on every step
→ Touch targets of at least 48 px, main actions at the bottom of the screen
→ A palette checked against WCAG AA
→ One design system for all of them
07 · The decision
Two versions of the service process
This was the hardest part of the project. I designed the whole line-service process, and the team and stakeholders rejected it. They had a different picture of how the service should run.
I didn’t push back. I built their version as asked, and kept developing mine separately as a clickable Figma prototype, without blocking the team.
The team’s version
Built first, the way the team and stakeholders asked for it.
My prototype
Clickable in Figma. The technicians compared both and chose it, and it went to production.
When the team disagrees, let the people who do the work compare real options.
Constraints and what we left for later
Photos
Some airports don’t allow photos, so pictures of the device and location are optional, while a written description is always required.
Later
Editing and cancelling a reported fault, and showing a fault’s repair history when it’s defined again. We noted both as future features so the first version could ship.
08 · Solution
Before and after
Three screens technicians use every day. Click a screen to see it larger.
Before: a generic form on a gradient. After: a branded DiMS start screen with the language switch at the top.
Before
After
Before: a long form with dropdowns. After: tap-first tiles. Scan a QR code, pick the symptom and priority, add a photo.
Before
After
Before: coloured tiles with codes like MAL or OC01 and no context. After: a team timeline with task status, deadlines and a to-do list beside it.
Before
After
Names and logins on the screens are blurred.
09 · Outcomes
From outcome to impact
→ Faults are reported with the device, symptom, priority and photo in one place
→ Technicians and managers see the same plan and task status
→ Developers build new screens from documented parts
→ It went to production
10 · Learnings
What I’d keep doing
01
Start with an audit. It gives the team a shared list of problems instead of opinions.
02
When you disagree with the team, build both options and let users compare them.
03
Accessibility has to be explained, not just applied.
04
Test where the work happens, with the people who do it.
11 · More from Dimark
Other apps in the family
Besides DiMS, I designed for other apps in Dimark’s product family. If you’d like to know more, I’m happy to walk you through them in an interview.
Video monitoring
BRS mobile app
DiSCADA
BRS on handheld scanners