Lessons from Digitizing a Real Business Workflow
What I learned building a document automation platform: the gap between requirements and reality, and how user feedback shaped the product.
The Setup
My PFE at Axians was to build a workflow digitization platform — a web application to replace manual paperwork. I had a brief, a tech stack decision, and six months.
Lesson 1: Requirements Are a Sketch, Not a Blueprint
Two weeks in, after showing early mockups to actual users, I learned the brief captured intent, not reality. Reality came from the people doing the work.
Lesson 2: The First Version Will Be Wrong
My first UI attempt was logically correct and unusable in practice. I watched one of the assistants try to use it. She hesitated at every step — not because she was not technical, but because the flow did not match how she thought about her work.
I rebuilt the main flow around her mental model, not mine.
Lesson 3: Data Modeling Is the Most Important Decision
I rebuilt the document template association system twice. The first version hardcoded which templates applied to which intervention types. The second used a flexible mapping table that just needed a database row for new contract types.
Five minutes of thinking about future requirements before building saved a week of refactoring later.
Lesson 4: PDF Generation Is Harder Than It Looks
The PDF had to match existing paper formats exactly (regulatory requirement). Dynamic content needed layout reflow. I ended up building a template engine that mapped database fields to PDF positions.
Lesson 5: Adoption Is Part of the Deliverable
A system that works but that nobody uses has failed, regardless of code quality.
By the end of the internship, the people I had built the system for were using it voluntarily for covered workflows.
In Summary
Build with the people who will use it. Model the data for change. Measure success by adoption, not feature completion.