There are many articles listing and summing up the pros and cons of wireframing, defining what a wireframe is and what not and where the difference between prototypes and wireframes are. That’s why we won’t go that much into detail here and rather focus on 5 common misconception about wireframing and how they can be avoided.
1. Wireframes have to be hi-fi
Wireframes come in many different shapes, sizes and even with a different degree of fidelity – from low to medium to high fidelity – all depending on your individual wireframing needs. So yes, wireframes can contain many details and the more they look like the final product, the less abstract you have to think. Of course it’s a good way to demo your app or website idea as well as its USPs and core features to potential clients, investors or stakeholders who prefer the touch-and-feel experience over abstract thinking. But you certainly won’t present them your very first idea. Especially in the early phase of the product development process you only want to quickly scribble your basic idea and refine it with same basic elements, placeholders or transitions. It’ll be all about testing your idea and its feasability.
The lo-fi wireframe supports all that! So put your papers aside, stop overexplaining your idea, and just use a simple lo-fi wireframe and tell a story with few words only. Additionally, the lo-fi wireframe prioritizes the core functions of your deliverable by demonstrating the structural placement of the content, potential functionalities and intended interactive product behavior. In terms of design, you can keep things functional rather than pretty and if necessary at all just use a few colors only, integrate some placeholders where text or images should be.
2. Wireframing is for UX folk only
The awareness for UX has risen in the past years and more and more companies understand the value of integrating UX in their product development process. However, the term “user experience” is on the edge of becoming a fuzzy buzzword. Wireframing is closely connected to UX as it’s about the alignment of elements and mainly about creating an interface that users are happy to interact with. That of course pushes the assumption that wireframing is limited to the people who mainly focus on UX. But it’s not. Because wireframes are necessary for everyone who’s involved before the release of the finished app or website.
First of all, wireframes however provide a quick way to achieve a joint understanding of the deliverable. They also help to bridge communication and to get all your product stakeholders from the developer to the designer to product manager on the same page. Thereby the iterative process loop of getting feedback and improving is assured. But it’s also about the users! Before investing a lot of time and money in coding and releasing the app or website, you certainly use your wireframes to run several usability or A/B tests. During that iterative process, wireframes are the quickest and easiest way to generate results and to create the best possible user experience.
3. Wireframing is unnecessary in times of agile development
In times of agile development, wireframes seem to be out of time and apparently, the focus now moves on to interactive medium- to even high-fidelity prototypes. Because such kind of prototypes speed up usability testing, extend feedback rounds or even help to lean back on living documentation. That’s not wrong, but speaking of time and cost effectiveness in the early product development stage, you won’t skip development steps and start with a highly detailed version straight away. Instead, create a consistent and well-structured development process to avoid misunderstandings from the very beginning.
And that’s why a wireframe is still needed and even more: it’s the skeleton of your deliverable! Wireframes help you to create the architectural structure of your deliverable, build the concept and form the foundation. It’s more than just a sketch and the wireframe will soon evolve over time, receive more and more details, morph from a wireframe to hi-fi prototype, become the code-ready version and finally the released version.
4. Wireframing is best done in presentation programs
There are many different ways to create a wireframe and basically it depends on your needs and so any program could be helpful to scribble an idea. That’s why often some of the most common presentation programs are used. And they might even be sufficient if you want to click some screens. But what if you want to receive feedback on your wireframe, would like others to be able to edit it, or you need to send it to your stakeholders? The only way to do it is forwarding the presentation file. However, it’s very likely that not everyone will be able to access it and see the result properly due to program incompatibilities. Working already with a few people, you’ll get many emails with a lot of feedback, which you’ll have to sort, combine it with the corresponding spot in the presentation file and also have to compare all the submitted change requests.
Here it helps to consider the main functions of a wireframe: consistently gaining feedback. The best way to do that is by choosing and using a wireframing or prototyping tool that suits your needs best and most of all allows for collaboration. After defining your product team roles, you can make them all join your wireframe in the professional wireframing program. Now, all of you can view the current state of the wireframe, share comments on it, edit the wireframe together in real time or separately while everyone still gets the latest wireframe state.
5. Wireframes can be replaced with design comps
Design comps (short version for comprehensive layouts) act as the visual drafts of the final product, which means they actually look like the final app or website just by adding graphics where formerly placeholders were seen in the relatively sparse looking wireframe and moving them nearly pixel-perfect to their positions. Comps are the layouts ready to be forwarded to the decision-makers and once approved serve as the design guide. That’s why it’s quite tempting to assume that such visual comps make creating a wireframe absolutely redundant. But in fact it’s not! Where comps focus on design, wireframes also include the interactivity.
It might be one of the longest ongoing discussion in the field of UX and wireframing. However, there’s a good way to keep things clear: wireframes act as the basis of a visual comp or at least as its supplement and help to define the product requirements. Most importantly, wireframes support the data-driven UX process, while comps support the visually-driven design process. With that mindset, visual comps and wireframes only come along together and rely on each other as they will be your best way to both create and iterate your deliverable.