** After a year of constantly learning from our customers we decided to change how tasks look in order emphasize what we learned are the most important features other than the actual text of the task item: who is responsible, when it’s due and what’s the current state.
Your feedback changes Blimp
Blimp launched almost a year ago and during that time we’ve talked to hundreds of creative teams around the world. Those talks have given us a lot of new knowledge on how people work, how they manage tasks, what works and what doesn’t. Today we want to talk about three of the lesson we’ve learned from our customers and how we’re going to apply these lessons into Blimp 2.
Tasks need to be assigned to a user or they will not be completed
This now seems super obvious. If you create a task and don’t assign a person to be responsible for it, that task will just sit there for ever. As you might know we’re all super busy all the time and we don’t always have time to look at things we don’t necessarily have to do. In these kind of teams, assigning every task to a person at the moment of creation really helps move things along.
This is not the only approach we’ve seen. In our own team some tasks just don’t get assigned at the moment of creation. What happens is that periodically we all go hunting for things to do and assign ourselves to tasks. This really helps balance the team because every member knows how much more work he/she can do at any given moment. No management needed.
The approach we are proposing for Blimp 2 is that if a task is not assigned to a user, that task should look and feel incomplete. We think that if a task without an assigned user looks incomplete, “people’s eyes will start to hurt” (not a real thing but you know what I mean) and push them to assign it to themselves or another user achieving the desired effect.
This is a sketch of the current design with the assigned user on the right.
Here’s the new design with the assigned user area on the far left replacing the checkbox (which we don’t longer need). If the task hasn’t been assigned, it will show up with an empty circle where the user should be. This will achieve the incomplete look we are trying to get.
Finally, the task with a user assigned.
**Tasks need to have a due date or they will not be completed
** Again, this was not obvious to our team. During the past year we’ve been working on Blimp which is a software product which involves a development process that never ends. So, due dates where not a priority for us. We just keep working as fast as possible and one task gets completed after the other.
Our customers have told us that when they have a task without a due date, that task tends to stay on the project and never see the day of light until the project’s due date is near. If a task has no due date, there’s no way of “failing” at delivering that task, so they tend to get postponed to after the tasks that actually have a due date.
In the current version, the due date appears if the tasks has it assigned. If the tasks doesn’t have a due date it looks perfectly fine. You might even argue that it looks better without a due date which we think might encourage the negative behavior. Also, in order to set a due date, users have to double click on the task to show the detail pane and then set the date, which now seems like too much work for something so important.
On the next version, tasks that don’t have a due date should look incomplete. We must have a visible space for due dates and that space should look empty when there’s no date assigned. Assigning a due date must happen right from the task list without the need to open a detail pane.
Here’s a sketch of a tasks with the current design. Notice the due date in red. When there’s no due date that space will be empty without any hint of a possible due date.
This is the new design, which has a space clearly marked for due dates (in red). If the task has no due date the space will still be there and empty, producing and incomplete feeling on the task.
Finally this is the new design with a due date set.
**Task state should be set manually
** When we began working on Blimp we knew that task state was critical to communicating project progress. We thought that if we automated the process of setting task state that would help project progress communication. Turns out that trying to automate that was the wrong approach.
In our current version we try to implement a process which helps move projects forward without having to be an expert in project management. The current implementation of that process is very weak since we’ve been constantly removing automation in order to accommodate for our users needs.
From these mistakes we learned two very valuable lessons. First, don’t try to force the user to use the tool as you intended and second, the user knows the status of a task better than any algorithm.
In order to apply these lessons we are making a few changes on how task state is expressed and managed. First we will have four new task states: not started, in progress, on hold and completed. We will allow users to set the state of each task manually and change it as they please. No more locking of tasks in particular states. This should solve most issues with the current implementation.
This change has a very important impact on how tasks should look. We think that we can’t show tasks with the familiar checkbox on the left side if we have more states than done and not done. So, we decided that we needed a way of changing task states that allowed users to easily and quickly access any of the available states and that this should happen on the list view of tasks without the need of the details pane.
The decision was to remove the checkbox and move to a kind of drop down menu. We have been playing a lot with the idea of the drop down menu and we came up with a very cool interaction that will give users the same one-click experience when completing tasks.
We achieve this by opening the drop down when the mouse enters the area where we display the current state. When the drop down opens, the completed state will be preselected so the user only has to click once to set it. We need to do more testing but it’s looking pretty good. Here’s a sketch of what we are thinking.
** Here’s a sketch of the before and after.
What do you think?
We really need to hear what you have to say. Please let us know what you think of the change and how you think it will impact your workflow. Are we missing something? Have a better idea?