Bite size design operations | Effort estimation model

Using probability, the basic building block of ML, in design operations

Photo by Markus Winkler on Unsplash

TL;DR

• The method is built on the foundation of the design sizing model I introduced in my previous note. Read more about it here to better understand this method.
• You can now estimate the effort it takes to deliver a design work by looking at the probability distribution of the design size score, ‘d-score’.
• The method takes the complexity score, ‘cp-score’, (more on this later) out of the d-score, and let you decide on the effort requires to deliver the design project.
• You can also add historical data points to your data set to refine and increase the accuracy of your estimations.

One of the many challenges of the design teams is estimating the effort of the design work. The effort estimation model takes this challenge, gets into the game-on mood and addresses those challenges by estimating the probability of the effort while introducing the cp-score. It helps take the guesswork out of our estimation process using the probability distribution.

1. Designers would be able to make more accurate estimations if they struggle to provide a timeline of their work.
2. Cross-functional teams (XFN) would have more visibility into the design timelines when estimating the product launch dates.

d-score is the cognitive load of a design project on creative teams and it consists of four levers: Effort, Priority, Goal Type and XFN Collaboration. In our effort estimation model, we group Priority, Goal Type and XFN Collaboration under one bucket called Complexity. Focusing on Complexity and Effort allows us to see the relationship between each other through variations and historical data. The image below explains the weighted scoring model and the relationship between the d-score and the cp-score.

The breakdown of the d-score

cp-score equation is similar to how the d-score is calculated. It’s based on the weighted scoring model and it blends the priority, goal type and xfn collaboration into one score, cp-score. However, there’s a slight difference: Those 3 levers now have different weights. For instance, the priority represents 10% of the d-score. However, we want to understand its impact on the 65% so when we move onto the cp-score, it represents 15% of the cp-score:

cp-score

Looking at different variations and historical data, you’ll get a table similar to the one below that shows the probability distribution among d-score, cp-score and the effort:

Probability distribution

For example, if you read the table according to the steps outlined, you’ll see a project with a cp-score of 4 will likely to take 8 weeks to deliver with 26.49% probability.

This is just a small step to introudce ML to the design operations. The model needs to be trained with historical data. Having said that here’s a few scenarios to give you an idea around how this model might be helpful:

Scenario 1: the designer taking on the work is not sure about how long the work would take or doesn’t feel comfortable providing an estimation. They go to the tool, select the fields that help them calculate the cp-score and make a decision based on the probability.

Scenario 2: Product team would like to make a high-level estimation on the product feature launch date. They go to the tool, calculate the cp-score and understand the likelihood of the design timeline. They then get in touch with the design team or the designer taking on the work, and confirm the timeline because no matter how accurate the model predicts, the final decision is always made by the designer taking on the work.

Hope you enjoyed this note. If you have questions or ideas to improve this model for your team, get in touch!