Question
Clarify the outcome, owner, evidence, constraints, and approval boundary before designing a workflow.
- Problem framing
- Stakeholder logic
- Risk inventory
- Acceptance criteria
Process
My process starts before the screen and continues after launch.
The reference site has a classic design process. Mine needs to show a broader operating process: question, delete, optimize, accelerate, automate.
Delete
Remove weak opportunities, unnecessary infrastructure, duplicate state, and tasks that do not move the outcome.
- Scope control
- State ownership
- Decision pruning
- Roadmap discipline
Optimize
Make the necessary workflow clearer, safer, faster, and easier to operate before adding automation.
- UX flows
- Policy checks
- QA paths
- Customer-safe copy
Accelerate
Use tools, code, templates, and agents to shorten the path from decision to working product.
- Working slices
- Static hosting
- Adapters
- Deployment packages
Automate
Only automate when the system has an owner, evidence trail, failure behavior, and approval rule.
- Routines
- Agent scopes
- Rollback
- Auditability
Evidence over activity
Motion is not progress. I look for proof that the work changed the operating state.
Clarity over cleverness
Interfaces and workflows should make the next right action obvious.
Launch with a way back
Every meaningful release needs validation, monitoring, and rollback.