Designing Applications Around Decisions
How review, consent and document workflows make product design more concrete than a collection of screens.
Find the moment that changes the work
A useful way to examine an application is to look for its decision points. What does a user need to know before an action, what changes afterward, and what record should remain?
Three examples from Culina, Muninn and Elysion make this more concrete than a generic list of screens.
Review is part of recipe publishing
Culina connects recipe authoring to administrative approval or rejection, with review notes. Creation and publication are distinct steps in the workflow. The product needs to represent both the submitted content and the decision about it.
The design implication is that an editor cannot be considered in isolation. The person reviewing a recipe has a different task from the person composing it, even when both work with the same ingredient groups and preparation steps. Review notes preserve context between those tasks.
Consent needs a visible subject
Muninn’s optional AI workflows let users review selected content before consenting to external processing. Deployment and journal controls establish whether a capability is available; request-level consent concerns the specific content being processed.
Those controls answer different questions. A setting that enables an integration is not the same decision as sending a particular journal entry. Keeping selected content visible at that boundary makes the action easier to understand. Separating self-reported mood from AI-inferred observations likewise preserves who supplied the information.
Documents belong to the operational record
Elysion generates documents from versioned Word templates and converts them to PDF. The result remains associated with a source record and template version. In the product model, generating a document is therefore more than offering a download button: it creates an artifact with context.
Elysion also serves two audiences through separate tenant and platform administration applications. Shared forms and themes provide consistency, while the applications retain different responsibilities. A consistent visual language does not require giving both audiences the same workflow.
Use the workflow to evaluate the interface
These examples suggest practical design questions: is the relevant context visible before the action, is the resulting state understandable, and can someone later explain what happened?
They are useful evaluation criteria, not a claim of measured usability outcomes. The implemented workflows provide the material for testing them. Product design becomes more specific when it follows an actual approval, consent or document task from beginning to end.