Author Proof
An LMS-integrated integrity tool that verifies authorship through personalized comprehension quizzes generated from each student's own submission.
- Seconds
- From submission to quiz, instead of about ten minutes
- One view
- The score lands beside the submission the instructor is already grading
- 4–6 weeks
- Concept to production-ready MVP
- Company
- Proctorio
- Role
- Staff Product Designer, end to end
- Type
- New Product, MVP
- End-to-end Product Design
- Prototyping
- Accessibility
- Figma
- Claude Code
Problem
Plagiarism detectors analyze the document, not the student. A paraphrase, an AI rewrite, or a ghostwriter pass clears every existing check. Instructors had no scalable way to verify authorship inside their Canvas workflow.
Task
Take a new product from an assigned brief to a shippable MVP inside Canvas, without adding a single step to the instructor's grading workflow.
Process
Mapped the intended flow step by step and pressure-tested each step against what the platform could actually do. Four constraints came out, each one a design problem in disguise, and the answer was a smaller, faster flow rather than a workaround for each.
Did you write this?
Existing integrity tools answer one question: is this original? None of them answer the one instructors actually care about: did you write this?
Author Proof asks that question directly. When a student submits written work, it generates a short comprehension quiz from the student's own writing, in the submission's own language. Someone who wrote the paper can answer questions about it. Someone who didn't, can't. The result surfaces as a score badge beside the submission, where instructors already grade, with a link out to the full session for anyone who wants the question-level detail.
Four constraints, each a design problem in disguise
The product arrived with its architecture already chosen: submit through the LMS as normal, generate questions, create a quiz in the LMS's own quiz tooling, assign it to that one student, and notify them. Before engineering committed time to it, I mapped that flow step by step and tested each step against what the platform could actually do.
- Timing. Fetch, generate, create, assign, notify added up to roughly ten minutes between submission and quiz. That gap is exactly the window a student needs to pull their essay back up, so the architecture was quietly undermining the one thing the product is supposed to prove.
- The quiz tooling is one-to-many. It assumes a quiz is authored once and assigned to a class. A fresh quiz per submission fights that assumption at every step, and gets fragile when a whole class submits at once.
- Notifications are not dependable. Students can turn them off, the inbox is rarely checked, and email timing varies by institution. The fallback would have been "instructors remind students," which puts the burden on the exact person we were trying to help.
- Two disconnected things to grade. A separate quiz item meant the submission and the quiz would live in different places, with no unified view.
A smaller flow that kept the promise
Rather than report the blockers, I pitched an alternative and split it into an MVP and a longer vision. The MVP embeds Author Proof in the assignment itself: the student starts the assignment, uploads their essay, and the quiz appears seconds later. That one move collapsed the timing gap, removed the notification dependency, and stepped out of the quiz tooling entirely. The result is written back beside the submission, so the instructor reads one thing, not two.
I was also clear about what the pitch cost. It excluded short pieces written directly in the LMS editor, and it left an open question about how proctoring would coexist with the embedded flow. I would rather flag the hole myself than have engineering find it. The longer-vision pieces were parked on a roadmap rather than dropped.
Confidence, not verdict
The product had to read as evidence for a human conversation, never an automated judgment. Three rules followed from that:
- No binary pass or fail. A score is shown with a confidence level, and the instructor decides what to do with it.
- Transparency into what was evaluated. Every generated question sits next to the student's own words that prompted it, and next to the assessment of the answer, so a score can be traced back to something a person can read.
- Never color alone. The host platform controls the badge color and maps it the opposite way from the score, so the score, label, and confidence are always carried as text.
The prototype was the spec
I led design end to end on a four-to-six-week timeline from concept to production, and handed engineering working prototypes in HTML, CSS, and vanilla JS rather than a document about them. Surfaces included the quiz-settings panel inside the assignment editor, the student quiz flow, and the results pathway from badge to session detail.
What I'd do next
- Prototype the embedded flow alongside a proctored session earlier, so that open question gets resolved before the direction decision instead of after.
- Let instructors review generated questions before they reach a student.
- A per-language quiz picker, beyond the submission-language default.