What this prototype argues

One screen, three panels: the shape, the selected person, and the controls that change the line. The journey document fixes the panels; the variants decide how the shape is drawn.

• A · Tree and inspector (recommended). An indented tree with expand and collapse, and the selected person beside it. It shows depth and branches plainly, keeps the whole tenant on one screen, and gives the controls a fixed place.
• B · Chart of boxes. The same tree as boxes with connector lines. It reads as an organisation chart, and it stops working past a few hundred people and on a narrow window.
• C · Table by depth. A flat table, indented, one row per person. Best for search and for reading a manager column; the shape has to be inferred from the indentation.
• Nothing here is a tree read. The server answers one flat page of accounts with reports_to_account_id per row, so this page nests the flat list in the browser and says so. A large tenant needs the tree read the journey proposes.
• The server accepts a loop. Nothing refuses A reports to B when B already reports to A. The picker leaves out the people who would close the cycle, and states that the screen is doing the check the server does not.
• There is no reporting-line-only write. Saving sends the whole account, so a concurrent edit to the job title is overwritten by the copy this screen holds.
• No approval exists. A person's proposal to change their line has no request, no queue, no notification and no decision, so the screen states who approves and the line does not move for a proposal.
• An office cannot be named yet. The card would show the party a person works in, and the association read carries party_id alone. Values underlined in amber are mock.
• The line has no history here. The account is versioned, so a change is recoverable, and this screen states none of it.
• The signed-in administrator is a mock persona. The journey's actor is the tenant administrator; the name in the header is for the picture.