Background

When I first joined Statuspage, the working process of the team was still stuck in startup mode, like this: The product owner got an idea upon observing people around him, or from his own need; then himself or the designer (if they had one at the time) sketched it; then the engineers built and launched it. If no one ever contacted the support team to complains about it, then that was it. They assumed there was no need to fix it, and moved on.

This process worked in the beginning because the product users were a small group of people who were very similar to the team itself (tech startups) and the product was simple: the features were not complex. The product proliferated by fulfilling customer requests quickly and remained at the top of the market for years. However, when the product was preparing to integrate into the Atlassian product line, it needed to expand product users to a more significant group: giant tech and non-tech companies. Often, decisions about which features should be built first led to arguments within the team. Without an apparent reason for the features, it was hard to align the team to go forward.
 

Why We Need Design Principles

For years, Statuspage remained at the top of its market because the product has very friendly user interfaces. When we asked our users why they would recommend Statuspage to other people, 9 out of 10 had the same answer: “it’s easy to use.” However, when the product got more and more complicated, we started to see inconsistent reasons for why features should be built. To align our team, we needed to have a set of design principles as a guide.

To start the conversation, the design manager and I looked through what other good products have as their design principles to get some inspirations. We copied some of them if we thought they might apply to Statuspage. Then we went through the list one by one, based on use cases the product is applied to, and removed or added what we thought was right. Eventually, we drafted five design principles:

1. Pride Matters

2. Persistently familiar

3. Brutally clear

4. Simple over powerful

5. Lighten the load

Then we shared these five principles with the product stakeholders. After that, based on the conversation with them, I removed one and updated some definitions. Here is the final result:

1. Brutally clear

We respect that the product is used when things go wrong for our customers. When emotions run high, they need things to be exceedingly clear in the product so it can perform well for them. This includes interactions, language, UI patterns, content, and flows.

2. Persistently familiar

Our UI, interaction design or flows are consistent across different parts of our products. Even though each part would need to adjust for its own use cases, users would still feel familiar with them, like meeting siblings from the same family.

3. Simple, then powerful

Our default user experience is designed for the novice but can be configured for the pro. Users of all experience levels should feel comfortable using Statuspage.

4. Trust matters

We believe trust is the foundation of a long-term relationship and ensure our customer looks trustworthy to the world. We elevate the trust people have for our customers by ensuring that we show the right kind of data displayed in a flattering way while being authentic.

 

The Influence

One of the key principles we set here is “Simple, then powerful.” It is a strong statement, and the team was hesitant about it because it sounds like we decided not to develop new features in order to remain simple. However, with this clear statement, the stakeholders agree that in design we separate the product features into two tiers: Publish/update incident message is the first tier of the product, those should always remain extremely easy to use, and the user flow should not be confused by extra functions. And we always go back and make sure the first tier is simple to users when we are adding new features.