Cyril Northcote Parkinson, mid-20th century British Civil Servant, was a smart guy. His observations on stifling public sector bureaucracy are widely referenced – and with good reason. Northcote is famous for his Parkinson’s Law, where he suggests that “work expands so as to fill the time available for its completion”. If you’re interests lie in productivity and efficient decision making, his ideas are insightful and remain very relevant (The Economist published his scientific theory in 1955).
He is also responsible for another – perhaps more cogent – truism. Parkinson’s Law of Triviality states that “organizations give disproportionate weight to trivial issues”, and it is an important concept in the pursuit of effective and efficient decision making. It proffers that when important, complex decisions need to be made, the default action is to tend to the trivial, or subjective details, more fervently.
“The Law of Triviality… briefly stated, it means that the time spent on any item of the agenda will be in inverse proportion to the sum involved.”
– C. Northcote Parkinson
Parkinson uses an analogy of building a nuclear power plant, where the gathered committee spend most time discussing the colour of the proposed bike shed, rather than how the atomic reactor might function. Complex issues are given scant time while, naturally, everyone has an opinion to offer on the trivialities, which are debated ad absurdum.
With software development in general and UI design in particular, this Law of Triviality has been adopted as an anti-pattern known as bikeshedding (or ‘BS’ if you prefer!) where opinion wars over non-critical issues can block efficient decision making and slow development progress. And, critically, lead to incongruous UI design. If you work in an agile environment that encourages cross-functional collaboration but de-emphasises the role of design, the consequences of bikeshedding can be pretty dire.
It is important that designers safeguard against this. The tendency to bikeshed should be brought into the light early on – be upfront and honest about it with your co-workers. Have a laugh about it. Highlight it when it rears its head.
When it comes to design critiques, workshops or whatever with business stakeholders, make sure you prioritize making a decision – any decision. It may not be perfect but you can fail, iterate and test again. Take a vote, flip a coin – just decide! Or better still, let data do the deciding for you by utilising data-driven design techniques or Lean UX’s build-measure-learn paradigm.
I get the impression that our friend Northcote was an impatient man, one who didn’t suffer fools, and believed that decision making should be left to those with the relevant expertise. I think he saw the danger of giving everyone a voice or platform to air their opinions, and was suitably aghast at the cultural bikeshedding evident in bureaucratic organisations. He felt that decision making should be de-democratised for the sake of efficiency and the public purse.
This was prescient. We are often led by our ‘gut’ to go with the majority at the expense of the minority – or even expert – view. Recent neuroscience research into decision making suggests that a “hefty reliance on the opinion of the majority can … translate to suboptimal choices, odd beliefs, and missed opportunities” (Sharot T, 2017).
This heuristic (or mental shortcut) is known as the ‘equality bias’ (Bahrami, B et al, 2015). When making group decisions, we can revert to an easy strategy of weighing everyone’s opinion equally, even when a domain expert is present. We assign equal weight to everyone’s opinion because it just ‘feels right’ and requires reduced cognitive effort.
Be on your guard against ‘bikeshedding’ and the ‘equality bias’ at your next design group meeting. By ensuring that your expertise and opinion is weighed correctly against other less-informed stakeholders, you just might eliminate the inefficiencies and biases that stifle productivity and hinder good design.
