In the previous two posts about our design philosophy you could read how we decided to build Triggre and why we chose simplicity as the core of our design philosophy. In this post I will give you an insight into how this design philosophy works in practice and how it shapes our ideas and our roadmap.

Putting Simplicity First

Putting simplicity at the core of our design philosophy had a few major implications when we first started developing Triggre back in 2011. To understand this, we need to get a little bit technical. Don’t worry, I’ll keep it light. Triggre consists of two major parts. The designer, which is what you use to design an application, and the builder, which takes a design and builds the application.

The important thing to understand is that the user only interacts with the designer. So this is the part that needs to be simple to use. The builder however, has to be able to make basically any application, so this will inherently be complex. But, as John Maeda wrote in his book The Laws of Simplicity, if we can hide that complexity, it will appear simple to the user.

Designing Triggre

You would think we would start from the user’s perspective then, making our designer as easy as possible and then we’d create the builder to work together with the designer. We decided to do it the other way around however. Mostly because we knew what types of applications would need to be created by the builder, and had a good idea of how we wanted that part to work.

The designer on the other hand, is one of those things where if you see it, you start to see possible improvements. Add to that the fact that without each other, both the builder and the designer would be useless. And to make things worse, we had to design all of this from scratch. I mean, there’s no way you can iteratively build a first version of something like Triggre, so we had to design everything up front and get it (mostly) right the first time around.

This had a big impact on our roadmap. It meant we decided to make our designer good enough, but make the builder work perfectly. This way we knew that any application that could be made using the builder was fast, reliable and technically sound. We would then improve our designer later, making it even simpler to use.