Top

Principles Over Standards

Innovating UX Practice

Inspirations from software engineering

A column by Peter Hornsby
August 18, 2014

“These are my principles; if you don’t like them, I have others.”—Groucho Marx

For a long time, I’ve been an advocate of creating standards, guidelines, and patterns as a way of achieving design consistency within a large organization. While these do offer significant benefits, they also introduce a number of problems into the design process.

Some Problems with Design Standards

First, standards can provide a false sense of expertise in design. Calling something a standard, by its very nature, seems to imply that a great deal of research, thought, and experimentation has gone into its creation. It is likely that the proper stakeholders and experts have approved it. So designing something in a way that differs from a standard sets the designer against the people who set the standard and the weight of the work that they have done. No mean feat. Particularly for people who are new to an organization or junior designers, it can be easier to keep their head down and avoid challenging a safe option. In some organizations, particularly those that outsource a lot of design work, a reliance on standards can also lead to stakeholders using the standards to design solutions themselves, bypassing the UX design team.

Champion Advertisement
Continue Reading…

Next, a standard can seem like quite a safe, respectable thing for designers to refer to in meetings with stakeholders. When someone asks, “Why have you done it this way?” the designer can pull out the weighty tome containing the organization’s standards—the implicit message being, “Challenge that, if you dare!” Of course, the flip side of this is that the designer can sound rather hollow and lose credibility by constantly referring to a standard rather than providing a solid rationale for each design decision.

Finally, design standards can lock an organization into psychosclerosis: a hardening of its attitudes. Because a lot of work goes into the creation of a standard, it becomes easier to leave the standard as it is rather than challenge that effort. Just as many organizations get locked into doing complete redesigns of their sites and services every few years—rather than following a process of constant improvement—an organization’s design standards can get locked into place, becoming increasingly outdated over time, while the rest of the world moves on. This often happens because of modern organizational pressures, the major effort that updating design standards represents, and an excess of documentation. In large organizations particularly, defining standards requires documentation, and people perceive large volumes of documentation as carrying both physical and intellectual weight. It’s only half in jest that graduate students joke about their thesis being put on the scales to determine whether they pass or fail. Some people consider standards in the same light.

Basing Standards on Design Principles

Standards and patterns do have a useful role to play within organizations, but they are most effective when we use them in combination with a well-defined set of design principles. When people are solving problems in any domain, they tend to flip between the problem domain and the solution domain; defining the solution helps them to better understand the problem. This is as true for designers as it is for anyone else. When designers create a set of design standards, the act of creating the standards helps them to develop their understanding of the key principles underlying their design work. However, describing these design principles in a way that is as clear as a designer would wish can be another challenge entirely!

I have found it helpful to document the design principles on which my team has based its design standards. Defining and agreeing on these principles can be a significant piece of work in itself, but doing so has several advantages. A design principle is a much higher-level concept than a design standard. This means you can use them in presenting a design rationale, without either creating the perception that you’re avoiding responsibility by referring to a standard or requiring stakeholders to check out the standard.

You can express a design principle in just a sentence or two, so it has much less physical volume than a design standard, whose documentation and examples frequently run to many pages. This, in turn, means that a novice designer can spend less time reading and more time thinking about what the principle means in practice. In a similar way, it’s much easier to share a set of design principles with an agency than a set of standards, and since principles are less wordy, the agency is more likely to be able to apply the principles than they would a corresponding set of standards.

Some Useful Principles

Here are some of the principles that I have consistently used in my own design work.

Strip away everything that doesn’t add value, then add some visual texture back in.

The great car designer Colin Chapman famously said, “Simplify, then add lightness.” This principle owes something to that mindset. Every element on a page must add value to the user or the business—and ideally, to both. Taken literally, the process of stripping away non-value-adding elements can produce a rather Spartan design. This is where adding some visual texture back into a page comes in. This approach means:

  • The page focuses on the key content.
  • The necessary visual texture and interest is present—supporting the aesthetic-usability effect—but not at the expense of the key page content.

Don’t repeat yourself.

I recently saw a page element that included a title, Email us, instructional text telling users what topics they might send an email message about, and a button labeled Email—all in a sidebar containing other contact information. There are sometimes good reasons to reinforce a message on a page. These are design principles rather than hard-and-fast rules, after all. But needlessly duplicating information in this way doesn’t help users and, indeed, adds visual clutter to the page that they must fight their way through. In this example, it didn’t help that, on the same page, there were several buttons. So rather than the button’s being a clear call to action, it was a one-size-fits-all solution for letting the user do something.

Provide information at the most relevant point on the user journey.

Particularly in financial services, it is easy for users to get bombarded with information—frequently, in an organization’s attempt to be open and clearly provide all of the information that is necessary to make a decision. While their intent is a good, they fail to consider the way people behave online—specifically, that people scan rather than read. While telling people all of the conditions that they must meet before completing an online form can give the business the warm feeling that they have met their legal obligations, careful management of that volume of information is key to creating effective interactions. So, rather than including instructions somewhere on a page, consider providing interactive user assistance—showing, for example, any constraints on an applicant’s age as the user completes the date of birth field in a form.

In Summary

When a small UX team agrees on the design principles that they will follow, this can help the team to align—regardless of the existence of any standards or patterns. A set of design principles provides a concise, robust means of communicating with stakeholders, and designers can use them in the way that is most appropriate to any situation. 

Director at Edgerton Riley

Reading, Berkshire, UK

Peter HornsbyPeter has been actively involved in Web design and development since 1993, working in the defense and telecommunications industries; designing a number of interactive, Web-based systems; and advising on usability. He has also worked in education, in both industry and academia, designing and delivering both classroom-based and online training. Peter is a Director at Edgerton Riley, which provides UX consultancy and research to technology firms. Peter has a PhD in software component reuse and a Bachelors degree in human factors, both from Loughborough University, in Leicestershire, UK. He has presented at international conferences and written about reuse, eLearning, and organizational design.  Read More

Other Columns by Peter Hornsby

Other Articles on Principles

New on UXmatters