Product design | understanding of tasks, project management design

The project management, task management is a concept that has been played badly by various products, but playing bad does not mean playing well ~ even if the current network is full of all kinds of such tools, each tool has its own focus, but if you want to use it to put on my scene, it seems to be very weak ~ why ~ user scenes are too much and too complicated ~ simple to play, complex and difficult to use ~

so what to do?!

before doing this part, we visited the core users many times to listen to their ideas for the product, the demand for the product, and the design plan was changed again and again, but it seems that there are always some scenes that our design cannot cope with, and there are always some scenes that we cannot meet ~ very headache ~ ~


looking back now, we were caught in a misunderstanding of designing to solve a single problem, and solving the user's problems one by one would not form a complete and effective solution.

without a global perspective, the core problem can never be solved.


When Fabricator was introduced to the company, this new style of play stimulated the nerves of many people, and everyone began to study its difference from other tools, and the software that Facebook can use for task management will definitely not be just because it can be associated with git and code

Personally, I think that the reason why Phabricator can play is because it decouples the task and the project, and many tools recognize the task, thinking that the task must rely on the project and exist, and there must always be a space to carry it. 

 

As everyone knows, this in itself is a very strong binding. In fabricator, tasks do not require such a strong binding, and tasks and projects become siblings, with a simple association similar to a tag in the middle, and can be unraveled at any time. In this way, the task becomes a single body, and the user does not need to run between the various projects to see their tasks, but only needs to grasp the attribution of these tasks on the task page.

Redmine

Our team has been using Redmine, although in terms of user experience, many students have complained, but redmine's design in task management fully illustrates its understanding of the term task. Students who have used Redmine know that the two most common objects in Redmine are projects and issues. Everything is issue, whether you're a requirement, a task, a bug ~ Redmine just thinks it's a property of issue, that's all, it can be changed, it can be changed, but the content is still the same.


Another very effective design provided by Red mine is the concept of father-son products and father-son tasks, many project management tools on the market will not be too involved in this part of the concept, because once there is a father-son level, the display of the product interface, the inheritance between father and son, and various configurations in the product will obviously improve the complexity of the product, especially in most products, tasks and projects have a strong binding relationship, which will further limit the creation of tasks. The user's perspective on the task will become more jumpy.

found

Combining the understanding of project and task management of these two products, as well as the analysis of tasks and project management tools such as etc., combined with our unique user scenarios, we found that:

• decoupling the relationship between tasks and projects is important.
• at the same time, we also found that the so-called tasks, requirements, defects, etc. are just a property of the task, we do not need to limit what the user submits, the user can determine its category according to their own definition.
• at the project and task level, adding a layer of parent-child relationship can be more beneficial to the classification and expansion of projects and tasks, and it is more in line with the use scenarios of our users.
• labels are an effective grouping tool, we have tried to let users manage their own tasks and projects in groups, but found that in many scenarios, tasks may need to appear in multiple groups, and the common grouping pattern cannot meet these needs. however, the management method of grouping and classification has its unique convenience, at this time we introduced the label, the label can be seen as a very lightweight grouping method, and the readability it brings is not worse than the grouping, and the scalability is stronger.

tasks section

based on the above conclusions, we have made the following design for the task:

• lightweight the creation process of tasks, give tasks more attribute types, such as requirements and defects, so that the task is oriented to a wider user base.
• decoupling the relationship between tasks and projects, tasks can exist without relying on any project or any product. at the same time, tasks can be associated with multiple products and multiple projects.
• tasks can be disassembled into multiple subtasks, in order to avoid overly complex hierarchical relationships, we only retain a layer of parent-child relationship, and subtasks inherit some of the properties of the parent task by default.
• allows tasks to be tagged, and the tagging operation is completely freed up to the user.
• in terms of display, we have changed the long-standing "list" domination of tool products, and adopted a new item method to display task lists and parent-child display effects.

color, the different types of tasks are distinguished by color (of course, the color is determined with reference to our own specifications). although the labels can be represented by different colors, in order to ensure the cleanliness of the interface, we use a lightweight way to deal with the labels.

project section

for the project, in addition to inheriting the design of the task on the display, we also designed the project as follows:

we think of a project as a container for tasks to better aggregate, manage, and give management feedback on the progress of the project, among other things. so the project does not have too many status points, open, close is enough~ ~

we still believe that projects are the most common way to collaborate on development within a company, so projects are created at the same level as tasks and are more lightweight. at the same time, in order to avoid the flood of large and small projects at the same level, we provide a first-level parent-child relationship, allowing users to more clearly manage the relationship between their own projects.



in most of the tools of project management, we have found the functionality of kanban, and its convenience and visibility are recognized by most users. this kind of view can give managers a good sense of the progress of the current project, and then coordinate resources according to the progress. here, in addition to providing some necessary screening, we have also combined the status of the task with the kanban board (of course, non-mandatory), dragging and dropping the task while changing the state of the task.

other

of course, most of the above design points are for ordinary users, for the design of some advanced functions, such as the definition and use of custom fields, such as advanced queries and the preservation of search conditions, such as the hiding and display of kanban boards, etc., we have hidden these advanced functions as necessary. for advanced users, these features will provide the convenience of customization to fulfill their product requirements.

product summary

therefore, the design of the project and the task will be summarized, and the characteristics that project management should have:

• lightweight: tasks and projects will be created in a very simple and quick way, and there will be no unattainable user threshold.
• decoupling: tasks are no longer forced to bind to projects, and the relationship between them is no longer an inclusion between superiors and subordinates, but becomes an association between peers.
• visible: we will see a list of projects or tasks with a clear hierarchy and a clear structure, and will realize the display of task status and control of project progress through the panel.
• strong extensibility: there is no traditional sense of grouping, no special customization function, through the label to achieve the classification of tasks, through the custom field to meet the needs of different users customized.
• through these features, users are given more playability, so that task management and subsequent development processes are not bound by force, so that all kinds of users can focus more on their work.

personal touch

flexible, is to allow users to form their own habits of use through the functions we provide, just like lego bricks, we provide a variety of materials, how to play, look at the user himself, what we need to ensure is that the user in the process of playing, will not be because of the limitations of the product and can not play, will not be because of the user experience of the product and give up this toy.
without losing the criterion, it is to meet the scene of most users, reduce the output of customized functions, functions as long as the output, you need to occupy a certain position in the product, and these custom functions, can not bring convenience to most users, on the contrary, if placed in the interface, even will cause confusing effects, which requires us to adhere to their own design guidelines, in the case of both can not be taken into account, follow the principle of two eight, products, not designed for everyone.