Abhishek Roka
Abhishek Roka

Why I'm Replacing Django Admin with a Dedicated Dashboard in My Placement Portal

After my first stakeholder meeting with the Head of my Department and the Placement Coordinator, one requirement kept coming back to me.

The Placement Officer needed to create dynamic application forms for individual job postings.

Different companies have different requirements.

One company might want:

Another might ask for:

A fixed application form wouldn't work.

The Placement Officer needs the flexibility to create the fields required for each job.

That immediately raised a more interesting question for me:

What should creating those fields actually feel like for the person using the system?

And that's where my thinking started to change.

I Stopped Thinking About Models

As a backend developer, my first instinct was to think about the implementation.

I could create an attribute model.

I could connect those attributes to a job.

I could use Django Admin inline forms.

Technically, the problem could be solved.

But after my stakeholder meeting, I realized that technical feasibility wasn't the only question.

I needed to think about the person who would actually use the feature.

The Placement Officer doesn't care that I'm using Django.

They don't care how the database relationships work.

They need to create a job and define what information applicants should provide.

So before building the interface, I decided to study an experience that already solves a similar problem well.

Google Forms Became My UX Reference

Instead of immediately opening my code editor, I opened Google Forms.

I created a sample form.

I experimented with different field types.

I uploaded a file.

I moved through the workflow as if I were the person creating the form.

What stood out to me wasn't simply the number of features.

It was how little effort was required to understand the interface.

I didn't need to read documentation before creating a form.

The interface itself guided me.

That led me to an important principle:

Users shouldn't have to understand the technology behind a product to use the product effectively.

The Real Challenge Isn't Building a Form

I could reproduce the technical functionality of a form builder.

But that's not the actual challenge.

The real challenge is building an experience that helps a Placement Officer complete their work quickly.

Their workflow is something like:

Create Job
    ↓
Define Eligibility
    ↓
Add Application Fields
    ↓
Publish Job
    ↓
Review Applications
    ↓
Manage Recruitment

The user is thinking about placement management.

My software architecture should support that mental model.

It shouldn't force the user to think in terms of database models, inline forms, or framework concepts.

Should I Just Extend Django Admin?

One obvious option was to continue using Django Admin.

And honestly, there are good reasons to consider it.

Django Admin already provides:

For internal administration, that's incredibly useful.

I could potentially build the dynamic form functionality using Django Admin inline forms and get the feature working much faster.

But then I asked myself:

Would a Placement Officer understand what an inline form is?

They shouldn't need to.

That's where I started seeing the difference between an administration interface and a product interface.

Django Admin and a Product Dashboard Serve Different Users

Django Admin is extremely useful.

But its purpose is different from what I'm trying to build for placement staff.

Django Admin is primarily designed around managing application data and models.

A Placement Officer is trying to manage a recruitment process.

Those are different mental models.

For example, I don't want the user to think:

"I need to edit the JobAttribute model."

I want them to think:

"I need to add a 10th percentage field to this company's application form."

The second statement represents the actual business workflow.

That's the interface I want to build.

The Dedicated Dashboard

The alternative is to build a dedicated dashboard for university staff.

Instead of exposing the underlying Django structure, the dashboard would be designed around their responsibilities.

It could provide workflows for:

The difference isn't necessarily what the backend can do.

The difference is how that capability is presented to the user.

Designing Around the User's Mental Model

This is probably the biggest lesson I've taken from the process.

As developers, we naturally think in terms of implementation.

We ask:

"How can I build this?"

But product development requires another question:

"How does the user think about this?"

A Placement Officer doesn't think:

"I need to create an EAV relationship."

They think:

"The company wants candidates with a minimum CGPA of 7.5."

They don't think:

"I need to create another model instance."

They think:

"I need to add a CGPA field to the application form."

The software should translate between those two worlds.

My Current Direction

The more I think through the stakeholder requirements and the user experience, the more convinced I am that Django Admin should remain primarily an internal administrative tool.

It can continue to be useful for:

But the day-to-day placement workflow deserves its own interface.

That means building a dedicated dashboard designed specifically for the people managing placements.

It gives me much more control over:

Most importantly, it lets me design around the user's work instead of designing around the framework.

What Google Forms Actually Taught Me

The lesson I took from Google Forms wasn't:

"I should copy Google Forms."

It was:

"I should study why the experience feels easy."

That's an important distinction.

Good products don't necessarily win because they have more features.

They often win because users can accomplish their goals without thinking about the complexity underneath.

That's the experience I want to bring to my Placement Portal.

Final Thoughts

This decision started with a technical question:

"How should I implement dynamic application forms?"

It eventually became a product question:

"Who is going to use this, and how should the experience feel?"

That shift changed my approach.

Django Admin can help me manage the application.

But it doesn't necessarily have to become the application that my users interact with every day.

The backend should expose the capabilities.

The dashboard should expose the experience.

And that's the direction I'm taking with my Placement Portal.

Because users don't remember which framework powers a product.

They remember how easy—or difficult—it was to get their work done.

— Abhishek Roka