Operations ·
A feature request deserves a question before it becomes a button
A useful internal tool helps someone finish a task. Evaluate a requested feature against the work it supports before adding another control.
By Norwind
Ask what the person is trying to complete
A request for a button often describes a proposed interface rather than the underlying need. Ask what happens before and after the click. A user may need to find a record, correct a repeated mistake or get approval from another team. Understanding that task makes it possible to compare the proposed feature with a simpler change to the existing screen or workflow.
Account for the work every feature creates
A new control needs a label, behavior, permissions and a response when something fails. It also needs to remain understandable when the application changes. These are reasons to design deliberately, not reasons to reject requests. A rarely used feature can still be essential. Its value depends on the importance of the task and the consequences of making the user handle it elsewhere.
Review the smallest useful version
Show the user how the task would work with the proposed change. Include the exception that prompted the request, not only the easy path. Consider whether the application can remove an unnecessary step instead of adding a shortcut through it. Agree how the team will tell whether the change helped. A compact internal tool can be valuable because its limited scope makes the important work easier to see and complete.
A practical check
- Describe the outcome without naming a screen control.
- Review permissions and failure behavior with the happy path.
- Remove an unnecessary step before adding a shortcut.