Design Estimations: How to Properly Estimate a UX & UI Design Project
A few years ago, when I was working for a software development company I wrote an article with some advice on how to estimate software projects. At the time, it was a burning issue in our development team.
We were getting project inquiries from potential clients and our developers were way off with their time + cost estimates. Can’t blame them, to be honest. Giving the accurate time to complete an entire project, even if the client provides the most detailed specification (which never happens) is extremely difficult.
Years later, when I moved on to work in design, I eventually bumped into the same situation — getting project inquiries and having to create design estimations that clients can use to make a decision or budget appropriately. I approached the task thinking it would be a piece of cake compared to software.
This may be partially true, but it’s definitely not the whole picture.
Adjusting your internal process
Let’s consider why design estimations are difficult to do. For the most part, it’s because of missing information. On the client’s side, they don’t know how long it takes to create designs and even if they do, they don’t know how much your design team can achieve within a given timeframe.
On your side (the agency), usually you don’t know the full picture of what your client wants to do and you have no way of knowing what additional features will turn up after you start designing and get a better sense of the scope.
So, the lack of information is a constant. You’ll always be faced with limited knowledge — no way around that. What you can do instead is to adjust your internal process so this lack of information is not such a huge issue.
As an example, at Melewi, we work in 2-week design sprints. In each sprint, we focus on a specific user flow (e.g. user onboarding, purchase flow, account creation, etc.). When a potential client comes to us, we have a detailed call to understand what they want to build, who they’re building it for, and how the users will be interacting with the product.
This helps us map the rough amount of user flows and their complexity. From there, we can determine the number of sprints we’ll need to design the product.
Through the years of creating design estimations and working with clients, we’ve also seen that often times plans change and once a product starts taking shape, clients also start to have a better idea of what they need. This is why we’ve found it easier to keep things flexible and charge clients per sprint, not for an X-month long project.
That way, we can start with a design scope that takes 4 sprints and add more design sprints as we move along if there are a lot of new features that need to be designed.
Leave yourself some wiggle room
Bearing in mind how uncertain design estimations can be, you should always leave some room for revision at a later stage, when you expect to have more information. Be sure to prepare your client that the estimate you’re giving them now might be subject to change, based on what you discover in the future.
We do this in two steps. First, after we have an initial call with an interested client, we come up with a rough estimate so they can get a feeling of how much time the project will take and what it might cost. Our design process always involves a series of kickoff workshops, before we actually start designing.
Those workshops are intended to provide us with a ton of additional background information, about the client’s business idea, value proposition, competitive landscape, and user persona. This knowledge will both help our designers when creating the UX & UI, and it will also help us get a better understanding of the scope and any industry-specific features that might take longer to design.
Naturally, after we’re done with the design workshops we have a much better understanding of the work we need to do. This is the point where we might re-evaluate the estimate we initially provided if the scope is much larger.
What about ad-hoc design?
So far, my main point was that your internal process can mitigate some of the issues that come with design estimations. However, that internal process is not universal. If you’re doing full UX & UI design projects from start to finish and occasional ad-hoc design work, the same process won’t work for both cases. If a client comes to you and needs a design for a 10-page brochure for an upcoming conference, they’ll need to know some numbers.
The good news is you’ll get better at estimating those types of requests with every next project you do. You’ll get a feeling of how much time it takes to come up with the structure, fill it with design elements, add colors, shapes, etc. You’ll also start automatically provisioning some time for back-and-forth communication (which shouldn’t be underestimated).
Still, if this is not a usual project inquiry for you, consider the lack of knowledge you have now and what information you’ll need to be able to come up with a design estimation.
First, you’ll need the see the content of the brochure (or whatever you need to design). This will help you understand how much text/images there should be in it and what’s the available space you’ll be working with.
Second, you’ll need to get some context. What kind of conference is this intended for? Who will be reading this brochure? This will give you some directions on the actual design you need to create — does it have to be something wild and eye-catching, or something more clean and subtle.
Third, ask them about the deadline. When do they ideally want to have it ready? The estimate doesn’t necessarily have to be X number of hours times your rate per hour. If the client wants to have it ASAP, that’s additional after-work hours and additional stress for you. This has to be compensated accordingly.
Design estimations are hard to do accurately. Whether you need to estimate a UX & UI design project or an ad-hoc design task, 9 times out of 10 you’ll be faced with a lot of uncertainty. Instead of trying to nail the time and cost down to every small detail, create an environment where changing the scope won’t matter that much.
Keep things flexible and communicate clearly that estimating design projects requires context and background information. Don’t be afraid to ask your clients to do some homework.
Further reading on estimating UX projects — https://uxmastery.com/how-to-estimate-a-ux-project
Originally published on the Melewi blog.