Emergent Principles: A Rebel Leader’s Secret to Better Team Design Decisions

Many eons ago…
In a conference room far, far away, a rebel team reviewed their latest usability test results. They’d been observing people starting out with the Empire’s latest operating system: Windows Vista.

These rebels were now focused on the improvements for what would later become Windows 7 Desktop. They saw how flummoxed and frustrated users new to Vista became when besieged by all the settings and configuration options necessary to get started.

In that moment, a new design principle was born: UX over knobs and questions. For their new system, the rebel team would focus on turning down the volume of questions and deliver value to the user without them having to configure things.

A few years later…
At a different company, another rebel team had just come back from a series of field studies. They’d watched their customers interact with a recent version of their small business point of sale application.

As the rebels were comparing notes, the team realized they’d seen too many bugs in the deployed software. Many of the bugs they spotted while in the field hadn’t shown up in their own testing, so were new to them. They realized just how broken their QA process was.

In that moment, another new design principle was born: Polish before new features. The rebel team realized they had been so intent on shipping new capabilities that they hadn’t adequately finished the existing software. Bugs were getting in the way so much that users weren’t using newer features. By fixing the bugs, they’d be delivering new capabilities to the users with code they’d already written.

More recently…
Another rebel team, this time deep inside a government agency, was working on a complex workflow for approving benefits. They’d watched their agency’s field officers using the management application and noticed the interface kept asking officers for information they needed to look up elsewhere. In essence, the officers were calculating and typing information from one computer tool into another computer tool.

And in that moment, yet another new design principle was born: Don’t force users to do things computers are good at. The field officers had compensated by developing spreadsheet applications and other tools to answer questions in the workflow interface. The rebel team was intent on inventorying those tools and building them into future versions of the benefits approval software.

The Best Design Principles Are Emergent

These weren’t the only principles these rebel teams created. In fact, each team created quite a few more, based on what they’d learned from their users.

The rebels didn’t create these principles all at once. The principles came about as the team was learning, often deep in the middle of their projects. The list of principles was growing and the teams were embracing each one.

These particular principles emerged. They usually emerged from user research. The team would see patterns of broken things in the existing design. At that moment, a team member would propose they create a new principle to guide their future design work.

Teams latch onto emergent principles like these. They keep bringing them up in design discussions. They frequently have debates, where they argue about the semantics of whether something is or isn’t covered by the principles. Is that a knob or another type of control? Should we give the user an option in this case?

These debates are healthy, as they help the team understand the subtleties and nuance in their designs. Their new understanding of these subtleties helps them solve the real user problems they observed. The principles make it easy to see and agree on what needs to be different in the design.

Emergent Principles Are Not Divinely-Inspired

There’s another type of design principle that’s very popular with teams. These principles come from a team leader or committee that decides, for the entire organization, what the best practices should be. Facebook, for example, has beautiful design principles, like Bring clarity to complexity and Be accurate and predictable.

This type of principle doesn’t emerge. These principles are often declared, as if they were handed down from a higher authority through some sort of divine inspiration. The team doesn’t get a say as to whether they apply or not, and there are few specific examples of how they’ll use this to improve their designs.

While emergent principles become living rules that teams embrace, it’s rare for us to see a team embrace any of the divinely-inspired principles. We never hear teams bring these principles up in discussions. It’s only the emergent principles we see teams bringing into their work.

The Empire likes its divinely-inspired principles. Rebels, on the other hand, want to make their own rules. They favor emergent principles.

Principles Move Teams From Good Design to Great Design

Emergent principles become tools for making tough design decisions. It’s these tough decisions that turn a good design into a great design. Yet, before a team can work on making their designs great, they first have to turn their poor designs into good designs.

When a team tries to improve a poor design, the principles become easy to identify. If their current design is unusable, they fix it until it becomes usable. If the design frustrates users, they redesign it until the design is no longer frustrating. The team doesn’t need more nuanced principles than that, because it’s easy to see how to resolve issues by watching the users.

This is where the divinely-inspired principles come from. These simplified principles, like Bring clarity to complexity, don’t need to be useful in the day-to-day work, when the team is still struggling to make their designs good.

Today, we know how to make good designs. Now we want to make great designs. We’ve outgrown the divinely-inspired principles. That’s when emergent principles pay off.

Emergent principles go beyond divinely-inspired principles because they are rooted in the problems the team identifies from their research. They are unique to every project, even in large organizations.

Where a Facebook-like company could have a handful of divinely-inspired principles to cover every project, the emergent principles will be specific to individual projects. The UX over knobs and questions principle is perfect for the Windows 7 Desktop project. It wouldn’t work for a Windows system administration or network management tool, where configuration and customization is a core part of the user’s job.

Emergent Principles Become Our Rationale For Future Design Decisions

During the Rebellion, the rebel teams independently work toward a common goal. They need to make decisions to move their projects in the right direction, often without communication with other parts of the organization.

Emergent principles are an instrumental tool for making all those decisions. A good principle tells the designer how to make the call, when it’s otherwise not clear. Should we do this or that? When we’re not sure, we look to our principles for guidance.

The principles are there to help us make future decisions. They become the design rationale we’ll use to explain decisions we don’t even know we’ll need to make.

When the government application team decided on the principle Don’t force users to do things computers are good at, they were making decisions about future functionality they needed in each release. The point-of-sale application team would use Polish before new features as their way of pushing back on delivering functionality. Once everyone bought into these principles, it became easy to make these decisions.

Because each emergent principle comes from research, there’s an origin story associated with each one. Users had a problem that the team will solve under the guidance of the new emergent principle.

If every team member knows the specific story (even better if they saw those user problems first hand), then they know why the team is making decisions to support the principles. It’s very powerful when a team member can see a clear, positive outcome from their decisions.

Emergent Principles Eventually Fade Away

Eventually, the point-of-sale application team will build out an improved quality assurance process. They’ll be releasing polished functionality quickly and efficiently. At that point, the emergent principle of Polish before new features no longer serves any purpose. It can now fade away.

Other principles will emerge to take its place. The team will continue to do more research, and see more problems. Some of these new problems will now be easier to identify because the design has improved. Those new problems will demand new principles to guide future decisions.

It seems heretical to suggest a divinely-inspired principle may no longer be effective. Yet, this happens with emergent principles all the time. They are specific to a moment in the product or service’s evolution and eventually fall by the wayside.

The most effective rebel teams know when it’s important to create a new emergent principle, and when it’s important to let it fade away. This ensures the current set of principles are actively helping the team turn a good product into a great product.