The Principle of Crushing Inevitability — IT Security Work

Article in preparation.

Links, shared identifiers and explicit states should carry the user through the process. The user should not have to reconstruct it.

01 / The process is straightforward

A document is uploaded, read and accepted. A task can then commence. In security work, the reviewer needs the evidence, the relevant approval and the task they support. The relationships are the work.

02 / The links stop halfway

The task links to the document acceptance. The trail stops there. No onward reference to the document itself. The user gets to reconstruct the rest.

03 / Another tab. Another investigation.

There is an Approvals tab. Approvals are listed by parent approval, so the reviewer drills down to find the one they are working on. Still no reference to the document they need to review. Another tab is not another connection.

04 / A name does not mean there is a document

Documents can be named without uploading them. Documents can be uploaded without naming them. Neither the presence nor the absence of a name tells you whether a file exists. Click every link. Find out.

05 / The user supplies the missing architecture

The reviewer makes the connections, remembers the records and checks whether the evidence exists. The application holds the information needed to do this. Instead, its interface creates an investigation before the actual review can begin.

06 / Carry the identity through

T-3096 → PA-3096 → CA-3096[aa–zz] → D-3096[aa–zz]
The task number and the relevant designation remain recognisable across the records. You need the task ID and your designation. Display the person’s name too. Hell, make it useful.

07 / Recognition and navigation belong together

The identifier tells you which task a record belongs to. The link takes you there. The state tells you whether the document has been uploaded, read or accepted. Follow the work instead of investigating the application. Acceptance records a decision; the document still has to justify it.

08 / A charitable explanation

Clearly the developers, managers, designers, process developers and possibly the AppDev Director despise the team using the application. Perhaps all human life. Perhaps all life.

Or they never have to use the shit they have developed. Or it was designed for a different audience. Or—and this is the one I go for—all they have to do is drink coffee and lounge on beanbags.

09 / The idiot test

Give someone a real task without a developer narrating the interface. Can they find the document, understand its state and proceed? If the application makes a competent person feel like an idiot, inspect the application.

The next step should be obvious, the records recognisable and the necessary facts available. The user has work to do.