A staff member needs the next order to work on. An owner needs to see outstanding money and the next person to ask. I wanted the public ERP experience to make that difference visible before visitors had to learn a list of features.
This is a close reading of the layout I built for a public, synthetic example. It contains no client screens or records. The central decision was how reading order should lead into an action.
Start with the next action for each role
A large sales figure can make an employee screen look impressive while leaving today’s work hard to find. A long order form can make an owner screen look capable while asking the owner to interpret everything again. I treated the first question for each role as the beginning of the layout. The staff example moves from item, quantity and supplier to preparing a request. The owner example moves from a figure to its entries and the work requiring attention.
On the homepage I placed those views alongside one another so their relationship could be read quickly. Preparing the example request changes the order status shown to the owner. It does not change the monthly financial cards. The separation is explained close to those figures because order preparation and a monthly ledger have different boundaries. Sharing a page must not imply that every panel is a calculation of the same transaction.
Give a card and its details different jobs
The owner’s first view contains synthetic sales, purchases, receivables and payables. If the experience stopped there, visitors would only see attractive numbers. I connected each amount to the entries that produce it. The summary answers how much; the details answer what needs to be checked. Fictional parties, responsible team members and dates appear because the useful next question is usually about a particular balance or follow-up.
Keeping every entry expanded would also have been possible. For this public introduction I separated the width needed to understand the summary from the attention needed to inspect the details. A real button opens the entries and exposes its expanded state. That is a choice for this setting, not a universal ERP rule. A ledger used all day may need row comparison, search and sorting first. Here the purpose is to help a new visitor recognise a problem in their own company.
Keep one authoritative input tree on smaller screens
Two columns on a desktop do not require a second mobile form. In the homepage document, the staff view comes before the owner view. The layout becomes one column as space narrows while preserving those same elements. Duplicating inputs would introduce another place where quantity, state or keyboard focus could disagree. I chose to change the arrangement of one set of elements instead.
The homepage pair becomes a single column at 1000 pixels. The detailed owner section has a different context: its main summary and supplementary example stack at 850 pixels, with further spacing and metric adjustments at 520 pixels. These are the boundaries in this implementation, not numbers I would prescribe for another company. The useful test is where the real content, both languages and the controls stop fitting comfortably.
Set the minimum width before choosing the proportion
A declaration such as minmax(0, 1fr) is easy to overlook. Its role here is to let a grid track shrink without long content imposing an unwanted intrinsic minimum. The detailed owner section uses a 1.5-to-1 proportion with that zero minimum on both tracks. The excerpt below is taken from the current public styles. It describes the grids, not the complete layout; child rules and responsive changes remain necessary.
Labels and values stay in related groups, and actions remain actual buttons or links. The supplementary small-screen card is also explicitly an example arrangement derived from the same synthetic monthly data. It is not a screenshot of a working mobile app. I kept that explanation in the experience because a convincing device-shaped panel should not stand in for evidence of a deployed operational product.
Explore the implementation
Grid declarations in the current public CSS
.erp-demo-pair{display:grid;grid-template-columns:repeat(2,minmax(0,1fr));gap:22px;align-items:start}
.xp-owner-layout{display:grid;grid-template-columns:minmax(0,1.5fr) minmax(0,1fr);gap:50px;align-items:start}A separate page makes room for a different level of attention
Expanding every workflow scenario on the homepage would ask someone reading a company introduction to begin a training exercise halfway through. I kept the homepage focused on the relationship between staff work and owner oversight. The detailed page lets visitors follow the sequence from quotation to collection and inspect role choices, import review and recovery in their own places.
Navigation should explain what the destination offers. I used ordinary internal links and identifiable section anchors rather than making an entire visual panel an ambiguous click target. The source includes keyboard-operable native controls and generous control heights. I have not repeated physical-device or rendered-browser testing while writing this article. The evidence here is the implementation and its stored checks, so I do not turn those structural choices into a measured usability claim.
Translate the structure into your own company’s questions
Before listing screens, write down what a staff member and an owner ask at the start of a day. Separate values that must be entered, values that are only reviewed and states handed to the next person. Then trace a single transaction through both views. If different totals cannot be explained by the scope of the underlying records, the data boundary needs attention before the layout does.
The related shared module shows a responsive structure with a single input tree. Keep the distinction between simplifying a view and enforcing access rights. Role selection in this public experience changes the explanation and example fields. It is not server authorization. A real service must enforce user identity and record access independently. The role’s question starts the interface; an explicit implementation must protect the records behind it.