The starting point
doinstruct delivers compliance-relevant training. But before any company can train, they first need to know: what hazards exist in the workplace? Who is exposed to them? What protective measures and training follow from that?
This Gefährdungsbeurteilung (risk assessment) is legally required, audit-relevant, and aimed at managers — not employees. At many customers, it still happens manually — in Excel, Word, or through external consultants.
The strategic thesis: whoever maps the entire path from hazard to training in one system becomes the system of record for compliance from day one. Larger deals, stronger lock-in. A big, risky bet in a technically deep, regulated field — exactly the wrong place for assumptions.
Field research: shadowing on-site
The core of the project. I accompanied an external consultant who was creating risk assessments and operating instructions on-site at another company — and documented the entire process live. Instead of being told how a risk assessment is created, I saw how it’s actually done: which steps in which order, which tools, where it breaks down, which information comes from where, and where the work becomes fragmented or error-prone.
My guiding question throughout: at which points does it make sense to digitise this process — and where not? This first-hand observation became the foundation for everything that followed.
How a risk assessment is created in practice
Understanding the domain
A risk assessment is technically demanding. I worked through the field thoroughly enough to structure the complete setup myself: the assessment types (organisational, activity-based, machinery, maternity protection, psychological), the three parts of an assessment, risk evaluation via the parameters frequency, probability and consequence, and the derivation of protective measures following the STOP principle (Substitution → Technical → Organisational → Personal).
Domain Knowledge — Risk Assessment Framework
The most valuable outcome of the field research wasn't a list of pain points — it was understanding which parts of the process are actually digitisable and which aren't. Some steps require human judgment that no software can replace. Knowing the boundary made the design decisions much clearer.
From discovery to prototype
From the discovery I built a Figma prototype for risk assessment in doinstruct — deliberately in German, because I tested it directly with German customers and partners. Critically: I didn’t test once and move on. I iterated the prototype on-site with users across multiple rounds between observation, adjustment and re-testing.
The competitive analysis of an established market tool showed where doinstruct could differentiate — not by replicating a complex enterprise solution, but by making the process accessible for the managers who actually have to do it.
Prototype Flow — GBU in doinstruct
The prototype is interactive — explore the full risk assessment flow yourself.
Open prototype →Built in Figma Make · German interface · click-through prototype
Impact
A large, unclear business question became a solid decision basis and a prototype tested with real users. Because the insights came from direct field observation — not assumptions — the recommendation stood on firm ground.
Notable: the need independently surfaced in a sales survey as an ROI lever — my discovery aligned with real deal signals from sales.
On entering an unfamiliar domain
This project required me to become genuinely competent in a domain I knew nothing about — fast. Not surface-level familiar, but deep enough to know what the software had to handle, what it couldn’t, and where the user’s judgment was irreplaceable.
That combination of field research and domain learning is what made the prototype credible. It wasn’t a designer’s interpretation of a complex process — it was built from direct observation of how that process actually works.