The starting point
Customers need to prove in audits that their employees have completed legally required training. Individual certificates per lesson aren’t enough: a plant manager or QA lead needs a consolidated proof across multiple completed trainings — something you can hand to an auditor without hunting down dozens of individual documents.
Compliance depth is a deliberate differentiator for doinstruct — not a side feature. A certificate feature has to live up to that: it needs to actually work as a reliable audit proof, not just look good.
From customer feedback to requirements
The starting point was real customer feedback. I gathered the recurring needs around compliance documentation and translated them into concrete requirements: what exactly does a summary certificate need to contain to hold up in an audit? Which training sessions are summarised, in what form, with which mandatory fields?
This meant the starting point wasn’t a design idea — it was a documented need.
Concept & UX flow
I designed the end-to-end flow: from the point where an admin role wants to generate a summary certificate, through selection and composition, to the finished, audit-ready document.
The central question was how the feature integrates into the existing product logic — lessons, completions, groups — without creating new friction. The feature needed to feel like a natural extension of what was already there, not a bolt-on.
UX Flow — From admin action to audit-ready document
UI design & handoff
Based on the concept I designed the UI in Figma — following the doinstruct design system and with the requirement that even non-technical admins can generate the proof without instructions. The focus was on clarity: what is being summarised, what appears on the document, how do you get there.
I handed the design off to engineering with the necessary specifications, states and edge cases — so implementation could run without back-and-forth. The feature is live today.
Thinking in compliance context
Summary Certificates doesn’t stand alone. I considered it alongside the adjacent compliance building blocks — signature confirmation, audit trail, certificate localisation — so the feature is part of a coherent proof experience rather than an isolated component.
The hardest design decision wasn't the UI — it was defining what 'summary' actually means in a compliance context. Too broad and it loses legal validity. Too narrow and it creates more work than it saves. Getting that boundary right required understanding the audit process, not just the product.
On designing compliance features
This project was a good example of how compliance features are different from regular product features. The success criteria aren’t set by user preference — they’re set by legal requirements and auditor expectations. Designing within those constraints while keeping the experience accessible for non-expert admins was the core challenge.