A product can seem simple until I look at it from a second role. Then permissions, exceptions, intermediate states and decisions that depend on other people begin to appear.
That is why I start these systems with relationships rather than screens. Who can act? On which entity? At what point? What do they need to know first?
The interface as a representation of the system
Role-specific navigation is not cosmetic personalisation. It is the visible expression of different responsibilities.
In projects such as Buy&Sell or an operations hub, states need to be readable and consistent across the interface, API and database. If each layer uses a different vocabulary, the experience eventually exposes the disconnect.
Simplify without hiding
Simplifying does not mean removing complexity, but placing it where it can be understood and managed. A good interface lets people act without requiring them to understand the entire architecture.
Product work involves deciding what needs to be visible now, what can wait and what evidence each decision requires.
Explore roles and states in the Club Hub