Sep 26, 2023
During the design phase of a website redesign project, it’s not uncommon that someone (usually the customer) has a budget in mind before the website design work has started.
Subsequently, as the information architect, designer, and customer goes through the design process, they often end up with a design that can’t be achieved within the expected budget.
This results in a sticky situation between design and development which can derail the entire initiative, especially if both sides dig in and resist being flexible. The design team has put in a lot of effort coming up with great ideas and the development team knows that all those bells and whistles require way more time than is available within the budget.
To reduce this conflict, Oshyn's team typically plays the role of "technical expert" during the design phase in order to provide feasibility feedback to the design team. We offer guidance based on the technology requirements and effort as well as the constraints that the software, environment, or architecture might present.
For agile purists, the optimal solution for this situation is to avoid it entirely by not separating the design phase from the development phase. Instead, roll them together in an agile sprint model where you deliver a set of functionality periodically (usually every two weeks).
However, if you take the EXACT SAME features and design and build them using an agile approach rather than a waterfall approach (i.e. a stand-alone design phase followed by a stand-alone development phase), those features will end up taking longer and cost more. The reason the agile method is preferable is that you rarely understand everything you need before starting the process. The features you thought were required don’t actually end up being needed, or they change dramatically.
But while agile provides a better approach, it doesn’t usually get applied in its pure form in the real world. Customers don’t typically buy into the uncertainty of what they’ll end up with without at least some semblance of a design phase.
So in this situation, it’s indispensable for everyone involved to have a full understanding of – and to agree on – the strategy being used in the design phase. These are the most common strategies that we have seen:
| Description | Downside | Upside | |
|---|---|---|---|
Are we there yet? |
As each feature is designed, you ask, “is this feature within the budget?”. The answer to that question is probably yes…until it isn’t. As the dev team answers the question, they are trying to guess the impact of all the features yet to be designed. |
You really can't tell when you are looking at the handful of first features whether all the subsequent features will fit into the budget. This typically results in saying "yes" to the first half of things that get added to scope and saying "no" to some percentage of the second half. If you attempt to "fill your scope bucket" to the very top, the likelihood that you will end up needing more budget to complete everything is high. |
Design is mostly unencumbered by budget considerations for the first 75% of the project. It can be useful when it is necessary to establish credibility with the customer up front by impressing them with great designs. |
To the moon! |
Design everything without concern for budget constraints. Once the design is complete, you figure out what to cut to stay within budget. This will typically mean re-working the designs so they make sense with the reduced featureset. |
This strategy requires the design to be reworked to fit within the budget. This effort results in spending more than necessary on the design phase which cuts into the budget for building actual functionality. |
You’re likely to end up with a more complete design up front (albeit at a cost) that may make adding the missing features easier down the line. It’s easier for everyone to envision the final product when everything is seen at once together. It is much easier to make scope and priority decisions once you know the total universe of pages and components. |
First build a bike, then build a car |
MVP strategy #1: design a minimum viable product (MVP) that is not intended to maximize your budget, but rather to get the minimum scope built quickly and available to users so feedback from users can give you better information on what the subsequent features should be. |
Constant reminders of the strategy to create the MINIMAL product are required and sticking to this is difficult. Customers don't want to disappoint their own users – or their management – by deploying something that looks 'half-baked or not fully developed. It is also challenging if the site is replacing an existing one that contains a larger, fuller feature set. |
Speed: this is the fastest option to market and for systems where the final product varies significantly from the initial concept, this can be the most cost-effective option. However, it is impossible to know the delta between final and initial without the benefit of hindsight. |
Build a 2 BR house, then do additions if you have enough budget |
MVP strategy #2: design an MVP that is intended to use 50-60% of your available budget. Once those features are built, design and add in additional features to use the remaining budget. |
Constant reminders of the strategy to create the MINIMAL product are required and sticking to this is difficult. |
In our experience, this strategy tends to be the most successful. It provides a good balance between using the budget efficiently and managing expectations. The conversation gets easier because you are essentially just pushing the lower priority features to a secondary list – and some percentage of those features will be attainable within the budget. |
The odds of a successful project increase exponentially when all parties understand and agree on one of these strategies (including the downsides) before the design phase kicks off. If everyone is not on the same page with the plan for scope management, the result is a difficult situation that typically means lost budget, lost time, and a reduced perception of quality of service.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.