Simplicity is complicated!

Why are the apps I work with so complicated to understand and use?

I have never found applications more complicated, more incomprehensible than the ones I have been using internally in my company being either corporate applications or either apps we bought from outside.

Let’s take Salesforce for instance, even if such product could look simple, we have been building so many pages with so much information, so many rules, so many processes that none of the Sales is now able to understand anything about what he is supposed to do with it.

The same happened to JIRA, we configured such basic Task tracking platform in such way that you may need now a Master Degree and Super Advanced Certification to understand the thousand of fields you need to fill each time you find a bug and want to create a new Ticket.

Internal applications we built on Development side are even worst, these are so complicated that only very few end users really know what the application does and how to use it. They even sometimes get from such knowledge some kind of insurance that they will never get fired, as their departure would also mean the departure of the precious knowledge about how to use the app…

The reason for that I believe is that people building these apps or configuring these are not the ones using these!

Ask a developer to use the app he developed during two months, every day, doing the same things that end users are supposed to do on a daily basis… I can tell he will be changing the app superfast and will make it much easier and faster to use.

There will be no need to make a plan, no need to track all improvements for next 2 or 3 years. He will be implementing all of these like superman in just few weeks!

So we decided to avoid doing these same mistakes and start developing applications by making sure that developers would use the app being developed every day during the development phase and even later.

To do so, we assigned application use case execution to developers, so they had at least one hour per day, a session during which they were forced to use the app and do what end users were already be doing or would be doing in the future when the app is complete.

If at the beginning there were complaints, all developers quickly understood the benefits of doing that. We had some kind of regression testing done everyday doing that and performance testing too. Developers complaining about the difficulty of use of some features, the overall latency of the app, … tracked all new issues by themselves and got these fixed very quickly.

We have seen appearing some kind of natural responsibility for developing better feature and testing these better too. Each developer took responsibility of tracking improvements he was thinking were really needed for better end user experience and developed the corresponding fixes very quickly.

It happened the same with one of our last app we built called TipiCalls, being a conferencing and collaboration platform, it was easier to have developers using it by default and as we had to meet, chat on daily basis and used also the Task tracking feature too.

For such application, we have also then seen developers coding all these features the way they wanted them to be, not the way a business analyst not using the app may have wanted and put down into a document at some point.

This generated some simplicity and fluidity within the app, I believe. If you want to discover an application which has been developed this way, you can try TipiCalls.

I hope this article helped.

James from Tipicalls.com