For years, ERP design was synonymous with having to line up menus, forms and reports to give finance, HR and operations teams their own space in the system.
This isn’t all work anymore.
The interfaces built on top of ERP systems are becoming intelligent, recommender, and action takers in 2026. This change is driving a rethinking of what good ERP design really means.
This is most important for the ones who have to sign the cheque for the system, business owners and finance leads who will be responsible to justify an ERP investment against actual operational risk. For them, bad design is no aesthetic issue. The difference between what your team uses and a six-figure shelfware.
What Is ERP Design?
ERP design is the art of shaping the relationship between the users and ERP. It covers the navigation, dashboards, workflows, permissions and data visualization that lie in the space between the business data and the person seeking to use it.
From checking stock levels on a tablet in a warehouse to creating a quarterly VAT report by the finance director.
It’s important to get the terminology right, as vendors often do and it also carries real cost consequences.
ERP Design vs. ERP Configuration vs. ERP Customisation
Term | What It Means | Who Does It | Risk Level |
ERP Design | Structuring workflows, navigation, dashboards, and user experience around how the business actually operates | Vendor/implementation team, with business input | Low, reversible with iteration |
ERP Configuration | Setting parameters within the existing system (tax codes, approval limits, chart of accounts) without altering code | Implementation consultants | Low, built into the platform |
ERP Customisation | Writing custom code to change core system behaviour beyond what configuration allows | Developers | High, can break with every future upgrade |
Ask a vendor if they are offering heavy customization as a solution to a design question, first ask if it can be accomplished via configuration. The cost of customisation is big and the cost of maintaining any customisation is huge when the platform gets a new update.
Why ERP Design Matters for Growing UK Businesses
About 25% of ERP implementations are over budget. It’s not the software, but the gaps in the technology, staffing and organisation which is always the root cause.
Any mismatch of the interface and how people work leads to the creation of workarounds in spreadsheets by the staff. Data quality drops. Business decisions based on the reporting of an owner become unreliable.
That risk escalates rapidly for an expanding UK SME. With a rapidly growing UK SME, that risk can rapidly build up. Not only software, it’s visibility of the business that prepares for cash flow, inventory management software and ensures compliance as heads and transactions increase.
The poor system is not only a waste of time but it is a liability to the system. It quietly damages the quality of the data on which all reports, forecasts and audits are based.
If your team has been exporting data to a spreadsheet to make it usable on a regular basis, then it is a design issue, not a training one. The user interface is only fixable with user training, not when it doesn’t match the workflow..
How ERP Design Works: The Step-by-Step Process
The right Erp design ui/ux process has a clear trajectory, regardless of the vendor’s labeling, such as discovery or double diamond.
Step 1: Research & Discovery (User & Process Mapping)
This involves mapping actual roles and processes of users and not assumed. It’s the simulation of a purchase order from the moment it’s requested until it’s paid, not as shown in the purchase order process diagram.
Discovery will bring informal workarounds to light that your team uses. Those are typically the best indicators of failure of the current system (or, if poorly designed, of the incoming system).
Step 2: Defining Goals & Requirements
This step converts discovery findings into a set of specific design requirements such as: Who should be assigned to which dashboards, What is the approval chain, Where are compliance checkpoints located.
This is also the place for setting measurable goals for the adoption of the business. Not only go live by Q3, but usage and data-quality metrics to measure against after go live.
Step 3: Ideation & Information Architecture
In this case, the relationships between navigation and modules are structured and data across the system is related and interdependent, rather than in silos.
This is one of the most prevalent and correctable reasons for low adoption rates, especially poor information architecture. A user doesn’t quit a workflow because there’s a feature he or she doesn’t have, it is because it is three menus deep.
Step 4: Prototyping & Testing
Real users should be used to test workflows before go-live to surface friction points, and make changes at a low cost.
This is the one thing that is often neglected or rushed through the time limit. Also it is the point at which the best value for money fixes occur as a change in a prototype is a small amount of the cost of a change after launch.
Step 5: Implementation, Launch & Support
Rolling out involves training, monitoring and, crucially, considering design as a process instead of a one-off development completed at the point of go-live.
Vendors who treat design as a fixed deliverable rather than a continuous process are the ones you’ll be calling back in eighteen months for a costly redesign.
ERP Design Best Practices
The best-designed ERP systems share a small set of recurring traits.
Simple, Role-Based Navigation
All users should only see what is pertinent to their role. A warehouse man doesn’t need to find the general ledger in his menu and a finance director shouldn’t have to search the production schedule for a VAT report.
Role-based navigation isn’t a ‘nice to have’. It’s also a data integrity control, as it will restrict the number of people who can accidentally touch data outside their scope of responsibility.
Customisable Dashboards & Data Visualisation
A real-time dashboard with information on cash position, stock levels or outstanding invoices that can be seen at a single glance can make an ERP system a system of decision.
The aim is NOT to display more information on the screen. It’s the proper three or 4 numbers a certain role demands to act upon these days.
Search, Filtering & Findability
Quick filtering and searching becomes an important functionality as transaction volumes increase, and as much as the model itself. It’s easy to underestimate in a demo where the sample data is clean, and it will hurt to find out is missing once you’ve 3 years of transaction data for your business.
Security & Role-Based Access Design
Access control is more than a matter of IT. It’s a design decision. The interface should enable the processing of approval for payment, editing of a purchase order and export of customer information, not be implemented as an addition after the fact.
AI-Driven & Agentic ERP Design (2026 Trend)
It is here that things are moving the quickest. Until now, most ERP intelligence has been analytics, meaning dashboards were used to tell you what had happened.
Agentic AI takes it one step further. All of these steps can now be automated in a system, with an abnormal invoice flagged, a reorder can also be pre-prepared before stock is low, while a discrepancy can be checked and routed for approval without any human steps.
Now there’s the level of autonomy that this agent can have, how to recommend them and of course how a human should still be in the loop for anything money or compliance related. How does it look like a human’s decision point is located and is there a direct view of it such that no one accidentally rubber-stamps it.
Every agentic AI action that touches money, stock levels, or compliance data should have a visible reason , a short explanation of what triggered the recommendation, not just an approve/reject button.
Common ERP Design Mistakes That Cause Failed Implementations
- Designing for the org chart, not the workflow. Mirroring departmental structure in the interface instead of how work actually flows between departments.
- Over-customising early. Locking in bespoke code before the business has used the standard system long enough to know what it actually needs.
- Ignoring mobile and field use. Many SME teams, especially in manufacturing and Distribution erp software, need functional access from a warehouse floor or a delivery van, not just a desktop.
- Treating compliance as an afterthought. Retrofitting tax or audit requirements after the interface is built is far more expensive than designing for them from day one.
- No feedback loop post-launch. Adoption data, login frequency, workflow abandonment, support tickets, is rarely reviewed after go-live, so design problems go undetected for months.
- Underestimating data migration. Design decisions made without ERP Accounting Software for the state of legacy data often force a second, unplanned redesign once real data hits the new system.
- Skipping a formal sign-off on requirements. When what the system should do is agreed verbally rather than documented, scope drifts during build, and the design ends up reflecting whoever spoke loudest in the last meeting.
- Confusing a demo environment with reality. Vendor demos typically run on clean, low-volume sample data. A dashboard that loads instantly in a demo can behave very differently once it’s filtering three years of live transaction history, worth testing explicitly before sign-off, not assumed to scale.
These patterns manifest themselves in all sizes of implementation, but they magnify in SMEs, where there is typically no project team within the organization to catch issues early. That’s one of the reasons why the vendor relationship and the amount of design ownership they have versus holding onto it becomes more important for smaller companies than large companies with in-house ERP departments.
ERP Design by Industry: What Changes and What Stays the Same
The fundamental design principles of simplicity, role-based access and real time visibility are applied everywhere. Some priorities vary by sector, however.
Not sure where your industry fits? Request a personalised demo and we’ll walk through the priorities specific to your sector.
Industry | Top Design Priority | Why It Matters |
Manufacturing | Production scheduling & shop-floor data capture | Downtime and material shortages are expensive and time-sensitive |
Retail | Point-of-sale integration & multi-location stock | Stock visibility across locations directly drives sales |
Healthcare | Patient data segregation & audit trails | Regulatory and safety requirements override navigation speed |
Education | Multi-stakeholder access & term-based reporting | Finance, admissions, and faculty all need different views of the same data |
Manufacturing ERP Design Priorities
Production scheduling, shop-floor data capture and bill-of-materials visibility reign supreme. Watch how this works in the real world with a manufacturing ERP system based on production workflows.
Retail ERP Design Priorities
Reorder workflows, multi-location stock visibility and point of sale integration are the most important features. Explore our industry specific retail, Visitor Management System patterns.
Healthcare ERP Design Priorities
Segmenting patient information, tracking patient history and implementing access controls are more important than navigating quickly. These constraints have formed the basis of our healthcare ERP system.
Education ERP Design Priorities
The design is influenced by multi-stakeholder access (finance, admissions, faculty) and reporting cycles based on terms. How this looks in the context of education ERP software is visible in our education ERP software.
ERP Design and UK Compliance (VAT & Making Tax Digital)
Compliance should never be an afterthought in ERP, it’s part of the system’s lifeblood for UK companies.
HMRC’s Making Tax Digital (MTD) for VAT regulations require VAT-registered businesses to maintain digital records and file VAT returns via suitable software. Digital also needs data to flow electronically between systems, rather than having to be manually re-entered. The technical requirements are explained in HMRC’s VAT Notice 700/22 .
A well-designed ERP supports compliance through:
- Digital record-keeping
- Automated VAT calculations and returns.
- Connected financial workflows
- Clear audit trails
- Lower data entry workload.
The trend toward digital financial management also relates to the growing ERP market, and Statista currently has market data available. See Wikipedia’s ERP overview. for more context on ERP.
Compliance should be built into the ERP workflow. If VAT processes still depend heavily on spreadsheets and copy-paste between systems, businesses should review whether those processes meet HMRC’s digital-link requirements.
Where Sowaan Fits: Designing ERP as a Vendor, Not an Agency
The bulk of the content on the ERP ux design is from external UX agencies recommending best practice. Not so the guys at Sowaan ERP, who take a different approach, that of an ERP vendor who builds and supports systems on which UK SMEs conduct their operations each day.
It does not mean that we are guided in our design decisions by a design portfolio, but by what we observe is going wrong (and right) in real implementations in manufacturing, retail, distribution, healthcare, and education.
In practice, it manifests in the way the ERP modules, such as HR software, accounting ERP software, inventory management software, and distribution ERP software, share data and navigation logic and don’t appear as disjointed pieces.
Questions to Ask an ERP Vendor About Design Before You Sign
Bring these to your next demo: Request a personalised demo and put these questions to us directly.
- What percentage of the interface is configuration and what happens to customizations at future major upgrades?
- Do you observe at least two user types have role-based dashboards (e.g. warehouse manager, finance lead) in the demo?
- How are recommendations surfaced using AI and can it be humanly overridden before an action is taken?
- How does the compliance update process work if the regulations, such as Making Tax Digital change?
- What happens after a go-live, is there a formal review after 90 days or does the relationship come to an end then?
- How many of your last projects have you done on time and on budget, and what is the process you use to track it?
- Does someone own design decisions for the project, either the named designer or it’s distributed across the team that has the time that week?
- Have you got a reference implementation in our industry with a contact that we can talk with about design decisions that survived go-live?
These aren’t formalities. Someone who can give you the answers to the first two questions clearly and specifically with numbers and not just a general reassuring word, is usually a vendor who has taken the time and effort to make design a important part of their job and a product they sell, not an afterthought.
How to Tell if ERP Design Will Require Re-Implementation Later
Get a sense of the early warning signs: When the vendor uses too much custom code to accomplish common tasks, a workflow that doesn’t reflect the way the team actually works, and when the vendor cannot clearly articulate what its upgrade path is.
A system that is mostly customised is often a very expensive re-design job in a few years, whereas a system mostly configured can adapt to the expanding business.
How to Measure Whether ERP Design Is Working Post-Launch
Monitor login frequency per role, workflow abandonment rate, and volumes of support tickets relating to navigation confusion as well as the frequency of teams resorting to spreadsheets outside of the system.
One of the most obvious markers that design is working well is when the number of shadow spreadsheets used decreases over time. Establish these requirements BEFORE go-live, and not after.
Conclusion
In 2026, ERP design isn’t only about having a clean navigation and neat dashboard. It’s about giving the AI agent a certain degree of freedom, integrating compliance into the system, and when genuine data, not demo data, comes in, how will the system handle it.
The design is right, and an ERP system becomes the backbone of the operational backbone, enabling an expanding UK business to plan, meet, and expand with confidence. If it doesn’t turn out as you’d hoped, you’re in the league of two-thirds of projects who fail to meet their original expectations.
The core of Sowaan is the ERP design: role-based workflows that are compliant by default and industry-specific patterns based on real ERP implementations, not a design portfolio.
FAQs
It’s how an ERP system is structured and presented so that different teams can do their jobs, approving invoices, checking stock, running payroll, without needing deep technical training.
For an SME, a well-scoped implementation typically runs three to nine months, depending on the number of modules, industry complexity, and how much configuration versus customisation is required.
Design shapes how users experience the system, development is the underlying engineering work, including customisation, that makes new functionality possible.
Most SMEs are better served by a system that’s well-configured for their industry rather than heavily customised. Customisation should be reserved for genuine competitive differentiators, not routine workflows.
Usually a mismatch between how the interface is structured and how people actually work, combined with a lack of ongoing review after go-live.
It shifts ERP from systems that report on what happened to systems that recommend or initiate the next action, which means design now has to account for AI transparency and human oversight, not just navigation.
Cloud ERP design typically supports faster iteration and more frequent updates, so design tends to favour configuration over customisation to stay compatible with regular releases.
Costs vary widely by scope, but SMEs should budget for both the software and the implementation/design work, the latter is often underestimated and is usually where adoption succeeds or fails.
All departments that will use the system. IT-only design tends to produce technically sound systems that operational teams struggle to adopt.
Yes, if the system was built configuration-first. Heavily customised systems are far harder to update incrementally.
