Product design and specification for my own resource management app


In my eight years as a producer in digital agencies, one of the things I always found unnecessarily frustrating was the way project management and resource management worked together. In the many agencies I’ve worked at, I’ve never encountered a system where there wasn’t a lot of duplicated data entry between various pieces of management software. I mulled over the problem during my time as an executive producer in a mid-sized agency, and after I left my post, I took some time off to design my own ideal system.

My role

  • Came up with the idea
  • Conducted user research
  • Used user-centred processes to develop design
  • Created designs and specifications for MVP build

Design process and key challenges

I didn’t think this app would ever go to build – it was just a design itch I had to scratch. The beauty of that attitude is that you’re not thinking about budget constraints from day one.

Even though it was a personal project, I wanted the outcome to be potentially useful so I decided to follow a user-centred design process. I identified three user roles that this software serves – the business manager who oversees the resources for the whole company, the project manager who is responsible for the budgeting and scheduling for individual projects, and the team member who does the actual project work. Having been in each of these roles over my last ten years in the digital industry, I put the hats on one by one and listed what I would want from a resource management system in each of these roles.

I’d kept an eye on resource management products over the years (I reckon during my time as a producer, at least once a year I would’ve looked for new software out of frustration), but I thought I’d do some research to make sure nothing new had come up that did all the things I’d listed already.

Mmm, no.

But before I started design in earnest, I wanted to check that I wasn’t alone in my frustration with the existing products. So I decided to contact a few agencies that I had connections with, and conduct some user research.

In each interview, after establishing the different roles in the company (and how they mapped to my list roles) I asked about the amount of time they spent on resourcing/planning each week (to ascertain whether resource planning is a significant task), and what some of the most frustrating and rewarding parts of their jobs were (to try to gauge where resource planning sits as a priority, as well as surfacing any key pain points).

A large part of each interview was also spent stepping through hypothetical scenarios: a client has signed off a new job – can you describe all the planning-related activities that happened to get to this point, and what happens from here? This helped me confirm my model of how planning works in an agency.

Lastly, I threw in some questions about whether they had looked for alternatives to the current software they were using in the past year, both to gauge the level of frustration with the current system, and the willingness to switch. One office manager said, “No… but it’s only because we’ve given up – we’ve already tried so many over the last four years.”

From here, I happily started my design work knowing that I wasn’t crazy. Firstly, I outlined some key principles that I thought good resource planning product should follow, to help me assess whether a design was good or not. Secondly, I listed about ten of the most common uses cases for the system, and mapped the user needs to these to help prioritise requirements. From here, I started sketching out wireframes that satisfied both the general principles and the specific user needs.

It was satisfying to see that there was a potential solution to the resource planning problem that had bugged me for so many years.

*    *    *

Some months later, I came across an opportunity to have an MVP of my app built. I seized it. But because I had started designing with no budget in mind, I had to redesign the product to fit the scope. I only had 20 days of development time to work with, so I had to prioritise pretty hard.

I asked myself – what’s the aim of the MVP? To test the core of the system, to show that the choices I’ve made in how to display and interact with resourcing-related data makes it more efficient to use than other resource management systems.

To build all the parts necessary for this to be tested, there would not be enough time at this stage to build the infrastructure to make this product publicly releasable. But as long as it’s possible to deploy the product in at least one agency, I was sure I would be able to learn enough to make it worthwhile. With this in mind, I redrew my designs and wrote up specifications (with an optimistic list of “nice to have”s in case we have leftover time) for build.

The MVP for Projector will be trialed at an agency in the coming months. Next steps of development will be determined following test results.

If you’d like more details about this project or any others in my folio, please contact me.