Operating model
We map the people, decisions and exceptions. A server, host, manager and owner need different capabilities, even when they are working with the same restaurant.
What goes into the build
The screen is
the surface.
We turn a practical problem into a product by defining its users, rules, records and complete workflow. The screen is where those decisions become visible.
- 01Operating rules
- 02Interface & feedback
- 03Records & state
- 04Identity & authority
- 05Contracts & exchange
- 06Testing & delivery
Design the visible feature and the invisible responsibilities.
From idea to product
Six layers behind a working application.
Interaction design
We shape navigation, forms, feedback and confirmations around the task. A fast-moving host stand and a financial review require different layouts and levels of detail.
Records and business state
We define original records, permitted changes and the history needed to explain a correction. A clock time, shift and restaurant business date must retain their distinct meanings.
Authority
We enforce access to the operation and its data. The server checks the person, organization, role and permitted action; a hidden menu is only part of the interface.
Connected services
We define identifiers, message formats and expected results between systems. Timeouts, duplicate messages and partial failures need explicit handling.
Testing and maintenance
We test the workflow, preserve accepted behavior and prepare the change for delivery. Clear source ownership, version records and recovery procedures make later work manageable.
In practice
An employee, a shift and an app are different records.
In a connected restaurant platform, an employee can have a published shift without yet having approved access to every application. Account identity, restaurant membership, role, app access and clock status are separate decisions.
Our design keeps those distinctions explicit. The interface needs to show the employee what to do next, while the underlying request checks whether the action is permitted. A second application must reach the same conclusion from its own entry point.
This is where much of the engineering lives: connecting an understandable experience with consistent rules across the system.
Model the relationships
Employee identity≠Published shift≠Approved access
The product needs an explicit relationship between these states, not an assumption that one implies the others.
The scope of the build
Every connection adds responsibilities.
Additional roles, devices, integrations and business states create more combinations to design and test. A late correction, interrupted payment event or repeated request can matter as much as the normal path.
We work through those combinations as part of the product, alongside usability, security and maintainability. The result needs to support the next person using it and the next person changing it.
- 01Roles
Whose experience changes?
- 02Records
Which source is authoritative?
- 03Dependencies
What can be unavailable?
- 04Recovery
How does work resume?
Bennett Edge Group
Bring the problem.
Let's work through the system.
Talk with us about software, an engineering project, publishing, or a partnership.