Why Triggre is great for developers

At Triggre, we use our own product to automate a variety of internal processes. For example, we have applications for registering vacation leave, HRM activities, and invoicing. Having a tool for automating processes, we would be crazy not to use it and make our lives easier, right?

Yet, when our lead architect recently joined us for lunch and asked if he could get a new environment to create a simple application to track licenses of libraries used in Triggre, his request was met with raised eyebrows by some colleagues. Being an excellent programmer, couldn’t he just program this simple application from scratch?

Seeking the challenge

Now of course, our lead architect is perfectly capable of programming such an application by himself. But that doesn’t mean it’s his favorite task in the world. What he truly loves to do is work on more challenging projects, such as Triggre itself. Using Triggre for the creation of a basic application allows him to quickly focus on the tasks that he enjoys to perform.

It is because of those challenging tasks, that he started a career in development in the first place. Creating a form to fill in some data or making a ‘previous’-button in an application, are not those challenging tasks. And that’s why Triggre is so good for developers.

With Triggre, creating process related applications that don’t require hard technical knowledge, can be done by anyone within the organization. This allows developers to focus on more challenging, technical projects that no one else can do.

Slicing onions, potatoes and oranges

Take a chef, for example. A chef starts his career slicing onions, potatoes and oranges over and over again – important skills to master and it creates respect for the process.

As he gets more experienced, works in different kitchens and really becomes a master chef, he does not want to slice onions or oranges anymore. And why would he? He will probably want to start a restaurant and give people an amazing food experience.

But, now imagine the chef writes a cookbook and gives it to people to make his dishes at home. This gives the chef the opportunity to experiment with combining new flavors and creating really technical plates, instead of cooking his restaurants’ menu for people every night.

Because that’s what it’s all about for a chef – and it works the same with careers in development.

Automate the basics

If developers can use Triggre to add a form or create an application in no time, or – even better – if non-technical people in the company can do this themselves, developers get the opportunity to concentrate on more complex issues.

In other words, no more taking on tasks that can be automated by platforms such as Triggre. Instead, developers can again embrace the challenging work that attracted them to their field in the first place!

How much code can be used in no-code platforms?

Code in no-code platforms, that must not be possible, right? Because if you would be allowed to use code in a no-code platform, wouldn’t that make it a low-code platform? Well, the truth may surprise you.

What exactly is code?

This is a harder question to answer than you may think. Because the definition of what code is, depends a lot on who you ask. From a purely software engineering point of view, code is something that you can write, which is then translated to zeros and ones by a program called a compiler.

Only after the code has been compiled, you can use it. You can think of this as writing a letter in English, then translating it to Chinese in full, before handing it over to your Chinese colleague to read.

Over the years however, a lot of innovations have taken place in the field of coding. There are so-called Just-In-Time (JIT) compilers that don’t necessarily need to be run before using the code, but can compile on the fly, or ‘just in time’ for you to use it. I would still consider this code, but other experts might disagree.

In the analogy of the letter, you would let your Chinese colleague read while you are translating. Every time your colleague wants to read something, you make sure you translate it just in time. If your colleague suddenly jumps a paragraph, you do too, leaving the part in between un-translated until your colleague may eventually read it.

The real difference comes with languages such as JavaScript, which are mainly used in web-applications. JavaScript for example, doesn’t need to be compiled before you use it. Instead, it is ‘interpreted’.

Think of this as how the United Nations uses interpreters. They don’t translate any letters, but instead they interpret everything that is said on the fly.

This is distinctively different, because once you have interpreted it, the translation is no longer available. You’d have to translate again the next time the same text is spoken. In software engineering, this is called ‘script’.

Script isn’t code … or is it?

As a software engineer, there is a very big difference between scripting and coding. Mainly, script can be changed more easily than code, because code has to be compiled after it has changed. Script can just be changed and then used. From a technological point of view, scripting and code are very different.

The question of course is, though technologically different, how different are script and code to the person writing it? The answer is not all that different. JavaScript is, as the name suggests, script that is based on Java. And Java is code.

Today, the words are even becoming more similar in meaning, as it is now generally accepted to call writing JavaScript or HTML coding instead of scripting.

So whether we are talking about script or code, the act of writing it is more and more considered to be ‘coding’. And that is fine, because they are very similar to the person writing them. They often even look almost the same. You might be wondering why this difference is such a big deal. Good question.

No-code or no-script

Most no-code platforms are no-code because they don’t allow you to add any code. However, they will often claim that they can also be used for very versatile solutions. And one way of achieving that versatility is allowing the user to code, eh, script.

If the user can script certain things, such as the user interface by using HTML, then the platform is strictly speaking no-code. Whether as a user you experience it that way, is a different matter entirely of course.

I believe that the only real solution is to simplify the design process to its bare essence, eliminating a lot of the reasons to want scripting. For business users, a simple solution is often favorable over a more complex solution that has broader applicability.

Therefore, the option to use script for modifications should be considered to be coding. And should ultimately not be allowed in no-code platforms, in favor of a much better and easier user experience.

The difference between low-code and no-code platforms

In my earlier post I talked about the rise of no-code platforms as the next step beyond low-code platforms. We briefly looked at the difference between them, and in this post we’ll take a closer look at some of the distinct differences between low-code platforms on the one hand, and no-code platforms on the other.

Target audience

If you’ve read my other post, you already know that one of the major differences between low-code and no-code platforms is the target audience. Low-code platforms are aimed at developers.

These platforms require technical knowledge, and allow good coders to work faster. The more powerful the tools to speed up technical development, the better suited it is for coders.

No-code platforms on the other hand, target business users. These platforms provide no way of manually editing code, and instead focus on creating the best and easiest user experience possible, abstracting away from technical details. The easier the user interface is to understand, the better suited for business users it is.

This difference is a trade-off. Low-code platforms still require some code, because they are aimed at being able to create a very wide array of software solutions. To make sure the developer has the control they need, coding is still an important part of the development process.

No-code platforms however, abstract away from all the technical details. While being applicable for only slightly fewer use-cases, this makes no-code platforms much easier and faster to use.

Closed system

The other big difference between low-code platforms and no-code platforms is openness. A system that is open, allows it’s users to make changes to how it works. In low-code platforms this is done by allowing the user to change or add code, which affects how the application works.

The advantage is that this opens up the system to a lot of custom added code, making it applicable to more use-cases. The big downside however, is that this limits backwards-compatibility.

All low-code platforms suffer this problem, which is at the core of their architecture. Any new version that changes something in how the platform works, will affect customers who are using custom code that uses that functionality, because it now works differently.

This means that with any upgrade of the platform, all customers must spend time testing whether their software still works. If there are any problems, the custom code must be changed before they can upgrade to the new version of the platform.

No-code platforms on the other hand, only have a single version at any given time. When a no-code platform gets an update, customers need not worry about any breaking changes, because it is a closed system.

There are simply no points where custom code is permitted, which means that an upgrade cannot break an application. This is a huge advantage, as it gives users the ease of mind that any upgrade is simply immediately available, without having to spend any time testing.

The Triggre approach

Triggre has focused on these 2 aspects that set no-code platforms apart, from the beginning. We continuously update our designer to have more options, while making it easier and faster to use at the same time.

Triggre also has the advantage of being a completely closed system. Of course Triggre allows you to connect with other applications in an easy manner, but it keeps you from adding any code.

This provides our customers with the ease of mind of knowing that their application will still work, even when they want to make a change a year from now. But we take this even further. When we release a new update to our platform, we publish all of our customers’ applications, so they are sure to get any improvements without ever lifting a finger!

The rise of no-code platforms

Recent years have given rise to many low-code platforms. A low-code platform allows coders to gain a higher productivity, because a lot of the tasks they normally perform can be done in a visual editor, from which the platform generates code.

This process is about 2 to 8 times faster than regular coding, according to the many whitepapers on suppliers’ websites. The coder can then manually work with the code to make his own adjustments. Low-code platforms are like catalysts for coders.

No-code platforms, for lack of a better categorization, are platforms that do not require the user to write any code at all to create an application. In many ways, no-code platforms are seen as the next step after low-code platforms.

Because what is less than low-code? Exactly, no-code. It seems logical, but the truth is that low-code and no-code platforms are completely different.

Demand for productivity

Behind the popularity of both low-code and no-code platforms is a world-wide demand for higher productivity when it comes to creating applications. Globalization has had a very interesting effect in making the world seem very small.

A supplier in China can just as easily sell its goods in the US as it can in Japan, over the internet. Effectively this means that many companies have seen an increase in the number of competitors in their markets.

With more competitors, it becomes increasingly important to have a competitive advantage. And because an ever larger part of business processes are supported by software in the form of business applications, it means that companies turn to custom software development.

Standard software, in other words software that can also be used by your competitors, doesn’t provide a competitive advantage. If every company uses the same software, none of them are unique, thus none have competitive advantage. This is why the demand for custom software is growing with roughly 35% year over year.

Custom software is normally written by coders. The world-wide increase in demand for custom software, therefore leads to an increased demand in coders, or coders with higher productivity.

This is the driving force behind low-code platforms. They increase coder productivity, which means more custom software can be created.

Too few coders

The big problem, world-wide, is that there are simply far too few coders. It doesn’t matter if we make every coder 10 times more productive. It won’t be enough. Demand simply grows faster than supply in this case.

This problem is slowing down companies today, and will slow them down even further in the very near future. With too few coders available, companies simply cannot create the custom applications they need to stay ahead of their competition.

The risk is that many markets will see a winner-takes-all situation arise, where the company with the deepest pockets is the only one that can innovate quickly enough to gain a real competitive edge. Others will simply be bought out, or won’t survive at all.

Emergence of no-code platforms

If there are too few coders to fulfill the demand, we need a different solution. This is where no-code platforms come in to play. No-code platforms target a different user than low-code platforms.

While low-code platforms require technically skilled people to operate them, no-code platforms are made for business people. People who have the ideas for applications, but lack the traditional technical skills to make those applications.

The way you can distinguish a no-code platform from a low-code platform is fairly simple. Look at the user-interface. Is it as simply as possible, and does it aim to help you decide which option you should choose every step of the way in making an application? Or does it rely on knowledge you should have learned about how applications are built?

No-code platforms require zero technical knowledge and this shows by them have an extremely easy to use interface.The simpler the user interface of the platform, the more sure you can be that it truly is a no-code platform!

Why standard software is expensive to customize

“This software product already does 90% of what we need.” If only I got a cent every time I have heard this. It is the most ridiculous argument there is for standard software versus custom built software. When companies or teams select software, it is a common mistake to look at the percentage of functionality covered. Doesn’t a 90% coverage mean it’s just a small step to get exactly what you want!?

Adding a floor

Consider a high rise. 50 floors of exquisite architecture, exactly in the right location. And it’s super affordable. If only it had 2 extra floors…

The solution might be simple. If you need 2 floors added on top, that might be a viable option. Perhaps the elevator won’t reach them, but it wouldn’t be extremely expensive to do.

It’s a slightly different story when you need a double basement underneath the building. It’s still possible, but far more expensive.

The ultimate case however, is if you absolutely need to add two floors at the bottom or in the middle of the building. I am sure it can be done somehow, but I bet it’s cheaper to build a new building.

Adding a software floor

All three cases with the building add 10%, but it seems obvious that they are not equal. In software however, we somehow assume they are equal.

So whenever you consider ‘adding a floor’ to standard software, make sure you fully understand exactly what the impact is. No matter how configurable the software is, how many happy customers there are that ‘do things in the same way for 90%’ – if you try to add the wrong floor, it’s going to cost you.

Pulling back the curtain: a behind-the-scenes look at Triggre

A little while ago, I test drove a Tesla out of curiosity whether it would live up to the hype. In my eyes, it wasn’t all that special; it’s a pleasant and luxurious car, which I’d only expect for the price.

My interest was much more piqued by the almost bare undercarriage that was in the showroom. You could see where the batteries are located and it gave a sense of how the electro engines work. Since I’m probably not the only one who likes to see how things work underneath the hood, I will pull back the curtain on Triggre a bit today.

As previously discussed, Triggre consists of three parts: the Designer, the Builder and the application itself. The Designer of Triggre has about one million lines of code dedicated to only one thing: making designing an application as easy as possible for the user.

After users design their application, they hit the ‘publish’ button. That’s when Triggre-engine really starts running, because approximately thirty seconds later, the application the user designed is up and running in the cloud. So what happens in those thirty seconds?

From designer to up-and-running application

After the user hits ‘publish,’ the entire design is checked once more for inconsistencies in about a second. These can occur, for example, when you have deleted a page and you can no longer reach another page in your application.

Once checked, the design – including all forms, pages, buttons, and processes to be automated – is sent to one of our builders, where it is placed in a queue. Since we have several builders, however, it hardly ever happens that you actually need to wait.

The builder then writes the Javascript, .Net code for the backend, and SQL scripts to set up or migrate the database – briefly put, it writes the application. As our builder can write thousands of lines of code per second, programming the entire application is usually just a matter of seconds.

Installation packages

Like many applications, the code is compiled into a program and an installation package is created. If you are unfamiliar with web applications, this installation package is not completely unlike how you can download a program from the internet and install it on your computer. That too is an installation package of sorts.

Unlike those installation packages, the installation packages of your Triggre application need to run in the cloud, where it automatically is installed besides your already running application.

Once the database migration is completed using the created SQL scripts, the old application goes offline, and the new one goes online. This entire process takes up approximately thirty seconds, after which you can start using your new application!

What then happens, occasionally shocks some people: as the builder cleans up some files, the entire source code of the program just created is thrown away.

For many companies, the source code of a program is a very important commodity and the fact that we simply discard it is foreign to a lot of people. What however is the worth of keeping it, when it can be completely rewritten in a matter of seconds?

Creating an application in seconds, weeks, or months?

What our builder accomplishes in a mere thirty seconds takes the average IT company’s programming team weeks or months. Adaptations to an existing application would require another weeks-to-months-long process, whereas Triggre can implement these within another thirty seconds after your hit ‘publish!’

Maintenance on software is just like car maintenance: you’re getting played

In 2008, I brought my car to the shop for a periodic check-up, because it had a problem. Sadly, the check-up showed my car was in desperate need of repairs. The mechanics told me that it was probably not worth the cost.

It was a very, very old car and I had seen this coming for a while. Still, a mechanic telling me I’d best buy a new car, wasn’t really what I had in mind when I brought it in.

Adhering to a strict schedule

My first car was an old second-hand one. To be honest, I hadn’t been too strict with the maintenance windows. So, when I had to suddenly replace it, I vowed that when I would buy a new car I’d always take it to the shop on time, to make sure it was always in perfect condition.

The upside of taking your car to the shop on a regular schedule is that it is indeed always in great condition. The downside however: you get told by mechanics that something needs to be changed and you basically don’t know whether it is strictly necessary.

So, you have them replace it. When it comes down to it, this means spending a lot of money on things that do not seem broken.

Maintenance on custom built software

Any application that is custom built, or has a custom built component, will require maintenance. The simple fact of the matter is that the world around that application or component changes, which may require the application or component to change in return.

This is actually quite similar to owning a car. You buy the car, and because you use it, it requires maintenance. Just like software requires maintenance, due to the world in which it is used changes.

You bring your car to the shop for a check-up, the same way your software requires some maintenance every once in a while too. All to keep things running smoothly. For custom-built software however, most companies do not perform maintenance as often as is required.

Instead, they prefer the method to use it for as long as humanly possible, after which the whole thing needs to be replaced. Much sooner, though perhaps at slightly lower cost, than performing periodic maintenance.

Knowledge gap

If it isn’t broken, don’t fix it. It seems like sound advice. But if you don’t, it means using everything until it is absolutely worn down and replacement becomes paramount.

There is a huge gap between following every advice from a car mechanic and only replacing parts when they’re totally worn out.

This gap is a knowledge gap. If you’re like me, you don’t know everything about the car you own. This puts me in a disadvantaged position whenever a mechanic tells me something needs maintenance or replacement, especially if it isn’t causing a noticeable problem.

If I trust the mechanic, I’ll let them replace it. If I don’t, it is usually about time to bring my car in to another shop.

Bringing your software to another shop

In the past, I have switched shops for car maintenance a few times. This is fairly simple, since cars are a common thing and there are many shops that can service my needs. If I am unsatisfied, I simply take my business to a competitor.

And for software it’s pretty much the same deal, right? Software is very common. There are many companies that can build software and maintain it. So if I am unsatisfied, I can just switch to a competitor, just like I did with the car. Or can I?

The problem is that software, especially when it’s custom built, requires an understanding of how it works. Most applications also communicate with other applications, and are implemented to support a business process.

This makes understanding ‘how it works’ a lot harder. So, unlike bringing your car to another shop, bringing your software to another ‘shop’ would cost a lot of time and money.

The new shop would first need to get a good understanding of your business process, the other applications that the software communicates with and then understand the code of the application itself.

No leverage

Inevitably, you are left with without any leverage. Because if you cannot bring your software to another company easily, you only really have 3 options:

1)      Don’t perform any maintenance at all
2)      Just accept anything that your supplier tells you should be done
3)      Insource maintenance of the application

We believe that this status-quo should change. Not performing maintenance means losing innovative strength, since adapting software to changing processes or markets is no longer an option.

Accepting anything that your supplier sells you will cost too much money for what you are getting in return. And lastly, insourcing maintenance is extremely costly, if not impossible, due to the shortage of IT professionals.


Triggre strives to give companies back their freedom when it comes to implementing and maintaining software. Just having the option to make software yourself (without IT specialists) is a game changer, which makes you far less dependent on external companies – including us.

Behind the scenes

It has been a while since we updated you on our endeavors regarding adding more and more functionality to Triggre. This, of course, does not mean that nothing is happening. Behind the scenes, the work never stops.

Success is a process

When we released our current version, we had already put in countless man-years of work into it. The danger of delivering such an enormous project is that when you are done, you relax a little, sit back and enjoy your accomplishment.

Not at Triggre. As mentioned by our CTO Jesse in his interview about the new version of Triggre, we have set big goals. And in order to achieve those, we need to constantly reevaluate the way Triggre works. Only when we do that, we’re able to keep improving. We want to empower people and make software creation fun. As you can imagine, we will not reach this goal overnight.

What does happen overnight

One of the things that do happen overnight, is making a new release available to our customers. Since the major release on the first of September, we have had 6 smaller releases, all chock-full of new features and big improvements.

So, what kind of improvements have we been making? First, we started with bettering the user experience of Triggre, making it even clearer what you can edit and when. Then, we started adding more functions to our rule editor. This allows the user to create rules to add and remove items from lists meaning manual work is reduced even more.

In the release after that, we went for another functionality feast with the introduction of pick lists, allowing the user to easily create and reuse simple lists. With this feature the speed at which you can create your own application increased, again. And with the following release, we added automatically generated “create”, “edit” and “delete” functions for your data as well as an add-on to the pick lists. This add-on allows you to pre-fill form fields with items from your list, so the users of your application are guided in the right direction.

We also introduced two killer features in November. The first are repeat actions, which allow the reuse of parts of a process to make a process even more powerful. The second is creating and storing signatures in Triggre. You can even sign directly in Triggre, using your mouse or finger on a touch screen. Since electronic signatures are legal in Europe, this provides a huge opportunity in digitalization for our customers.

Full speed ahead

As you can read, we are always on the lookout for new, cool and useful features for Triggre. If you are curious about these new features, you can always check our release notes. If you have ideas, make sure to let us know. Together with our customers, we find the right enhancements for Triggre and we fully intend to keep going at this pace!

Author: Dagmar Ingelse

1000x Faster than Programming – Part 3: Our Strategy

In my previous two posts, I described the Simplicity / Functionality diagram and explained what the pitfalls of certain strategies are. In this third and final post of this short series, I will explain our vision on getting to Quadrant 4.

For Triggre this means that it is usable by business users, who have no technical knowledge, and think in terms of business processes and applications that support those processes. This usability must be combined with our aim to become 1000 times faster than traditional programming. Or in other words, 3 orders of magnitude faster.

The first step

We first started with the idea that ultimately led to Triggre in 2009. What we envisioned was a software platform that was so easy to use, and so fast, that you could pick up your smartphone and make a change while doing your daily commute with public transportation. Going from a vision to a product, especially as technically challenging as Triggre, is a big step. That’s why we decided that it would be best if we first introduced a Minimum Viable Product (MVP).

That product was designed, developed and tested between 2010 and 2013. By then, it still very far from our goal. It was fairly easy to use, but required a low level of technical knowledge to really get the most out of it. In the hands of experienced users it was fast though.

When creating the Triggre Benchmark, the record was set at 140 times faster than programming. That meant we were well over 2 orders of magnitude faster than programming. It was a big win for us though, since we had proved that the technology could work.

With our MVP we had immediately entered Quadrant 2, though we were far to the left and not that high up.

Steps toward the Holy Grail

By now you understand that in order for us to ever reach Quadrant 4, we would have to do something drastically different at that point. Becoming easier to use while offering more functionality is hard as it is, but our challenge is to combine this with a third order of magnitude in speed as well.

So our first move would be up, and then right, which requires a completely new concept. Preferably one that is prepared to subsequently move right in the diagram (at least a little bit) too and allows us to increase the speed as well.

Where the first point in the diagram is our first release, point 2 in the diagram is our recent release, code name Gulliver (September 1st, 2017). We gave it a code name because internally simply referring to Triggre wouldn’t work, since building this new version would take a long time.

For Gulliver, we went back to the drawing board. We decided that we should forget the Triggre Designer as it was then completely. We would throw everything away, and design a completely new concept.

Because with the knowledge we had acquired during the development of our MVP we could now design a new work flow that would solve those things that our customers still found hard to do in our first version. Instead of putting a band-aid on those things, we redesigned Triggre completely, aiming to achieve all of the big, hairy, audacious goals we had set.

Another order of magnitude

With a completely new concept, we already knew we were going to be able to develop applications much faster than before. Currently we are making a new version of our benchmark, to reflect this increase in speed, and we have a new record. Triggre is now 337 faster than programming at the maximum end of the spectrum. Not quite 1000 times, but not bad either.

While we were designing our new concept, we anticipated many more improvements. But to make sure we wouldn’t be developing forever, we scaled down our development as much as possible to get the absolute minimum of functionality that would work. That means that we still have many options to improve speed and ease-of-use, allowing us to move right and slightly up even, in the diagram!

More to come. And more. And more.

Triggre as it is now, is already a product we are very proud of. And the good news is that it will only get better. Our new concept allows for many more improvements that we will be making in the coming years, with each release either increasing functionality, improving ease-of-use, or increasing speed. The last two releases are already testament to this continuous improvement strategy.

Only 2 weeks after our big release on September 1st, we released our first improvement to increase functionality. We added new functions to our very easy-to-use rule editor, making it possible to create even more powerful business rules in an even simpler way.

Another 2 weeks later, on September 28th, we released a change to our data model that allows you to manage small lists in the designer. This means you will need less data items to achieve the same thing, while being easier to use. In other words, this release moved us up and right in the diagram at the same time!

Most recently (at the time of writing), we released a huge improvement. When you create a data item, you almost always want to be able to add, edit and remove those items using flow parts. That’s why we now generated those flow parts automatically, and keep them up to date as you change your data model. This increases development speed immensely.

We never give away what we have planned on our roadmap, but rest assured we will keep the improvements in speed, functionality and ease-of-use coming your way for a very long time!

1000x Faster than Programming – Part 2: Impossible Strategies

In my previous post I discussed the simplicity / functionality quadrant, which gives a good starting point to discuss strategies. If you haven’t read that post, I suggest you read it first and then return to this post. For reference, this is our quadrant:

Moving to another quadrant

There are many tools that live in quadrant 2. Complex, powerful tools that, when used by an experienced user, can deliver stunning results. Adobe Photoshop is a good example such a tool. It has so many options, I could probably write 1000 blog posts just covering the options, not to mention their many use cases. But these options come at the cost of high complexity, or in other words, the application is hard to use. So hard, that many books have been written about it, hundreds of pages each.

It is extremely hard to create an application that has the same power, yet is much easier to use. For example, Instagram is much easier to use, but far less powerful than Photoshop. Instagram therefore, lives in quadrant 3, where all easy-to-use yet less powerful tools live. The big question of course, is how do you get to quadrant 4?

Overcoming complexity

Let’s start by taking a look at those applications that currently reside in quadrant 2, the powerful, unwieldy tools. The shortest route for such a tool would be straight up, just make the application easier to use:

The problem however, is that it is extremely hard to make a powerful tool simpler. Often, in order to move even a little bit in this direction, a completely new concept is needed. If we take Photoshop and Instagram as an example, Instagram is a completely different concept than Photoshop and that makes it easier to use.

On the downside, it means it is less powerful. If Photoshop would ever want to reach quadrant 4 (which I think they don’t, but that’s a different discussion), they would have to start from scratch and come up with a completely new concept of how to do photo editing.

That concept must immediately be complete, because users will not accept less functionality in a new version (except for small changes that offer slightly less functionality). That means that they cannot move left on the diagram while moving up at the same time:

Both strategies are equally impossible. In the first case, the costs would be too high since every line of code would have to be rewritten in a completely redesigned concept. In the second strategy, the same concept is used, but only a part of the functionality is rewritten. Other options will be added later, to move into Quadrant 4.

This will never be accepted by users however, since they are accustomed to the functionality they have right now. That means it is extremely hard to move from Quadrant 2 to Quadrant 4, if not completely impossible.

Overcoming lack of functionality

But what if Instagram would want to move to Quadrant 4? The quickest way to get there is to simply move right along the axis of functionality:

The caveat is that this is not as easy as it looks. Simply adding more functionality results in more complexity. In other words, if you add more buttons to your application, it becomes harder to use. And instead of simply moving to the right, the application would quickly fall towards quadrant 2 instead:

The only remedy here is to have taken into account adding new features when designing the concept of the application. Much like adding simplicity is hard because it requires a different concept of how to use the application; adding features is also hard because it requires the concept of how to use the application to anticipate adding more functionality while remaining easy to use.

Instagram for example, is easy to use because it uses filters. If they wanted more functionality, they could add many more filters. But that would inevitably make it harder for the user to find the filter they want.

The holy grail

Getting to quadrant 4 is therefore very hard to do. It requires a deep understanding of the problem that the application or platform is trying to solve, as well as much creativity in devising a new way to do so. Instead of thinking in terms of features, or usability alone, designers must think in concepts. And most importantly, designers must be willing to design a new concept from scratch in order to move into quadrant 4.

Get your own personalized walk-through to discover what Triggre has to offer, in only 10 minutes!

By signing up for your personalized walk-through, you agree to receive e-mails from Triggre.