JiraProduct Thinking7 min readThe cost of a tool that can model anything
Configurability sold to buyers, paid for by everyone else.
- The surface
- Creating a project from a template, moving a ticket across a board, and what happens when someone needs the workflow changed.
- What the user wants
- I want to see what my team is working on and move my ticket to the next stage without filing a request to do it.
Project templates
New projects start from a named template such as scrum or kanban, arriving with issue types, a board and a default workflow already configured.
A sensible starting configuration
A fully general system with no starting point is unusable, because the first user has to design a process before tracking any work. Templates encode a common process so the team can begin and adjust. The template also becomes the thing nobody revisits, which is mostly a good outcome.
The board as the daily surface
Columns map to statuses, and dragging a card between columns performs the status transition. Most team members interact with the tool only through this view.
One surface for the common case
The overwhelming majority of interactions are move my ticket one step right. Collapsing that into a drag keeps the daily cost low no matter how complex the configuration behind it is. The gap between this simple surface and the machinery underneath is the source of most of the product's trouble.
Workflows as state machines
A workflow is an explicit set of statuses and permitted transitions, and transitions can carry conditions, validators and post functions that fire automatically.
Process encoded as constraint
For regulated or audited work, the requirement is that certain steps cannot be skipped, and a tool that only suggests order cannot satisfy it. Making illegal transitions impossible is genuinely valuable to the organisation. It is also the exact mechanism that makes the tool feel obstructive to the individual.
Screens and field configuration
Which fields appear at creation, during editing and on transitions is configured separately from the fields themselves, and required fields can block a transition.
Separation of schema and presentation
The separation is what lets one organisation run finance and engineering in the same instance with different forms over shared data. It is also why a field appears in one project and not another for reasons no user can discover. Power and inexplicability come from the same design decision here.
Permissions and admin distance
Workflow, screen and field changes generally require project or instance administrator rights, and in larger organisations those rights sit with a central team.
The configuration gap
The person who feels the friction daily is structurally unable to fix it, and the person who can fix it does not feel it. Every request has to survive a queue and an explanation, so most are never made. The tool then gets blamed for a process failure its permission model created.
JQL and reporting
Saved filters written in a query language drive boards, dashboards and reports, so the data model is queryable across projects.
A query layer over the process
Once process is structured data, questions about throughput and ageing become answerable without a spreadsheet export. This is the real argument for the heavyweight schema. It only pays off where teams fill the fields honestly, which is a cultural condition the tool cannot supply.
The distance between the friction and the fix
What not to copy
- The buyer and the user are different people with opposing interests. Configurability wins procurement and is paid for in daily seconds by everyone who files a ticket, and no feedback path carries that cost back to the purchase decision.
- Configuration accumulates and never gets removed. Custom fields added for a project that ended in 2019 remain on the create screen, and nobody has the authority or the confidence to delete them.
- Required fields at a transition punish the user for the organisation's reporting needs. The predictable outcome is accurate-looking data filled in as fast as possible with whatever passes validation.
- Performance and interface complexity scale with instance age. A new hire joining a mature instance sees a screen designed by accretion over a decade, and the onboarding assumes they already know which of it applies to them.
The takeaway
When the person who feels the friction cannot change the setting, you have a permissions problem wearing a usability costume.
Finished the teardown? Bank it and the day counts toward your run.
Where the principles come from
- The Design of Everyday Things (complexity and conceptual models), Don Norman
- Don't Make Me Think, Steve Krug
- The Inmates Are Running the Asylum, Alan Cooper
- Shape Up, Ryan Singer, Basecamp
Written from public behaviour of the product, not from inside it. Interfaces change often, so treat the flow described here as of the time of writing and check the live product before quoting it.