Creating Design Principles

Note: I wrote this before I left AppNexus to go to Spotify, but forgot to publish it 😬. Posting it now for posterity

The AppNexus design team believes that consistency can help make the user’s life easier. Primarily, we’e been focused on consistency at the micro interaction level, but it’s just as important to make sure we have it at the high-level. We worked on creating design principles to make sure that we were all designing with similar goals in mind.

The idea of design principles intrigued the design team when Julie Zhuo published an article on their importance. We created a small team (Creatively called the Principles Team) to lead the development of the AppNexus design principles.

Format

One of the first decisions we worked on was what format they should be in. Facebook’s were written as goals, Salesforce released theirs around this time as a prioritised list.

Dustin Senos ✌️had written up Medium’s design principles, which were written as dichotomies. His justification was that principles had to involve tough decisions, otherwise they don’t add value to the specific company. Inspired by this, we decided to go with the dichotomies, and one of mantras became:

Design Principles shouldn’t just equate to “Do good work”

Little did we know that deciding on the format would be the easiest part.

Generating Dichotomies

The next step was to start figuring out some dichotomies that existed in design. The Principles Team did a task with the full UX team where we asked them to create post-it notes of goals for good design. There were lots of great answers like: discoverable, clear, obvious, efficient, simple, beautiful, etc. We grouped similar words and then started trying to put them into dichotomies. This lead to some interesting discussions about semantics and similarity.

Is discoverable the opposite of simple? It’s easy to make things discoverable if you throw things on the page.

In the end we had about 12 different dichotomies, which was far more that anyone could remember. 5–7 seemed like a better number for us to remember

All of the dichotomies we ended up with

Choosing Dichotomies

Each member on the principles team took a stab at simplifying the principles down to a few. We came back together to talk through everyone’s lists and see where overlap existed. If you hate arguing about semantics,this is not going to be a fun meeting for you. It turns out that a lot of the design goal words had surprisingly different meanings in everyone’s minds. This meant a lot more discussion about semantics and which words were opposites. In a lot of cases the words we went with weren’t opposites, but rather trade-offs that we frequently had to make.

Then we had to decide which was ‘more important’ for our product. This involved another activity with the UX team. The Principle Team presented back the dichotomies that we had and then took votes for each dichotomy. In some cases there were clear winners, but in other where people were split, we had some discussion.

Efficient over Usable

A good example of the processes is our most contentious principle, “Usable vs Efficient.” We wanted to capture the choice between making something that a user can immediately figure out, vs making something that an expert can do quickly. Obviously, in an ideal world, a design would be both, but sometimes we had to prefer one.

The dichotomy started off as “Easy vs Efficient.” Some people saw “Easy” as meaning “less work” and almost synonymous with “Efficient.” “Discoverable” was also proposed, but it was being used in another dichotomoy. We discussed a few other words and decided on “Usable”.

Efficient was prioritised for a few reasons:

  • Our users are in our product for 8 hours per day so they learn many of the intricacies of our system
  • When we asked users what was most important they said “efficiency.”
  • We have a lot of training programs for our users, so even if something isn’t initially discoverable, we hope to make it learnable and efficient.

Stakeholders

Initially this started off as a design team exercise. It was supposed to be a tool to help us design more efficiently. As more stakeholders heard about it, however, they had a lot of feedback. Especially since our principles were strongly opinionated and some people strongly disagreed with them.

The principles

What did we decide on that was so controversial?

  • Efficient over Usable —When we asked users, all of them said the most important thing was efficiency. They’re in the system doing the same tasks for hours on end, so every second saved adds up.
  • Simple over Thorough —Simpler interfaces allow users to focus on high level thinking instead of minutiae. Our users are skilled employees, they should be freed to think strategically and creatively.
  • Guided over Freedom —A guided UI allows us to help users make the right choices without shooting them- selves in the foot. Designers have insight into the mistakes that users can make, so we can guide them away from errors and to- wards success.
  • Appropriate over Consistent — The bene ts of consistency are that it helps users learn to use the system. However, when consistency gets in the way of ef ciency or usability, then it makes sense to deviate.
  • Learnable over Discoverable —Users only spend a short amount of their time being new to our interface elements. There are also speci c on-boarding tools to help get them past the initial discovery.
  • Visual over Textual —Visuals are important for understanding the context of data, can help expose trends, and increases the perception that AppNexus products are powerful.

Piloting

Since they were quite controversial we decided to hold off on “rolling them out” and instead decided to pilot them for a quarter to see how we used them and if they did in fact match up to the decisions we made.