Building a Scheduling Tool

Building a scheduling tool


My role

  • Interviews and contextual research

  • Participatory design

  • Requirements analysis

  • Sketching and wireframing

  • Testing prototypes


Part of Forecast's objectives were to integrate Task Management with Project and Resource Scheduling so that projects can be planned, work defined and resources scheduled, in a seamless manner.

I led the design and analysis of the Scheduling feature, alongside the CEO and the CTO. Through collaborative workshops, I proposed to stay as lean as possible, and build the feature by formulating and testing hypotheses.


The Problem

After performing user interviews, it became apparent that a great pain for many Project Managers is the inability to find a tool that provides an integrated experience for planning work and managing their resources' calendars, many even resorting to create their own custom spreadsheets. The team had already worked in a scheduling feature for an earlier iteration of the product, but it was isolated from the work planning part of the app, so it didn't solve the users' most pressing concerns

Research: Interviews


Initial interviews helped us establish what were the recurrent themes in the lives of Project and Resource Managers.

"We need to ensure that for every project that comes in we have a team ready to start within two weeks of signature date."

"It’s difficult to manage multiple projects across multiple teams. Not getting updates on time, not hearing from a PM if a project is going off schedule makes my life very hard!"

"Sometimes we only get a deal if so and so can be placed in the project!"


1 - Articulating the problem: Co-design

After sharing the results of the research with the team, it was important to put everybody's assumptions on the table. So we spent a morning laying down assumptions. They were then aggregated into themes using affinity mapping, and prioritised. These assumptions then became our first hypotheses to build and test.


2 - Defining Hypotheses

Picking up the hypothesis in priority order (also taking into account what the Tech Lead had to build first), I created high level JTBDs

“When I schedule a project, I want all my team members’ calendars in the same place, so that I can create tentative schedules for projects that we might win.”

We played "How Might We" on these JBTD and everyone got to sketch proposed solutions to the challenges.


3 - Implementing solutions: Prototyping

Over a month, I collaborated closely with the Tech Lead on building the feature. We intended to work Lean, so I produced few initial hi-fi prototypes in Sketch to guide his vision, and then, the rest were paper sketches to illustrate and guide our conversations.

4 - Testing: A working prototype

The Tech Lead quickly put together a working prototype that I put in front of users. It addressed the overall concern of bridging the gap between the work planning and people scheduling, without getting into the finer details yet.


Video still of one of the tests

5 - Findings: QuickBooking

Inspiration struck when I was buying a flight home

Inspiration struck when I was buying a flight home

During the user testing sessions, it quickly surfaced that the resource managers operated at two different levels: when they had to staff a new project and when they had to quickly replace team members at existing projects. The calendar-spreadsheet with pointers to projects approach that most RM tools offer satisfied the first scenario, but made the second one somewhat time-intensive. I thought that, having to staff a particular person/role into an existing project, with time and price constraints, was a bit like booking a flight.


So, I took inspiration from the airline booking systems to create the Quick Booking functionality, where the PM enters a project name and set of skills and get a list of available team members for that period. This is now one of the major selling points of the whole application.