If you're comfortable, your principles aren't working

Design principles are a tool for delegating and scaling the ability to say "no" to many good ideas, so that they can say "yes" to one great idea. If your principles aren't constraining these kinds of decisions, then they are not actually fit for purpose.

Good morning, picnickers 

I’ve long talked about design as the applied science of decision-making and it warms my heart to see the topic surface in the discourse over the past couple of weeks. So today we’re going to talk about making good choices. And more importantly, enabling others to make good choices, because despite what design school might have you believe, none of us actually work under the enlightened despotism of total UX autocracy. 

The Timeline

One of the most useful ways in which professional user-centered design supports decision-making is by boiling down research into shared principles (I make the professional distinction because “democratized” user research does not perform this function). One does not need to have processed the entire dataset to be able to apply the lessons from it. 

As design has come in and out of vogue, so too have design principles. Managers have long sought to replace them with entirely “data-driven” decision-making. But data alone does not get you very far without principles to guide what to measure and how it will be interpreted.

We had an A/B testing tool that'd show you which of 100 metrics had moved significantly. With p=0.05, 5 of them will always move, this is just how statistics works.

Antoinette Weibel shared a great summary of a recent paper on how solely quantitative goals create tunnel vision in teams and expose them to additional risk, unethical behavior, and long-term consequences. Maria Romera Jolliff provides an example of how this happens in practice (if link is broken, see appendix). 

This is ironic because risk is exactly what draws stakeholders to quantitative indicators. But as Tom Kerwin tells us, what they are actually doing is refusing to engage with uncertainty, which limits the scope of their thinking and increases overall risk. This creates the reactive environment Doug Rabow describes here, where everything appears to be going great right up until the moment it fails. 

It’s not difficult to see how the proactive environment Doug describes requires design principles to function. Principles are what allows the team to make decisions throughout delivery rather than solely during planning, by shifting from the reactive “build and measure” approach. 

The mistakes and the learning aren’t things to be bypassed, but a vital part of the process.

 Jamie Smart on how Gromit was originally going to be a cat 

In other words, quantitative measurements – while a good idea in the abstract – are unhelpful in this context. And this framing of “X good thing over Y good thing” is exactly what makes a design principle so powerful, and so difficult to practice. 

Reading Material

To think about principles, it helps to think about what being principled actually means. A person who is principled is not necessarily defined by doing certain things, but by not doing a much greater number of things. Things that may be expedient, or profitable, or gratifying, but that do not align with their principles and therefore must not be done. 

A principle which does not bar a tempting course of action is not a principle at all. Indeed, a design principle should help you say NO most of the time. Design principles like “make it usable” may be values, but they are not principles, for two important reasons: 

  • They do not provide any guidance for achieving that outcome 

  • No one is actually advocating for things like “make it unusable” 

I can already hear the telltale sound of several hundred designers reaching for their keyboards to tell me that product managers and developers want them to make unusable things every day. But do you really think that this is how they see that decision, between “good” and “bad”? Everyone wants to make good software and this conflict happens exactly at the intersection between different definitions of what good is

A trick for avoiding this is to force “principles” into the format “X over Y” where X and Y are both objectively good. “Polish over shipping speed” is an actual principle that helps guide decisions and break ties. Nobody wants to do this though, because it forces you to take a sometimes-uncomfortable position that (gasp) someone may disagree with.

Geordie Kaytes (if link is broken, see appendix) 

This, I think, is the other key concept behind effective design principles. They are uncomfortable. Not only for the people exercising them, but for the decision-makers above them who are ceding power to decide. 

A project team has no use for design principles; decisions are made above their heads and they are only responsible for executing. Any additional decisions that surface are floated back up to stakeholders because “leaf-level” contributors are not framed as being capable of knowing things and therefore, of independent decisions. 

This experience and information that I have, thanks to my position in the hierarchy, didn't count as knowledge. Meanwhile, my manager, being the CDO of the company, had the clout and authority to make his vague beliefs count as him knowing something, which then allowed him to assert that view as institutional knowledge in a way that I simply couldn't. So, of course, I had to go and write the code.

As the quote from the article (which you really ought to read, it’s short and possibly the most insightful piece not only in this issue but in every issue of the Picnic thus far) suggests, the autocratic mode of decision-making does not work well. The more your identity as a leader is wrapped up in being the sole Knower and Decider of All Things, the more uncomfortable information that challenges your beliefs will become. 

The result of this culture of genius is that it strangles any culture of growth. Instead, people are incentivized to just make it work at any cost, lest they be framed as low performers or even (at the extremes of cross-functional enmity) wreckers who are doing bad work on purpose. 

The thing that I want to stress here is that you are not the exception, dear reader. Neither am I. I’ve worn every pair of shoes in the product triad, and there’s no vantage point from which you can simply make all the decisions as a benevolent dictator (if for no other reason that this does not scale). 

Because every bad decision looked like a good decision at the time

And that’s exactly why effective principles are structured the way that they are. No one really needs help deciding between bad and good things, but it’s when we must decide between two good things that the creative constraints of a design principle are most necessary. 

You can only make this happen consistently when you delegate the decision-making to individuals while empowering them with the tools to make those calls correctly in the context they can see. 

Dan Brown’s classic design principles for information architecture are a good example of principles that have remained useful for 15 years, even as the underlying technology and usage patterns have completely shifted. Nearly every principle provides guidance not only on what to do, but also what not to do – even when that thing might, in the abstract, be appealing. “Giving the user more choices” or “reducing the number of clicks” can both sound like benefits, in the right context, but these principles establish that information architecture is not that context. 

One final piece of further reading that caught my eye a while back is The Uncertainty Project, a large collection of decision-making models. It’s not entirely related to design principles, but some of their articles such as the one on simple rules can provide effective guidance when developing your principles. 

Appendix

LinkedIn does not properly support permalinks to comments, only parent posts. The direct links to the comments above will stop working at some point. This appendix will become a part of the newsletter that preserves those links for future readers.