Building Premium ERP Frontends
Frontend — — Ali Raza
Why internal tools deserve strong UI systems and how frontend quality changes ERP adoption.
The first ERPNext rollout I led for a municipal government nearly failed, and the backend had nothing to do with it. The DocTypes were clean, the approval workflows were airtight, the permission matrix passed every audit. But we put clerks who had spent a decade on paper directly into the raw Desk interface, and within two weeks they were keeping shadow records in Excel. That project taught me what I now say in every kickoff: in ERP work, the frontend is not polish. It is the adoption layer.
The temptation on Frappe Framework projects is to treat UI as free. Desk auto-generates forms from DocType definitions, so why spend budget there? Because Desk is a developer's view of the data model, not a user's view of their job. A hospital receptionist doing patient check-in does not need forty fields, a linked-documents sidebar, and an Amend button. She needs five fields, one large primary action, and an unmissable error when the MRN does not match.
So the first design decision on any implementation is drawing the line between Desk and portal. Power users — accountants, HR, administrators — live in Desk, and it serves them well once tuned. Everyone else gets a purpose-built frontend, usually Vue with frappe-ui, talking to the same DocTypes over the REST API. On one HR portal we replaced a Desk form with 22 visible fields with a three-tap mobile flow for Leave Application. Submissions tripled in the first quarter. Same DocType, same server-side validation, different surface.
Tuning Desk itself is underrated work, and most of it is configuration rather than code:
- Order fields the way people think, not the way they were added, and use depends_on to hide whatever is irrelevant to the current state. - Set list view columns deliberately. A queue showing status, patient, and appointment slot is a work tool; the default columns are noise. - Rename workflow states into the user's language. "Pending HOD Approval" tells an approver it is their turn; "Review Level 1" tells them nothing. - Build Workspaces per role, so a storekeeper opens the system and sees stock entries and reorder reports, not the entire module map.
Reports are UI too. A Query Report with a formatter that turns overdue municipal complaints red and adds a day counter did more for response times in that government deployment than any dashboard we shipped later. People act on what they can see ranked and colored.
Two pitfalls keep showing up in code reviews. First, overriding Desk CSS from a custom app to force a brand look — it shatters on the next bench update and bench migrate, and you inherit the maintenance forever. If a screen needs brand-level control, it belongs in a portal frontend, not in patched Desk. Second, Client Scripts that fire synchronous frappe.call on every field change. Client Scripts are guardrails and conveniences; real validation belongs in the controller or a Server Script, where it also protects API and data-import paths.
Performance is part of the UI system, because perceived speed drives adoption more than any visual choice. On a healthcare deployment running over hospital Wi-Fi, we cut a check-in screen's load from six seconds to under two by requesting only the fields we actually rendered in get_list calls, caching the practitioner list, and shipping skeleton states so the page never sat blank. Nurses stopped calling it "the slow system," which mattered more than the milliseconds.
Finally, measure adoption like a feature. I track logins by role, records created at the source versus back-entered by admins later, and whether the shadow spreadsheets die. When the numbers entered at the counter climb and the Excel exports stop, the frontend is doing its job. ERPNext gives you a complete backend out of the box; the implementations that survive are the ones where someone treated the screens people touch every day as a product, not a byproduct.