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”.
