Whether Wireframes

It’s always good to question dogma, especially when you’re teaching it. One of the classes I teach is Interaction Design Fundamentals, and one of the tools we’ve traditionally taught is wireframing. But in the era of design systems and rapid production and prototyping, does it still make sense to do them (and to teach them to design students)?

Back in Ye Olden Times, designers always did wireframes as part of the UX process. There were three interconnected reasons for that.

1. To see if the functionality and site navigation worked — to check concept and flow
2. To show them to clients, stakeholders, and users for testing and buy-in on the Interaction Design and Information Architecture, not the UI. These people were usually confused as to why we were showing them this weird thing.
3. To make sure all the necessary pieces were there and worked before doing visual design, which was sometimes done by someone else

Much of this is still true, with some caveats. Wireframing is a tool, like other tools: useful in some situations, but not all. And I think that’s where the difference between then and now was. It can be ok to (gasp!) go straight to high-fidelity mocks. Better than ok, in that it sometimes makes perfect sense to do so.

If you’re working in an established design system and your concepts fit within that system, there’s very little reason to do wireframes now, at least medium- or high-fidelity ones. No one is going to be like Why is that blue? because presumably they are used to the design system. If they do focus on a detail, well, as Charles Eames said, the details are the design. You might be misusing a component.

I would only work in medium- or high-fidelity wireframes now only in certain conditions:

• It’s a new product or a disruptive/completely different set of features
• There is no established design system
• Stakeholders/clients really can’t see past the (known) design system. That is, there is low design maturity.
• Requirements are poorly defined or not defined at all. (One could argue this is every project.)

I would not do them just to check the We Did Wireframes box. The time it takes to do a set of medium- or high-fidelity wireframes often would be better spent making a prototype.

However.

Low-fidelity wireframes aka sketching are almost always valuable because I don’t care how amazing you are with Figma, you’re faster and looser on paper or (better yet) on a whiteboard with your team, product manager, or other designers. Design systems are amazing but they can constrain your concepts. When you have a pile of Legos, you tend to think in Legos. What if the best solution isn’t a Lego piece or is a piece you don’t already have? It’s harder to reframe a problem (one of design’s superpowers) when you’re staring at a set of tools to make a frame. Sketching and whiteboarding open up possibilities and are amazing tools for conversation, collaboration, and concepting. The stakes are so low making a mark on a whiteboard that all kinds of ideas can be more easily generated and considered. Even dumb, unworkable ideas that can lead to interesting places.

In the era of AI, the thinking behind the design — that is, one of the things that AI cannot easily replicate — is increasingly important and rare. Wireframes, especially low-fidelity sketched wireframes, are where thinking often happens. Don’t abdicate this step casually because you just might be giving up where your true value lies, and it ain’t in snapping Legos together.

Inspired by a Threads discussion