Solo concept for an evidence system that runs on a rugged field tablet and a lab desktop.
The aim: a digital space that mirrors the physical work as closely as possible,
so critical data gets documented well even under distraction and time pressure.
Role: Product Designer
Team: Solo
Scale: 2 devices, 2 user roles, 4 screens
Status: Personal design challenge, 4 days
Evidence is documented in conditions that work against careful documentation: a crowded scene full of distractions, time pressure, and data that has to be recorded correctly the first time.
At the scene, a crime scene investigator collects samples and seals them into bags. In the lab, a certified examiner opens each bag and verifies its contents against what was logged. Two people, two devices, and one shared requirement: what the system says is in the bag has to match what is actually in it.
So the challenge was not only to capture data. It was to fit the system to the physical work, giving each user the right mix of speed, guidance and flexibility for their situation.
I had no access to real investigators, so I was explicit about what my research could and could not tell me.
I used a chain of three Claude skills, each with a human checkpoint:
turned the brief into a list of open questions. I reviewed and sharpened them.
produced synthetic research insights from those questions. I checked the findings against relevant public sources and sent it back where they did not hold up.
turned the validated insights into a proto-persona and a UX/UI basis for the flows.
The result is a proto-persona, not a researched one. It gave me assumptions to design against and, just as important, a list of what I would need to validate with real users.
Ron, crime scene investigator (proto-persona). 14 years in the field. Skilled at his work, not a tech enthusiast. He trusts simple, robust tools and is wary of anything that could put the legal admissibility of evidence at risk.
Double documentation
He writes on paper first and types it into the system later, which invites transcription errors.
Gloves and daylight
He needs large touch targets and strong contrast on a rugged tablet.
Incomplete information
At the scene a sample often has only an ID. Who it belongs to is sometimes known only later, in the lab.
Both field screens follow the order in which the work happens at the scene: identify first, describe later. Instead of one generic “add evidence” form, each evidence type gets its own action. The investigator picks what he is holding, and the screen asks only for what that type needs.
By the time Ron documents a sample, the swab is already sealed. The one thing he has in hand for certain is its ID, so the swab ID comes first.
Scan or type, one field. Scanning the barcode is the fast path; typing is the fallback for a damaged label. Both feed the same field, so the scanned number stays visible for him to verify.
Large, touch-friendly fields that work with gloves.
Free-text notes for anything the structured fields miss.
Here the print is captured with a reader connected to the tablet, not lifted from an object. So the capture step comes first, and it shows the reader’s connection status. If the reader is disconnected, the screen says so and capture cannot start.
After capture, Ron marks which finger was sampled, then fills in the subject’s details.
The decision I would test first
I made the subject’s details optional on both screens. At the scene, the person a sample came from is often unknown, and a required field would force Ron to invent data or stop working. The cost is weaker data completeness. This is the trade-off I would validate first with real investigators.
In the lab the job flips: the examiner is no longer recording what exists, but checking that the record matches the bag. The desktop suits this work, with a keyboard, a mouse, and a scanner at hand.
Scanning the bag’s barcode is the first action, so it sits at the center of the screen as the primary button. But not every visit starts a new bag. An examiner often handles several bags at once and comes back to one that was opened but not finished. A Bags in progress list below the scan gives one-click access back to unfinished work.
Lab work gets interrupted, so the screens are built to let the examiner leave a bag midway and come back to it: unfinished bags stay in the list, and several bags can stay open in tabs.
The screen is built for one question: does what is in the bag match what is in the system?
A summary strip at the top: bag ID, status, case number, collection time, item count, and the investigator who collected it, so the examiner knows who to call if something does not match.
Item list on one side, documentation on the other. The list shows the whole bag at a glance, with a progress counter of items handled.
Exceptions only. Only verified and missing items are marked. Marking every item would bury the two states the examiner needs to act on.
Both kinds of mismatch. The bag on the table and the record on screen can disagree in two ways, and each has its own action. An item in the bag but not in the system can be added manually. An item in the system but not in the bag can be marked as missing.
Fields by category. Each item type shows only its relevant fields, split into two groups, Identification and Condition, with dropdowns instead of free text to reduce errors. What is already known, the barcode and category, appears in the current item’s header as values rather than as fields to fill again.
The flow follows the physical work: the examiner takes an item out, finds it in the list, fills in its details and saves. The system then moves straight to the next item.
The research was synthetic, so these are open questions, not findings.
do investigators fill them in later, or do the gaps stay open?
do investigators pick the finger before scanning or after?
do examiners start from the list or from the physical item?
Ron needs to work offline and sync later. Showing connection and sync status is my next design step.