I don’t say it with a hint of sarcasm. I’ve put together a lot of furniture lately, and IKEA instructions are the only instructions that are consistently correct and unambiguous. In dozens of units, I’ve confirmed one case of an ambiguous step. But even in that case, I was able to read ahead and eliminate the ambiguity.
Compare this to almost every other piece of furniture I’ve put together. The drawings are often ambiguous, and even worse, the furniture can be constructed in multiple ways. This is rare with IKEA furniture. You may get to the end and find out you messed up, but things won’t really fit together. With my son’s crib, though, I had moulding pointing the wrong way with no structural effects. Unacceptable.
Assembling furniture from basic components is necessarily complicated. IKEA does a great job embracing this complexity by supplying extremely concise-yet-precise instructions and products where the construction process is considered in the design. My guess is that most people who have problems with IKEA construction jump in without understanding what they are doing. Fiberboard planks and screws are deceptively simple.
I think of this lesson often with the design of complex systems. Anything that deals with ACH (credits and debits in the US) is necessarily complex. You can only abstract to a certain level. Did you know that an ACH payment can transition from Succeeded to Failed? Attempting to “hide” the complexity of ACH, like we successfully hide the complexity of a file system, is a fool’s errand. Instead of making a payments API that’s simple to use, it’s be much better to make one that’s precisely defined, thoroughly tested, and well documented. There are still some problems that require a little bit of RTFM. It’s better to make this complexity front and center in a design like IKEA furniture, than to gloss over it and end up with client code that is built like second-rate DIY furniture.