Chances are you've come in contact with a piece of flat-pack furniture from Ikea. You may even have put a shelf or desk together with the help of an allen wrench and a single-sheet instruction manual. Ikea has successfully innovated in pricing, logistics, packaging, and store layout to become a global phenomenon.

But the lesson we, the UX community, can learn from Ikea isn't directly related to their low prices, or making customers put products together themselves. Rather, the valuable lesson we can take from the self-assembly giant comes from an earlier point in a product's lifecycle: the design stage.

When it comes to design, Ikea is a price-first company. Sure, they pride themselves of their Scandinavian design and ingenuity, but above all else they want their products to be as affordable as possible. As a result, the target price for a product defines and constrains the product design, rather than the other way around. Instead of specifying a product and then determining how much it will cost, Ikea decides how much a product should cost and then designs it to fit within the cost constraint. In an interview with CNET, Ikea product developer June Deboehmler said, "When we decide about a product, we always start with the price... Then, what is the consumer need?"

To some this may seem like a counter-intuitive approach. But in actuality, creativity loves constraints. It may seem that a cost constraint would be burdensome to designers but in fact it helps focus and guide their work. Even if cost isn’t the leading constraint (as it is with Ikea), it’s always a critical constraint that should be factored into design.

But in the world of software and UX design, you seldom see projects where cost is treated as a primary, initial constraint. Instead, cost is treated as something that’s derived from scope. Foundational problems with scope, budgets, and constraints are a setup for failed projects and poor UX. But how can we all learn from Ikea in a way that makes sense to industry? We have defined four lessons that will guarantee smoother projects before they even start.

1. Cost is a primary constraint

After they’ve outlined a product’s scope, most companies already have a strong sense of what they think the product should cost, or at the very least how much they can afford. But, in the majority of cases, rather than communicating both the scope and cost expectations to their vendor or internal development team, they withhold the cost information. This forces the development team to go through a complicated, error-prone process of trying to extrapolate a cost estimate from the scope. This is followed by a back-and-forth of discussion until the estimate comes into alignment with the original cost expectation. The cost expectation (or limit) was known all along but everyone has to participate in a ritual dance before it’s disclosed.

In most other settings, this practice would be considered dysfunctional, and an example of how poor trust and communication wastes time and money. But, oddly, it’s standard practice in software and Web development. If the cost expectation is fixed and present from the beginning—in other words, it is a primary constraint—why not simply let the development team know about it? Constraints give the team better understanding of what will be possible, reduces errors in their projections, and gets them working sooner.

Companies are generally wary of sharing their budget numbers upfront for fear of having the development team take advantage of their trust. Their concern is that the development team will charge the full amount in the budget even though the scope of the project should actually cost something less. But, in actual practice, this can't happen because the scope is never smaller than the budget. For innovative, UX-focused product and website development efforts, the project's requirements will always grow as large as the budget will allow—again, cost is the project's primary constraint. The entire course of a project always entails an ongoing negotiation between the stakeholders and the development team about how much work can reasonably be accomplished, and how many requirements can reasonably be fulfilled, before the budget runs out. This is true whether or not the budget is initially disclosed, and whether the project is charged fixed-bid or hourly, because of the weaknesses of upfront planning and the ambiguity inherent to scoping documentation. If the development team is aware of the real cost constraint from the outset, their projections about what they can accomplish will be much more accurate—and, often, much more ambitious—than if they were left to make guarded guesses about what the cost constraint might be.

2. Goals are more important than specs

Initial scope and specifications documents are a form of guesswork product design often done by whoever owns the project, rather than by actual product designers. Such documentation is meant to serve as the definitive blueprint for the project, but have you ever (seriously, ever in your life) seen an early scoping document that turned out to be anywhere close to accurate when the project was done? This isn't because the people drafting these documents are incompetent; it's just that product design is something best left to, well, product designers.

And even for the most experienced product design professionals, the beginning planning stages of a project are the time when the least is known about what the project will actually entail. This is the worst time to have to lay out definitive specifications for the product. Complex, UX-focused software projects just don't lend themselves to extensive upfront planning and specifications efforts—too much of the project's actual needs won't be discovered until design and development commence. So how, then, can project stakeholders ensure their vision and requirements for the product are met? By expressing their needs very clearly in terms of the business' goals for the product. Goals are another form of constraint.

When business stakeholders attempt to build detailed specifications up front, they are attempting to extrapolate specific requirements from their general goals. If Ikea took this approach in their product design, businesspeople would spend a week in a conference room trying to describe in words in long, numbered lists, exactly what a chair or table should look like and what features it should have. This would obviously be silly; product requirements (for both furniture and software) are best expressed through design materials and prototypes, not through lengthy specs built by business stakeholders. The stakeholders' role is to clearly express the constraining goals for the product and hand those off to product designers who can begin to design the specifics.

Business stakeholders need to ask themselves, what does it mean for a project to succeed? Is it successful if it fulfills on guesswork requirements built by the wrong people at the wrong time in the project, or is it successful if it meets the business' goals and stays within its budget constraints? Business stakeholders have the clearest understanding of what the company needs the product to accomplish, but the team that will build the product will advise them best on how to meet the goals. Setting clear, high-level goal and sharing the project's budgetary constraint gives a reliable development team the ability to plan accurately, reduce risk, and squeeze the most bang out of a buck.

3. Honesty and trust are mandatory

As we mentioned, many companies refuse to share their budget out of worry that they'll be taken advantage of. If you tell a car salesman that you're willing to spend $30K, he'll try to sell you a $20K car for $30K. If, on the other hand, you keep your budget constraint to yourself, you may drive out with a $20K car and $10K in savings in your pocket. But when shopping for cars, you're dealing with products that have already been built, and you're just picking the one that suits you. But when you're building software or a website, you're building something entirely new with great uncertainty about, and flexibility in, the details of the implementation. The scope of the product is a direct function of its available budget.

It's critical that you be able to work honestly and openly with your development team or vendor. You'll collaboratively manage a project to ensure it fulfills its goals, stays within its cost constraint, and delivers the best value possible. If you don't think you can trust your development team or vendor enough to share your budget with them, then you're working with the wrong team. That lack of trust will undermine the success of the project by crippling your ability to collaborate effectively. You and the development team need to be partners in building a great product, not adversaries who are managing each other as risks. In an adversarial or arms-length relationship, the development team will always be trying to do the least amount of work for the most money. The business stakeholders, for their part, will be trying to take advantage of the ambiguities in the initial scoping documents to get the development team or vendor to do more work for the same price. Both parties will be focused on protecting their interests, rather than working as true partners toward the joint goal of a good outcome for the project.

This partnership with the design team is what Ikea achieves by staying goal- and cost-focused. While it's uncertain what the product will look like, it's never ambiguous what the definition of success is for that product. This business stakeholders and design team are working toward the same goals without needing to keep information from each other.

4. Abandon guesswork for concrete understandings

This guessing game of "what's my budget" is very much a waste of time. Some business stakeholders think they couldn't possibly guess what a project should cost, but in thinking this they're approaching the problem backwards. When it comes to important, high-complexity, UX focused software and website development efforts, the question isn't "what should this cost," but instead "what can this cost?" One needs to have a number in mind—a limit that will constrain the scope and ambitiousness of the project. Giving development teams a pile of guesswork specifications documentation will just get you a pile of guesswork price estimates. What you end up with are unreliable specifications and unreliable cost estimates. By providing development teams with a specific understanding of your cost constraints, you make it much easier for those teams to make accurate projections about what will be possible. This also lets development teams show you other projects from their portfolios that had similar budgets. This, in turn, allows everyone to work from a solid understanding of the cost constraint with a concrete example of achievable scope. Development teams can help stakeholders by providing detailed information about the budgets and challenges encountered in their portfolio projects.

We believe that these four lessons are important to succeed in the high-complexity domain UX-focused software and Web development. Making cost a primary constraint and sharing budgets with development teams may require a shift in thinking by all parties involved. Business stakeholders need to trust the teams they work with, and therefore choose to work with teams that are trustworthy. Development teams need to earn that trust by clearly communicating what they will do with the information and by being honest and transparent about their projections and about project progress once it's underway. And if there's any doubt on either side, you can always say, "Hey, it works for Ikea".


Hi! Really good article! I am just a ordinary visitor to your site (very much like addict :P) on your website even though I had a issue. I'm just not likely pretty sure whether its the right site to question, but you have no spam comments. I receive comments day by day. Can you assist me? :

Interesting timing, because we've just chucked out a load of cheap Ikea bedroom furniture that my wife and I bought when we first got together. We replaced it with some big, heavy real wood furniture that was very expensive.

Can't say I ever liked the Ikea stuff that much.

Some nice thoughts here but 3 of your 4 points (1, 3 & 4) seem to be primarily about sharing budget info. I think you could simplify... maybe it's really just about the benefits of sharing budget, or clarify and make the points more distinct.

We read about Ikea in a case in one of my classes. This was mentioned briefly and I remember the case talked about how Ingvar said that if a solution/product was expensive, it wasn't a good solution.

I try to use this approach when dealing with clients and bidding for them.

What you are describing sounds a lot like an alliance based delivery model that is used a lot in infrastructure projects, especially around the trust and shared responsibility factors.

In addition to this great article, estimating is also much easier when one accounts for cognitive bias that people have like recency bias, anchoring and optimism bias. I have a pub trick example that you can find here:



What about everyday people being empowered to make something by following instructions?

We wrote about this recently, it’s very empowering that a person can pick up a IKEA instruction booklet, and by following a few steps they can get a good feeling about making their own furniture.

Well said, this framework is sound.
I internalize this way:

1. get the goals right
2. get the budget
3. confirm level of possible goal achievement
4. negotiate as necessary - in light of goals, not vague budgets or overly stated requirements.
5. do well on above = earned trust = more business with current client and or others through a fiscally sound portfolio of solutions

thanks for this

You're assuming that the budget in the client's mind is likely to be more than the cost for developing a solution with the minimum scope. In most cases I find the client seriously under-budgets, as they really have no clear idea of the costs involved, so then everything a fight to get enough to do the job properly.

Nice fresh thinking — but I see a problem.

For some industries, including IKEA's, cost is influenced by economies of scale. Economies of scale are based on how many units you sell, which could be based on the initial design. So you might design a chair that requires expensive an expensive tooling setup (producing a higher quality chair) but gamble on an selling so many units that it doesn't matter, or is actually cheaper when manufacturing zillions.

Other feedback on this article: It's very verbose.

I wish more of our clients would prescribe to this model. When putting together a project for a customer if we know their budget, we can create the best approach for the dollars they have available. I think the "car salesman" mentality impacts purchasing in our professional lives that is not really appropriate - at least when working with entities that have established relationships.