OUR PHILOSOPHY

This first appeared as an article in the Planfix blog in March 2011. Not much has changed since then, and we're publishing almost the exact same article here. We've added more examples, and our philosophy has become more apparent through our interface. There's a reason we reference this post often. It's crucial for understanding our approach to building the app. If you plan on using Planfix at your company and want to understand how it differs fundamentally from other systems you've come across in the past, we strongly encourage you to start with this article.
"Simplicity" is a trendy word nowadays. "Simple system," "simple interface," "simple features"— these are the mottos of the people creating most of the online CRM, BPM, and PM services available today. Initially, we also veered in this direction, and the word "simple" appeared on our home page at least twice. But if you take a closer look, you'll notice that even a basic thing like "simplicity" is understood differently by different people.
How do products like Planfix usually evolve?
The creators develop a simple data structure, such as "project-task-comment" or "lead-contact-deal." They make a simple design that uses negative space well. Then the creators begin using the system themselves and make it available to others
It's impressive at first
Feedback starts coming in from users: "Why don't you use to-do lists instead of tasks? It's not convenient for me to collaborate on tasks in your system and keep my personal to-do lists separate. Make to-do lists and I won't have to use any other apps except yours, and I'll invite my friends to use it, too."
Some time goes by
A new request from a different user: "You don't have 'events'! You should make them like a calendar, so we can arrange events like client meetings or debriefings."
And then...
As time goes by, suggestions and requirements begin to pour in: "We need discussions!", "Forums!", "Blogs!", "Make a chat!", "We really need news!".

The creators either fend off these suggestions or continue to pile on features and sections. Meanwhile, each time they create a new element and cram it into the interface, they're adding yet another turret to the sand castle we call "integration."

Requests pour in relentlessly: "Hey, we need to be able to add files to to-do lists as well as to tasks!", "I want to attach a chat message to a task so I don't have to keep searching for it," "Add the ability to turn to-do lists into tasks, it's really important!", "Why can't we add events for transactions in our calendars?!?!".
And another...
OK, this is important, and so we add another element and another section.
That sounds reasonable enough; to-do lists are important. Thus the system gets a new section.
There aren't that many ways the creators can react to these situations:
or they can build a megasystem, where different function blocks are very weakly connected (and often aren't even connected at all).
they can either stick to their sacred simplicity and not add new features.
In the end, the systems we were able to review ranged from having too few features to being bogged down by complexity overload, with a tendency towards complexity. In and of it self, this is neither good nor bad. It's just reflects the systems' standard evolution: from simple "single-cell" systems with very limited features, to dim-witted "dinosaurs" that can't even grasp that another dinosaur is biting off their tail.

It's very difficult for creators to make the strong-willed decision to leave a product at the "single-cell" stage, when everything around it is aspiring for growth. That's why most systems usually have arbitrary sets of features for organizing group work (blogs, discussions, chats, email), managing sales (contacts, leads, transactions, sales funnel), managing tasks (projects, milestones, tasks, comments, events), and individual planning (to-do lists, meetings, schedules). However, if you look closely, you can see that many of these elements have more similarities than differences.
See for yourself: isn't a task you assign yourself a to-do list? And a task set for a specific time during the day is certainly an event or meeting. Comments are still comments, regardless of whether they were left on a blog, a discussion, a chat, or an email. So why should we multiply these elements, increasing the types of data we're dealing with and inevitably running into problems when integrating them?
We noticed this challenge a while ago, and we've kept it in mind since then when planning new Planfix features. This is our philosophy, in brief:
We give you the ability to build a management system that encompasses your whole company, using a limited set of elements.
"
There are currently four Planfix elements:
Used to
group tasks.
The basic concept of Planfix. Everything in Planfix revolves around tasks. Tasks can have any number of subtasks, with unlimited nesting. You can add and remove fields from tasks as needed.
Any additional information you want to account for while working on tasks. This is a proprietary Planfix invention. Simple examples of data tags: earnings, expenses, time spent, etc.
Project
Tasks
Data Tags
"Information atoms" that reflect any changes in tasks: adding new files, adding comments, changing due dates, changing assignees, adding reminders, adding data tags, etc.
Actions
With Planfix, you won't find any "to-do lists," "events," or other features derived from tasks that are only slightly different from one another. That's how we've solved the problems described above, such as "we want notifications for to-do lists like for events" and "we want to be able to attach files to events." We are automatically able to do all of this, since tasks provide these features.
If a user asks us to add a new element to Planfix, we ask them to describe for us the difference between the new element and a task. During this conversation, it becomes clear that the only real differences are the name and the task settings used. The user can modify tasks themselves, turning them into whatever their team needs them to be, be that "to-do lists," "events," or "applications for production."

The name "task" isn't entirely perfect, anyway. It confuses users, and their usual understanding of the word limits them. If we were developing Planfix today, we'd probably call them something more universal, like "forms" or "objects." Maybe in the future we'll have to do that.

We understand that the Planfix philosophy takes some getting used to. Not all systems have an approach like this, so at first it can be difficult to accept that tasks replace all the usual system elements.
These are tasks without due dates, and the people needed for discussion are added to them.
Discussions
Let's take a few more examples:
These are also tasks without due dates. The "All company employees" group can be added as participants, if the news is for everyone. If the news is for just one department, add the appropriate group and only its members will see the news.
News
This is also a task, but you can add several additional fields, such as "Total transaction value." But working with these tasks isn't any different from working with other tasks. You keep in touch with the client, add the necessary colleagues, and complete the transaction according to the sales funnel (which you configure yourselves), until the deal is closed.
Transactions
It goes without saying that a simple internal structure doesn't necessarily guarantee simplicity in use. In particular, we still have a lot to do in terms of interface customization options. We're certain that in time we'll make the interface more clear and flexible, and we'll get rid of all the unnecessary little things and reduce clicks. And we'll use our clear and simple Planfix structure to do so.