Anudeep
All work
Enterprise SaaS · Design Systems2025·Product Designer — design system & UI

Restyling an ERP that 4 years of muscle memory depended on

A complete visual rebuild of a live open-source ERP — without moving a single control, changing a flow, or touching the core code or database.

RelatedPI-ERP in 2026: role-based UX at scale

FigmaAtlassian Design SystemDesign TokensiDempiere
Live demo
Role
Product designer — design-system research, UI system, full screen restyle
Timeline
2025 · delivered in a sprint
Team
Me, with PIPRA's engineering team · brief from my manager and CEO
Platform
Web — enterprise ERP on iDempiere
Status
Shipped — in use by the team and clients

The problem

PI-ERP runs on iDempiere, whose stock interface the team and clients had used daily for four years. Leadership wanted a modern UI in a sprint — but the user flow, core code and database could not change.

The outcome

A complete visual rebuild on the Atlassian Design System, with every control left exactly where four years of muscle memory expected it — so nobody had to be retrained.

If you read nothing else

01

The hard part wasn't designing a new UI — it was deciding how much to leave alone. Every gadget, tab and control kept its position.

02

I evaluated Carbon, Material and Atlassian against a genuinely data-dense enterprise product, and chose Atlassian because it's built for exactly this density.

03

Constraint-driven: no changes to user flow, core code or database. The redesign had to be purely a visual layer.

The people using this ERP had used the same screens every working day for four years. Any redesign that made them stop and look for something would cost more than the redesign was worth.

The brief

Modernise it — but don't break anyone's day

PI-ERP is built on iDempiere, a mature open-source ERP. It works, it's deep, and it looks its age: dense grey chrome, tiny controls, and a visual language that hadn't moved in years. My manager and CEO wanted it modernised, in a sprint.

The constraints came with the brief and they were absolute. The user flow could not change. The core code could not change. The database could not change. Clients were live on this system, running their businesses through it, today.

The reframe

The best redesign here is the one nobody has to learn

Four years of daily use builds real motor memory — people reach for controls without reading them. A redesign that relocates things resets that to zero and taxes every user with relearning, which shows up as support load and change aversion long before it shows up as praise. So I inverted the usual goal: keep the spatial model perfectly intact, and change only the material it's made of.

Method

Choosing a design system for genuine data density

Design-system evaluationAssessed IBM Carbon, Material UI and the Atlassian Design System against real PI-ERP screens — dense grids, deep forms, multi-level menus — rather than against marketing examples.
Interface auditWent through the existing iDempiere UI screen by screen, cataloguing every component type and its position so the restyle could be mapped one-to-one.

What it told me

  • Material's generous spacing and motion suit consumer products, but cost too many rows on screens where density is the point.
  • Carbon is genuinely strong for enterprise data, but its visual language is distinctive enough to read as IBM's rather than ours.
  • Atlassian's system is built for exactly this problem — tool-like, dense, calm, and designed around tables, forms and nested navigation that people live in all day.

Design principles

The rules I gave myself before touching a screen

Nothing moves

Every control keeps its position. If a user could find it with their eyes closed on Friday, they can still find it on Monday. Layout is treated as a contract, not a canvas.

Restyle, never rebuild

The change is a visual layer over untouched logic. No flow gets shortened, no step gets merged, no field gets moved — however tempting the improvement looks.

Density is a feature

This is a tool people work in for eight hours. Whitespace that costs visible rows is a downgrade, so the system had to breathe without pushing content off screen.

Before and after

The same dashboard, rebuilt

The proof

Look at what stayed exactly where it was

Activities, Calendar, Donate and Performance sit in the same order, in the same columns, with the same collapse and expand controls in the same corners. The Views panel is still beneath them. The tab still says Dashboard (1). Every number is identical. What changed is the typography, the spacing rhythm, the control styling, the count badges, and a navigation sidebar that finally shows the module structure — MRO, Manufacturing, Material Management, Project Management — instead of hiding it behind a menu.

Login — before.
Login — before.
Login — after: PiERP identity, Atlassian form patterns.
Login — after: PiERP identity, Atlassian form patterns.
Business partner grid — before.
Business partner grid — before.
Business partner grid — after: same columns, readable density.
Business partner grid — after: same columns, readable density.
List view — before.
List view — before.
List view — after.
List view — after.
Reports — before.
Reports — before.
Reports — after.
Reports — after.
Dashboard gadget modal — before.
Dashboard gadget modal — before.
Dashboard gadget modal — after.
Dashboard gadget modal — after.
Main menu — before.
Main menu — before.
Main menu — after: hierarchy made visible.
Main menu — after: hierarchy made visible.

Key decisions

The calls that made it safe to ship

Atlassian Design System over Carbon or Material

WhyChosen for density, not taste. Atlassian is designed for tool-like products full of tables, forms and nested navigation — the exact shape of an ERP. Material would have cost rows to spacing; Carbon would have made the product read as IBM's rather than ours.

Preserve every control position

WhyJakob's Law cuts both ways: users build expectations from what they already use, and for these people that's this app, every day, for four years. Keeping the spatial model intact means recognition still does the work and nothing has to be relearned.

Ship it as a visual layer, not a rewrite

WhyThe core code and database were off-limits, and honestly that was the right call — a rewrite would have put a working, revenue-generating system at risk for a cosmetic gain. Treating the UI as a swappable layer kept the blast radius to pixels.

Surface the module hierarchy in the sidebar

WhyThe one place I did add rather than restyle. The modules always existed but lived behind a menu; exposing them as persistent navigation improves information scent without moving anything that was already on screen.

Resist the improvements I could see

WhyThere were flows I'd have shortened and fields I'd have regrouped. Every one of those was out of scope by definition — and shipping a restyle that nobody has to learn is worth more to a live client base than a better flow they'd have to be retrained on.

The original iDempiere interface — the product as the team and clients had used it for four years.
Shipped
The rebuilt PiERP interface — same structure, same flows, entirely new visual language.

Where it stands

0 flows changed
user journeys, core code and database left untouched
1 sprint
from brief to a fully restyled interface
4 years
of existing muscle memory preserved
Shipped
in use by the team and clients

What I took from it

Restraint is a design skill

It would have been easier, and more fun, to redesign this properly — new flows, fewer steps, my own visual language. The work was in not doing that. Understanding why a constraint exists, and then designing hard inside it, produced something that shipped in a sprint and cost its users nothing to adopt. That trade is one I'd make again.