Throw Your Wireframes Away
A plea to focus on the thinking and not the deliverable
Lots of UX designers are doing it wrong. They make a point to focus on solving “real problems” for “real users”, but forget to apply the same type of thinking to the deliverables they create.
The product you’re designing is for someone else — but so are your wireframes.
They exist to make ideas visible, to facilitate discussion, and to drive a common understanding of what the larger team is trying to build.
They need to be clear, but they should almost never be pretty.
Once you’ve created wireframes at a level of fidelity sufficient to clearly communicate your team’s ideas, your job is done. Present, discuss, and iterate. If your goal is to build a product, further refining and “cleaning up” wireframes that already communicate what’s necessary is wasted time and effort.
Of course, as a designer, it can be satisfying to put some polish on the shiny new design you’ve just created, but in the end, it blurs the line between UX and UI design — which are very different skillsets and distinct, separate parts of the overall design process.
It’s worth noting that, in practice, different products and processes require design artifacts of different levels of fidelity. The level of detail you’ll need to include in a sketch to communicate an idea to the person you’re sitting next to is much lower than with someone you’re collaborating with remotely. The less you’re able to do the talking, the more your wireframes will have to communicate without you — and the more detail and organization they’ll need to be effective.
At the end of the day, wireframes go in the trash.
The nature of wireframes as a design artifact is that they’re always in service to something else….and it can be easy to get caught up in making your ideas pretty rather than brilliant.
As a UX designer it’s important to remember, the process is your deliverable, not the temporary documentation that enables it.