Cutting template creation from days → hours

Days of engineering behind every document

Organizations on the platform use forms to collect student data and generate official form outputs. Each output used a PDF template built from the form fields, which was uploaded to the system. User responses got filled into it automatically when they submitted a form.

But the workflow behind it required an engineer to recreate the form layout in external PDF tools and do the data mapping manually into the template, resulting in multiple validation cycles and back and forth before the template reached production.

This case study presents my design process behind creating a modern output builder that reduced template creation time from days to hours.

Deconstructing the problem space and execution scope

Most of the work went into understanding the legacy workflow and designing the builder around what the system and the teams could support. This case study covers the output builder, one module of a form ecosystem I designed end to end.

Where effort was actually being spent

I found that most of the time was going into mapping the response codes into the template rather than designing it.

Every answer carried its own response code. The example form below was one of the most common, and it had twenty three questions, but forty five codes to map. Every form requires at least one output with all the fields mapped by default, and larger forms ended up requiring hundreds of mappings per form.

Missing or mistyping a single code meant the field would not get filled, or worse, wrong information would be filled in on an official document.

The audit also turned up things nobody remembered the reason for. One option, File Category, had been added for a single client and carried through every build since, though no one used it and no one could explain what it did. When I traced it, it turned out to organize the generated PDFs inside the system. Since the new model does not store PDFs at all, the option had no reason to exist, and it was dropped.

From building a PDF editor to redesigning the workflow

The original requirement was simple:

“How might we make PDF creation easier?”

But once I realised that it was the manual mapping that was taking up the engineer's time, I rephrased the requirement:

“How might we remove manual mapping, so the engineers just build the layout?”

This reframing simplified the scope from building a brand new PDF editor inside the platform to a workflow redesign. By removing unnecessary steps, we would make the complex manual workflow simple. The challenge was to build it without affecting the legacy backend, and to build on the mental models users already understood.

Automating the mapping model before the interface

There are two parts to the output builder: a mapping layer and the layout builder. PDF was the container which had both of these layers packed together.

If layout is built into the system, why keep PDF as the container at all? Can't the mapping data be stored separately as data bindings? I had worked on similar mapping systems before and immediately thought of JSON as a viable alternative.

That was my theory, so I went and checked it. I reviewed the output templates built for several clients over the period and found that the design of them all followed a simple layout pattern, repetitive enough for the system to generate, while the response code changed for every single response. So, keeping the template builder decoupled from the codes will be more efficient.

{
  "Q_10235_RESPONSE": "name",
  "Q_10238_RESPONSE": "gender",
  "Q_10240_RESPONSE": "ssn"
}

I took this idea to the react team and they did a PoC based on my request and made my theory a reality. It was faster and more efficient than creating a PDF document. So we decided to adopt it. The template became a structure that the system fills on demand, which required no server side changes to the legacy backend.