Resource Planning: Lessons Learned in Product Design

Resource Planning


The Goal

  • Allow users to allocate team time to multiple projects at once without overburdening the team with tasks.

The Challenge

  • What made the resource planning feature so tricky was figuring out a plan of attack. We went through multiple design iterations and reviewed our customer's current solutions.
  • First, we had to pick between a user experience around assigning tasks to users or assigning users to tasks. As the core of Mavenlink is collaborating around projects and we had the paradigm of the task tracker, it made the most sense to us that people would be constructing projects first and then figuring out team availability.


  • When were designing a new feature, we take some time to define who we think the target users are and what their use case is. Resource planning seemed to have a practically unending number of discrete use cases. An executive needs to know that her team is fully utilized, a project manager needs to know that the job can be done on time, a team member needs to know what they're working on today, and so on.

Our Solution

  • For the first phase of resource planning, we decided to build an assignment view of a task tracker in a project. Tackling resource planning through a task tracker interface gave us the opportunity to lay the groundwork for what we're planning to do to the workspace task tracker (live edit, easy to manipulate tasks, build on learnings from our global task tracker), and we can give the user a focused view into a single project while still providing valuable global information about their team members' task loads.
  • As an immediate follow-up, we prioritized the utilization report, which gives company executives a people-oriented view of global allocation. Premier users can see their team's utilization by going to the report section on Mavenlink.
  • We justified making the report lower priority than the resource planning feature because of internal resource limitations (we're hiring! ), and because we thought that the report would be much more interesting to executives once there was data to display-- so team members first needed some time to start using the new tool.

Lessons Learned

  • At Mavenlink, our development team follows the Extreme Programming philosophy where engineers will pair program (meaning 2 people at 1 computer) to write code collaboratively. It was immensely valuable to apply this same collaborative philosophy to UX design. Our Creative Director, our CTO, and I spent significant time together working through at least 6 iterations of the user experience. Without each other, I'm sure we would have missed vital use cases.
  • You have to start somewhere. Because there was such a broad set of targeted users for this feature, it was challenging to wireframe the feature piece by piece, knowing that whichever thread you started with, it wouldn't work for all users. But, you have to start somewhere.
  • Perfecting, not perfection. One of my favorite things about working on a service hosted in "the cloud" is that you can continuously improve your product over time. We were able to ship our first iteration of resource planning, share it via private link with some customers, get feedback, and quickly iterate before officially shipping the feature. After we publicly shipped, I noticed that I kept trying to open the allocation bar by clicking in the daily cell. We were able to incorporate this interaction and a few other improvements that first day. Because Mavenlink is web-based, our customers benefit from our improvements immediately-- no update, patch, or new CD required!