← Selected work · 03 — Enterprise · ERP · Multi-tenant
Heirs Converge: one ERP for many roles, designed over eight weeks
Heirs Converge 2.0 is a cloud ERP built for African businesses. I planned and designed its core flows over eight weeks, first scoped as a four-week sprint. It is an internal enterprise tool, so this page shows the approach and the structure, not the product’s screens or data.
- Role
- UX consultant, design lead
- Scale
- Built for organisations with 70,000+ staff
- Time
- Eight weeks, from September 2025
- Shown here
- Approach only, no internal screens
The problem
An ERP that spans finance, HR, payroll, procurement and supply chain has to serve many organisations, each with many roles, without turning into a maze.
My role
Wrote the first sprint plan, set the design-system foundations and designed the global modules and the core HR flows.
The result
A role-based, multi-tenant design approach with a week-by-week plan and a handover pack. No outcome figures and no internal screens are shown.
01 — The brief
One platform for every back-office job.
The engagement was to deliver a modern, mobile-first, scalable UX and UI design system for a cloud-native, AI-powered ERP: finance, HR, payroll, procurement, supply chain and core operations in one product, with a clear hierarchy for many organisations and many roles inside each of them.
The scale is the point. The platform is designed for organisations that manage more than 70,000 staff. That is the figure I was working to; I am not publishing the client’s numbers or its internal data.Stated by me
02 — What makes it hard
Many tenants, many roles, one product.
Three things decide whether an enterprise product like this is usable or not. The first is multi-tenancy: every organisation has its own structure, and the product has to feel built for each. The second is roles: an employee, a manager, an HR officer and a finance approver should each meet a different, short version of the product. The third is trust: payroll, records and approvals are the screens people are most afraid to get wrong.Judgement
So the design questions came before the screens: who is looking at this, what are they allowed to do, and what happens if they get it wrong. Every flow in the plan started from those three.Judgement
03 — The plan
From foundations to handover.
I wrote the first plan below in September 2025 as a four-week sprint. We later reviewed the timeline and extended the engagement to eight weeks, so treat this as the opening plan, not the final schedule. It sets the order on purpose: shared foundations and the global modules first, because every later module inherits them, then HR in two stages, then a full week for feedback and handover.
- Week 1
Foundations and global modules
- Kick-off with stakeholders and a review of the product requirements
- Design-system foundations: colour, type, grids
- Tenant creation, sign-in with single sign-on, role-based access
- Dashboard and analytics layout
- Week 2
HR: employee core flows
- Conversational employee onboarding with document upload and policy acknowledgement
- Employee records and secure storage
- Organisation setup: departments, roles, org chart
- A clickable prototype shared for early feedback
- Week 3
HR: leave, performance, payroll
- Leave requests, approvals and a team calendar
- Performance dashboard and review cycles
- A light talent view: skills mapped to roles
- A simplified payroll flow with benefits and deductions
- Week 4
Feedback, iteration, handover
- Walkthroughs with stakeholders on the critical flows
- Corrections to interface, workflows and dashboards
- Design system tidied: components and patterns
- Handover: design files, prototype, screen map, user flows and a session with the developers
04 — How I designed it
Four rules I held to.
Foundations before screens
Colour, type and grids were agreed in the first two days, so that a form built in week two and a dashboard built in week one look like the same product.Design-level
Start every flow from the role
Sign-in, access and the first screen change with the role. Nobody sees a menu of things they cannot do.Design-level
Make onboarding a conversation
New staff are guided through documents and policy acknowledgements one step at a time rather than facing a form of thirty fields.Design-level
Prototype weekly, hand over properly
The plan puts a clickable prototype in front of stakeholders at the end of week two, so feedback arrives while it is cheap to act on. The handover pack was planned from day one: design files, a screen map, user flows and notes on how to use each component.Design-level
05 — The structure
An illustration, not a screen.
This diagram shows how the product is organised: tenants and roles at the base, six modules on top. It is my own illustration of the structure, not a screenshot.
06 — Not shown here
Ask me in the room.
The flows, the trade-offs I made and the handover pack stay inside the engagement. I am glad to talk through how I structured the work, how I handled role-based access, and what I would do differently in a second sprint.