Asmik Mikaelian — designer of minePASS LAMP

How I designed a safety-critical system by working directly with the people who use it underground.

minePASS LAMP is the digital system for the lamp room at an underground mine — where every transaction is a safety record and every second at shift start counts.

Enterprise B2B Safety Systems Admin UX Mining Industry End to End
Step 01

This is not a typical product. I had to understand the physical world first.

The lamp room is the last checkpoint before a miner goes underground. It is not optional — it is a regulatory safety requirement. Every miner must collect their cap lamp, self-rescuer, and gas analyzer. Every issue must be recorded. In an emergency, the mine safety officer must know — instantly — who is underground right now.
What the system had to do
→Record every entry and exit — who went underground, at what time, with which equipment.
→Process miners fast — at shift start, 40–50 miners arrive in a 10–15 minute window. The system had to keep up.
→Prevent equipment errors — wrong assignment is a safety violation. The UI had to make mistakes hard, not easy.
→Give real-time underground status — management needs a live list of who is below, always current.
→Integrate with minePASS — fit into the existing platform's employee data, roles, and CIN (company ID) system.
Why this project is different

Most admin systems exist to improve efficiency. This one exists to support safety. A paper ledger that has an error is an inconvenience. A digital system that has an error in a mine is a safety incident.

I designed this with the weight of that responsibility in mind from the first screen to the last.

Step 02

I worked with the admins on site — not with stakeholders in a meeting room.

Research approach

I did not start with wireframes. I spent time with the lamp room administrators — the people who would use this system every working day. I watched how they managed the existing paper process, where it broke down, and what they needed to never worry about.

This is not a system designed for a stakeholder presentation. It is a system designed for a person standing behind a counter at 5:45am, processing miners before a shift starts.

Primary user Lamp Room Administrator

On-site staff responsible for issuing and receiving safety equipment at each shift. Not a technical user. Works under time pressure at shift transitions.

Process entries in under 10 seconds per miner
See immediately if something is wrong
Know which equipment is out and with whom
Handle the rush without mistakes
Secondary user Mine Safety Officer / Shift Manager

Needs oversight of underground personnel at any moment. Manages employees, reviews reports, and handles escalations from the lamp room.

Real-time list of who is underground
Equipment audit history per employee
Employee management and role assignment
Alerts for unreturned equipment
Step 03

I mapped both flows end to end before designing a single screen.

Two critical flows

The entire lamp room operation comes down to two flows: entry and exit. I mapped both fully — including every error state, every edge case, and every decision point — before opening a design tool.

Step 04

The paper process revealed four problems the digital system had to solve.

Problem 01 Shift rush created processing bottlenecks

40–50 miners arriving in 15 minutes meant the paper system caused queues. Any UI with too many steps or small touch targets would replicate the same problem digitally.

Problem 02 Equipment misassignment was possible and undetected

Manual recording meant a lamp could be assigned to the wrong CIN. No system check. No alert. The error would only be discovered during an audit or incident review.

Problem 03 No real-time underground personnel list

The paper ledger showed cumulative entries, not a live current list. In an emergency, a manager had to manually reconstruct who was still underground from entries and exits.

Problem 04 No audit trail for equipment history

Paper records were lost, damaged or illegible. There was no way to retrieve reliable equipment history per employee for compliance reporting or incident investigation.

Step 05

Four principles shaped every decision.

01

Speed before everything

The terminal must process one miner in under 10 seconds. Scan → verify → confirm. Every additional tap is a problem. If the rush still causes queues, the design has failed.

02

Make errors impossible

In a safety-critical system, error prevention matters more than error recovery. The UI should make correct actions obvious and wrong actions require deliberate effort to take.

03

One source of truth

Underground personnel status must be a single live number — not reconstructed from logs, not estimated. Any manager, on any device, sees the same current list.

04

Designed with the users

Every interaction was reviewed with the lamp room administrators before it was finalised. Their corrections changed the design. Their confidence in the system was the acceptance criteria.

Step 06

One problem needed two different interfaces.

The core architectural decision

The lamp room administrator and the shift manager have completely different contexts, needs and environments. Designing one interface for both would mean compromising both. I designed two purpose-built interfaces that share the same data layer.

Interface 01 The Terminal

A tablet mounted at the lamp room counter. Handles one task: process a miner in or out. Designed for speed, large touch targets, and high-contrast feedback at a glance.

Tablet-first, touch-optimised
QR/RFID scan as primary input
Two states: Entry / Exit
Minimal steps — scan, verify, confirm
Large visual feedback (authorised / error)
Manual entry fallback if scan fails
Interface 02 The Admin Dashboard

A web interface for shift managers and safety officers. Handles everything the terminal doesn't: employee management, live underground status, equipment history, reports.

Web, desktop-optimised
Live underground personnel list
Employee CIN management and roles
Equipment issue and return history
SMS notification system
Shift reports and audit trail
Step 07

What collaboration with admins revealed that no brief could have told me.

Working method

I reviewed every screen and interaction with the lamp room administrators before finalising it. Their corrections were direct and specific — they knew immediately what would and wouldn't work in their environment. Those conversations changed the design in ways no user story could have predicted.

At the start of the shift I don't look at the screen much — I'm watching the miner, checking their card, managing the queue. I need to hear or feel when it works. Added distinct audio feedback for authorised and error states
Sometimes the card reader misses on the first scan. I can't have the queue waiting while I retry three times. Built a manual CIN entry fallback accessible in one tap
When management calls asking who is underground, I need to tell them immediately. Right now I have to count the ledger. Live underground count shown prominently in the dashboard header — always current
Some miners try to borrow each other's lamps. I need to see the photo, not just the name, to be sure it's the right person. Employee photo made the dominant element on the authorised confirmation screen
Step 08

I built a design system to make both interfaces feel like one product.

System rationale

The terminal and the dashboard share the same employee data, the same CIN structure, and the same status system. I built a unified component library so both interfaces feel like they come from the same product — even though they serve entirely different contexts and users.

Component inventory
→Employee CIN card — photo, name, CIN number, role badge, current status
→Role badges — Financial, Structural, Technical, Analyst — colour-coded for quick scanning
→Status system — Underground / Surface / Unknown / Flagged — consistent across both interfaces
→Action confirmation modals — standardised patterns for entry, exit and equipment assignments
→SMS notification component — for push alerts to employees and managers
→Form field states — default, active, error, disabled — covering all validation cases
→
Why a design system mattered here

The lamp room module was built to be part of a larger platform (minePASS). Consistency meant that when an employee record looked one way in the admin dashboard, it looked the same way in the terminal confirmation screen. No visual relearning. No confusion under pressure.

A component built once, trusted everywhere. That is the point of a system.

Implemented at

NOVA Zinc and Kirovskaya Mine — part of the minePASS platform rollout.

Quantitative post-launch data is not available for this case study. The outcomes below reflect what the system was designed to achieve, observed through admin feedback and operational context.

⚡ Faster shift processing. QR scan + single confirmation replaced multi-step paper recording. Reduced time per miner at the counter.
🛡️ Eliminated equipment misassignment. System-verified CIN matching with photo confirmation made wrong assignment require deliberate override.
📍 Live underground personnel list. Shift managers can answer "who is underground right now" without calling the lamp room or reconstructing records.
📋 Complete audit trail. Every entry, exit and equipment issue is timestamped and retrievable — replacing paper records that could be lost or unreadable.
♾️ Scalable to new modules. The design system and data architecture are built to extend into other minePASS modules without redesigning from scratch.
Reflection

The most important thing I did on this project was spend time on-site before opening a design tool. The lamp room administrators knew things about their work that no brief, persona or requirements document could have captured — things that directly changed how the terminal behaves, what feedback it gives, and what the admin dashboard prioritises.

Working with them did not slow the process. It made every decision faster to validate, because the people who mattered were in the room.

In safety-critical systems, the cost of designing without the user is not a poor rating or low engagement. It is a safety incident. That changed how I approached every screen.

Other cases

Asmik Mikaelian — LinkedIn