Skip to content
Debbie
Back to Project Delivery
Real project

AI Essay Marker

From interface concept to a working, teacher-facing AI workflow.

Role
Product design and hands-on technical delivery
Duration
June–October 2023
Project context
Marquis Education · teacher-facing product

Real work completed at Marquis Education in 2023; documented retrospectively from available first-person and documentary evidence.

At a glance

20
Maximum essay mark returned

Alongside detailed feedback

2
Input routes

Upload or paste

4 mo
Approximate delivery period
0
Real student essays used in development testing
01

The brief

Marquis Education wanted a teacher-facing tool that could accept essay content and return a mark out of 20, detailed feedback and line-by-line suggestions. I took the work from an interface idea into a functioning Bubble product connected to OpenAI.

The delivery challenge was not simply making an API respond. Bubble was new to me, the marking instructions needed repeated refinement, and the result still had to support a teacher’s judgement rather than present an AI recommendation as a final grade.

02

The starting point

The original Figma file, prompt versions and formal test records no longer survive. The evidence does establish the product behaviour, the technology used and my remembered delivery responsibilities, so this room distinguishes verified facts from retrospective reconstruction.

2
teacher input routes

Upload or paste

/20
overall mark returned
3
output layers

Mark, feedback, line-level suggestions

0
real student essays used by me in development
03

What I was responsible for

  • I translated the teacher-marking idea into a core submit-to-result journey and created the initial Figma mock-up.
  • I learned Bubble, built and debugged the application, configured the OpenAI connection and wrote the marking instructions.
  • I tested repeated and varied inputs, reviewed the outputs and changed the instructions when behaviour was inconsistent or unhelpful.
  • I incorporated review from the founder and project manager, including teacher feedback relayed through them.
  • I wrote usage guidance, trained the project manager and handed over the working product. I did not hold the formal Project Manager title or train teachers directly.
  • Requirements translation
  • Figma
  • Bubble
  • AI instruction design
  • Testing
  • Handover
04

How I structured the project

  1. June 2023

    Frame

    Clarified the teacher journey and represented the concept in Figma.

    Stage 1 of 5

  2. Summer 2023

    Build

    Learned Bubble while translating the core flow into a working application.

    Stage 2 of 5

  3. During build

    Connect

    Configured OpenAI processing and structured the requested marking output.

    Stage 3 of 5

  4. Iterative

    Test and refine

    Repeated inputs, varied the material, inspected behaviour and revised instructions.

    Stage 4 of 5

  5. Around October 2023

    Transfer

    Prepared usage guidance, trained the project manager and handed over.

    Stage 5 of 5
05

The hard part

A response was not the same as a dependable product.

The integration could return text before the experience was ready. I had to look at whether the answer contained the expected parts, stayed relevant to the submitted material and behaved consistently enough to support a human reviewer.

No preserved benchmark set or quantitative accuracy measure exists, so I do not convert that qualitative testing into a percentage. The evidence is the working flow, the repeated refinement loop and the handover boundary.

06

Key decisions

Decision 01

Design the teacher journey before building it

Context
The product needed a clear route from essay input to reviewable output.
Options
Build directly in Bubble, or first make the flow visible in Figma.
Decision
I created the interface concept in Figma before translating it into Bubble.
Why
It gave the build a usable structure while I was still learning the platform.
Consequence
The product moved from concept into an implemented teacher-facing flow; exact historical screens are not reconstructed here.

Decision 02

Treat the model response as product behaviour

Context
Technically valid responses still varied in structure and usefulness.
Options
Accept the first successful integration, or keep testing and refine the instructions.
Decision
I repeated the same input, tried different public texts and revised the marking instructions.
Why
Teachers needed recognisable outputs, not merely generated text.
Consequence
The mark, detailed feedback and line-level suggestions became the stable structure used for review and handover.

Decision 03

Keep the human judgement boundary visible

Context
A numerical mark can appear more authoritative than the evidence supports.
Options
Present an automated grade, or position the output as support for a teacher.
Decision
I treated the AI output as a recommendation within a teacher-facing workflow.
Why
Educational judgement and accountability remained human.
Consequence
This case makes no accuracy, autonomous-grading or learning-outcome claim.
07

Project control

  • The retrospective requirements register contains 20 controlled requirements: seven functional, six AI-behaviour, two usability, three non-functional and two handover requirements.
  • The requirements-to-evidence matrix separates verified product capability, direct recollection and present-day controls I would now require.
  • Known gaps—model version, prompt history, formal privacy controls, signed UAT and usage volumes—remain visible rather than being filled with assumptions.
08

Testing and assurance

I used public research papers and excerpts from children’s books during development, not real student essays. I checked repeated inputs, varied inputs, output structure and instruction adherence qualitatively, then incorporated stakeholder review.

  • Same-input testing was used to inspect variation.
  • Different public texts were used to exercise more than one example.
  • Founder and project-manager review informed iteration.
  • Teacher evaluation reached me indirectly; no direct teacher research claim is made.
09

From working build to operational ownership

I debugged the core submit-to-result journey until the working product could be demonstrated. I then wrote usage instructions and trained the project manager who would receive the product.

The exact release classification, acceptance signature and later technical owner are not established. My delivery involvement ended after handover around October 2023, and I had no ongoing maintenance responsibility.

10

What happened

Verified real work / retrospective evidence

Delivered

Working teacher-facing product

Verified product capability

Mark + detailed feedback + line-level suggestions

Output structure

Direct retrospective recollection

Completed

Operational handover

No surviving quantitative evidence

Not claimed

Accuracy, adoption and time saved

11 · Evidence gallery

These are readable web-native representations of the source artefacts—not fake software screenshots. Open any item for a larger view and its source reference.

12

What I learned

A model returning an answer is not the same as a usable feature. Behaviour, structure and the human decision boundary belong inside product quality.

Today I would keep versioned prompts and models, use a rights-cleared evaluation set agreed with qualified educators, quantify repeat-run variation and document privacy and retention before release.

Previous case ClinicFlowBack to DeliveryNext caseCRM Migration