Wireframes aren’t obsolete. They aren’t too concrete. And they definitely aren’t a waste of time.
Wireframes are skeletons for a would-be design, for a website or a mobile app, and we all know this. There are different types of wireframing techniques and ways of using these techniques. We won’t talk about what wireframes are, or how to use them — but ways to use wireframes to your advantage. And that is, in essence, the real sweet spot you must find for your process.
The “what” and the “why”
What are wireframes and why are we talking about them?
During the initial stages of the process, always have a goal for the wireframing exercise. Wireframes are supposed to be a bridge between the known and the unknown and will enable you to move forward with confidence.
The very reason for processes like breadboarding and wireframing is for the designer to figure out and hypothesize the knowns, the unknowns, and the unknown unknowns. These would then be validated by user research, or further in the process during usability testing.
The designer must also trust that the wireframe will solve something for them or help them decide— and this is usually tied to the information architecture or the hierarchy of how the information needs to be structured.
I’ve sketched on pen and paper, and created wireframes using online tools like JustinMind, but have always wondered “How is this helping me?”. It’s only recently that I found a way to utilize the potential of the wireframing process. And here’s the “how”.
The “how”
How to use wireframes to your advantage?
Uhm, good question. There’s not one, but a bunch of things that lead to the epiphany. And to begin we must talk about ownership.
With great power comes great responsibility. And with great responsibility comes great ownership.
Designers must be able to enjoy the ownership that comes with the job. Only then will there be a sense of belonging with the design that comes out of the designer.
“My work is a representation of me, it speaks for me and I for it. After all, I like what I do. And if there’s something wrong, I will learn from it, for the next time.”
Being an IC gives me the freedom to develop my craft. It teaches me to decide better with confidence, and trains me to communicate the decisions to whosoever is curious. And here’s how wireframes help me in all this.
Freedom
The design process is subjective. Which is in itself a subjective way to put it. And ever since I knew the difference, I’ve treated and portrayed design as a science. And with logic, comes a process that lets you see the truth.
I’ve never been a huge fan of the empathize, ideate, test, iterate design process, or the “design thinking” ideology that everybody seems to be showcasing, if not following. And I may very well be using parts of both, yes, but I really can’t tell. I use (and discard) methods that float my boat while keeping me on the right track. And freedom can’t get any better than that.
Design philosophies apart — Where in the logical process does Wireframing play a role?
Early, yes. But the freedom of how early and how much must be entirely up to the owner of the process — the designer.
Are your wireframes for the stakeholders or the users? Or are they only for you, the designer, to help you make decisions? Are they helping you validate? Or are they up for validation?
I, for instance, use wireframing for myself and use them alongside the high-fidelity designs, to find validation and harmony in the process. I rely heavily on my design document and it’s almost always the chemistry between the wireframes and the designs, that pave the way for me.
Here’s an example of the dashboard screen for an investment app. The structure is being formed with the help of a barebone information architecture and hierarchy, a wireframe connecting to the IA, and the final hi-fidelity design that birthed.
The pieces of information were be obtained as a result of a card sorting exercise with users. And the design would be prototyped and tested with a bunch of users well before it’s prepared to be built.
Decision
In the design process, it is difficult to define when decisions must be made. What contributed to these decisions is also a loosely-constructed idea to everybody else involved in the process. And sometimes, lost in decisions are the designers themselves.
Is it the designer’s hypothesis? Is it based on qualitative user research or quantitative analytics? Are we basing it on historical data or a future prognosis? Is it a careful mixture of all this? When do we consider the constraints in implementation?
The designer must know, understand, and decide before acting on any of these questions. And documenting all this (and more) stops the questions from echoing, from various departments or stakeholders.
And it’s the processes like wireframing and breadboarding, combined with techniques like user interviews and surveys, that assist the designer in deciding.
For an app designer like myself, wireframing helps in determining what needs to be displayed on a screen. It’s even better when there are multiple states and stages to that one screen.
And the user journey guides and supports the decisions along the way, like a guardian angel.
With a good amount of confidence in the wireframes, the designer can now proceed to present the wireframes to the stakeholders or create high-fidelity designs from there-on.
Here’s a dashboard screen with multiple stages, that adapts to the different stages in the user’s journey.
These wireframes will be skinned with the design system components and then prototyped and tested with users.
Communication
Wireframes communicate an essence. It’s a great way to validate the direction. But of course, every company is different, and so are its people and processes. Some stakeholders want only to see the final product, some want the entire process mapped out or some want to just see sketches on paper.
How to communicate and at what stage, is something the designer must sort out based on the organization they’re at. What floats your boat?
Learning is, to strike a degree of depth in the design documentation to ultimately make it suit any and all kinds of stakeholders.
With a design system in place, I sometimes find it easier and quicker to create the designs before the wireframes. And with a strong sense of visual design, it’s sometimes very exciting to see the interface develop in iterations. Sometimes even satisfying. But I also create the wireframes, to validate the flow and for documentation.
Creating wireframes from high-fidelity designs sounds ignorant or even stupid, but if done right, it works wonderfully. Sometimes you need that visual cue to be decided and put to rest, before going back up to the surface.
By understanding the dynamics of the vertical and the users who get the job done, you’d know that the last option stands out more in comparison to the other 2. There are probably many other ways to do this, but this is already a good way to move forward and test with. And it is possible to get here without a wireframe.
In design, communication is key. Designers must always try to over-communicate, not under. But if it depends on time, and it must be clear to the designer, if the problem needs a wireframe or not. And to know this, the designer must know how to tango with wireframes. And to tango, you must learn and appreciate your partner.
In conclusion
Wireframing cannot be obsolete.
Not yet. Not until robots start designing for us. And for designs to be human, we will err and iterate on our designs, only to make it more human-centered.
Wireframes aren’t concrete.
They are attempts to represent a layout and information architecture without color or any visual or content fidelity. They leave room for discussion.
Wireframes aren’t a waste of time.
They help you spot the gaps and understand the unknowns. They take from processes like card sorting and contribute to validation with low-fi prototyping. Investing some time early-on might just save some time later in the process.
