Nea

The problem

Moving into transport exposed poor usability for non-technical users, flows that didn't fit routes, per diems and field work, visual inconsistencies, fragmented information and no native support for teams or multiple companies. Clients used spreadsheets to compensate.

Constraints and design principles

• Multi-company support as a critical need.
• Three roles (admin, cardholder and observer) needing different views of the same entities.
• A small engineering team, so changes had to be incremental and reusable.
• Mobile support, since many users work on the road.
• No room to change models, endpoints or business rules; new logic had to live in the front end.

Within that room, three principles guided the design: simplify for non-technical users, differentiate experiences by role and build new logic on the existing infrastructure.

Multi-company

A persistent company selector switches the context of the whole platform while keeping the current module, filters and views.

Budgets

Modeled as a hierarchy: Company → Area → Operator or Team → Card. The creation flow covers basic setup, rules and permissions, members, duration and recurrence, and a final review on mobile and desktop. The detail view shows available versus spent, category breakdowns, members, linked transactions and controlled adjustments.

Transactions

Organized into Purchases, Commissions and Deposits. Purchase details have normal, expanded and rejected states, with the rejection cause stated explicitly. Accounting gets custom fields, accounting metadata and XML (SAT) management inside the same flow.

Users

Adding a user happens in a side drawer over the list. On desktop it keeps the context in view; on mobile the same pattern adapts to the screen width, which helps the responsive side without designing a separate flow.

Impact

Transport clients could model their operations, and operators and admins better understood spending rules. Transaction and XML review became part of period closing. The design system reduced visual patching, support reported fewer questions and sales had a clearer story for acquisition. I didn't measure ticket reduction or training time rigorously, and I'd call that out as a limitation.

What I take from it

Nea changed a lot in three years: it went from a platform for finance teams to one that also runs the operations of transport companies. That leap was teamwork; I worked alongside the lead designer, the design systems team and the branding team, and every decision built on what the others had already made.

What I take from it is that constraints, even hard ones, don't stop a product from evolving when you design with them: without touching the backend, multi-company support and budgets were solved from the front end, with small, reusable changes.