From Paper to Platform

The Origin

It started with a conversation.

A friend who works in a medical laboratory in Switzerland mentioned that her team had just integrated a new Cobas analyzer. I asked a few questions. How do you document errors when they happen? How does someone new find the procedure they need? How do you know if the same problem keeps coming back?

Her answers were the brief. Procedures lived in paper folders. Knowledge lived in one person's head. When that person was off shift, everything slowed down.

I went home and started sketching. A few days later I came back with a working prototype. They adopted it.

The Problem

A Cobas analyzer going down does not just cause inconvenience. It delays patient results. Doctors are waiting. Samples are waiting. And the fix to a known error was either locked inside the senior technician's memory or buried in a document nobody could search.

The team had no way to search for a known error by code, submit a problem and track its resolution, pass critical information between shifts in a structured way, or prove to the device manufacturer that a recurring issue was their fault and not the lab's.

The Insight

Knowledge was being lost in three places: between shifts, between people, and between the lab and the support company.

The solution was not more documentation. It was a searchable, visual, collaborative platform that turns every solved problem into permanent knowledge.

The Design

Three user types, each with a clear job.

The Viewer is the lab technician. They encounter an error, search the knowledge base, and if no article exists they submit a ticket with a description and a screenshot.

The Editor is the senior technician. They receive the ticket, resolve it, and convert it into a published article with annotated images and step-by-step instructions.

The Admin manages users, access, and system settings.

The Hard Parts

Two design challenges stood out.

The first was the article editor. It needed to feel like Notion or Google Docs. Familiar enough that a lab technician would not need training to use it. Rich text, headings, images, structured steps.

The second was image annotation. A screenshot alone is not enough when you are explaining which physical component to touch on a machine the size of a refrigerator. The annotation tool lets editors place numbered markers directly on images. Visual, precise, and language-independent. A picture is worth a thousand words, especially when the technician's first language is not the same as the procedure writer's.

The Field Visit

I visited the lab during a night shift. I watched a technician rush through the handover notes, trying to document the day's incidents before the last train of the evening.

That moment gave me the voice transcript feature. Instead of typing, the technician speaks. A local AI transcribes it. They review, make small edits if needed, and hit submit. The train does not wait. But now neither does the knowledge.

The Shift Handover Log

Teams were already using Microsoft Teams chat to pass information between shifts. Informally, unsearchably, and with no structure.

The Handover Log replaced that with tagged, searchable shift records. Every entry is timestamped, linked to a user, tagged to an instrument, and flagged if it needs follow-up. Over time this became evidence — a documented trail the lab could use when disputing recurring hardware issues with the manufacturer.

The Outcome

When the Cobas was first installed, the lab was handling approximately 12 support tickets per day. After the platform was in use, that dropped to 2 or 3 per day, sometimes zero.

A 75% reduction in daily incidents. Not because the device improved, but because the knowledge became accessible to everyone, not just the senior technician.

• 75% Reduction in daily support tickets
• 128 Knowledge articles published
• 16 Staff members on the platform
• 6x Faster Critical issue resolution on off-shifts

What I Learned

The night shift visit changed the product in a way no meeting room interview ever would have. Real pressure reveals real problems.

Having a design system ready meant the prototype was running in 3 hours. Speed of execution kept the momentum alive before the idea could lose energy.