Banning “Best Practice”

A new toxic element has emerged within the workplace, the defence of “best practice”. This blanket term has become ubiquitous amongst many architectural design sessions and it is hurting innovation and user outcomes. The term “best practice” is often used without any context and used to justify someone’s design decisions without having to explain that justification. It is a term that is used to shutdown any discussion, and will likely be used to elevate one’s ideas without merit. I frequently push people to break down their assertion that their design decisions are “best practice”. This involves challenging people to firstly understand the goals with greater clarity: Are we prioritising costs, user enablement, time? What constraints are we working with? Do we have specific environments we have to work in? What problem are we ACTUALLY trying to solve? By embracing these elements, we can actually frame our decisions in a way that enable a greater level of understanding by rephrasing “best practice” into something that is more structured. For example: As we are trying to get our customers using {product feature} as quickly as possible, I think we should look at using {service A} with {service B} as it will allow us to get consumers on our platform using {product C} quickly. By focusing more on the problem, the priorities/constraints, we can design solutions together that meet our needs, rather than just doing what someone else did and call it “best practice”