To lump design thinking and its output as “waste” only goes to subvert our own hard-earned experiences as UX designers because it sends the message that you are only as good/useful as your final documentation. If it wasn’t useful, of course it is waste, but that just also means that you failed in your COMMUNICATION of the concept in the first place. The documentation only serves as a reminder; it is not the end-all. You must still communicate with your stakeholders and developers throughout. It’s not a throw-it-over-the-fence mentality. So let’s not confuse the PROCESS that led you to your insights (and you are documenting whether you are doing it on a napkin or in Word, for the record) as being “waste”. This is like saying your vacation photos are a waste. They are not (unless you had a crappy vacation); they are only a reminder of what happened. Their worth is defined by what you put into it.

It is also a fallacy of the inexperienced. Maybe this works for small organizations or start-ups, but work for a large company for a while (and through multiple versions of product) and you soon see that documentation is not the enemy.

Sorry for the rant, but ughhhh… I’m so tired of this repackaging old concepts as new and slapping a new label on it and everyone without understanding it cheering in the streets like mindless drones (you can be excused if you are new to the industry, but everyone else, no excuse).

That said, I’m all for this. It’s what we’ve been (or should have been) doing all along. So here’s to the old. Cheers!

The question inferred by @greg in his article is only whether you’re creating artefacts just to create artefacts. Knowledge theory tells us that only a small % of knowledge can be transferred by documentation. The rest of it is embedded in shared experiences. Given this, we should always be questioning how valuable a UX artefact is likely to be before we create it. It means that collaborative workshops with the team, end-users, and others, or collaboratively prototyping a solution until the team gets the gist of the intent of your designs, are likely to be far less wasteful than making a beautifully detailed prototype.

M

Even if it does cover all cases, then the development team will need some way to “discover” all of the cases and how they play out in the prototype. Without some documentation that explicitly ties the prototype to the user stories, it seems like we’re leaving a lot of room for error and rework — especially if the development team is offshore.

That said, you’re right that the issue is to “make it understandable for the team to build” and I equally resist the notion of giant spec documents, which we know that no one reads, yet they are required to sign off on them. There is a middle ground that applies in the majority of situations.