Recently I started seeing a trend where fellow designers skip wireframing/low-fidelity-mockups and jump straight into their UI work. While for “some” tasks this might be okay, I believe for majority of your tasks, this will hurt your final design.
First, what do I mean by wireframing?
When I say wireframing, I am not really talking about fancy wireframes built pixel perfect with nice colours and everything, like the stuff you see on Dribbble.
What I am talking about is any kind of quick sketch of the layout. How you create it is completely of your own choice, you can use pen&paper, Sketch etc. The important part is this should be something that you can create super quick, modify as needed, and will not feel bad for throwing it out if it doesn’t work.
Wireframes should be a way to express the overall idea you have for a page or interaction. It is more about how it should work, rather than how it should look like.
Why do you even need wireframes?
Pen & paper can be a very quick way to create your wireframes
If you don’t do it properly, wireframes might feel like a redundant additional step that takes up valuable time between your ideas and your final designs. However, the reason we make wireframes is not just to have a skeleton for the UI design, but to be able to quickly iterate, modify and get feedback on your design.
When you ask people for feedback, you get very different responses when you show a wireframe vs. when you show a polished UI design. Wireframe encourages people to comment on how things actually work, how the screens connect and what the structure of the page looks like. Whereas the UI design makes people think about the colours, the overall feeling of the page, how the content fits in, how the spacing is done etc.
I am not saying one feedback is better than the other. The thing is, you need both of these to create a successful design. So you should make use of both types of feedback to improve your design.
Who to ask for feedback
Another potential pitfall here is showing the wrong screens to wrong people.
Wireframes are not for everyone. They require some kind of understanding about how they work, and a bit of an imagination to get a feel of how the product would be when it is finished.
Thus, if you show your wireframes to one of your users during a user test, they might not give you the feedback you were expecting. For designers and for others working in tech companies; prototypes, mockups, and abstractions feel natural, we use them all the time.
Yet, this is not really the case for an average user. When people show up for a user test, they expect to find an actual product. They might understand it not having all the functionality or maybe having some bugs, but they expect to see a polished look, not a couple of boxes.
Of course this situation might differ depending on your target user group, so just like everything else in UX design, consider your target user group to decide what kind of screen you want to use in your user tests.
Wireframes help you get on the same page with your fellow designers
If your user group is not really suitable for testing your wireframes, your next best option is your colleagues from the company. They might also require some explanation before jumping into the test, but in general they should be more willing to understand and learn compared to an average user you’ve invited for testing.
As testing with your colleagues requires a low budget compared to conducting an external user test, you can also try out several iterations with them. And as wireframes are quick to modify/create, you should get results within a short period of time.
Wireframes as deliverables
The last point I want to talk about regarding wireframes is using them as deliverables for your development team.
If you are not at the very beginning of a project, you probably have a component library, a general style guide, or some other way of defining how things should look like throughout the application. So, unless you are introducing a completely new component to the application, your wireframes should contain enough information for the developers to code it.
The more important part the developers care about would be the various connections between the screens and how they interact within themselves. Wireframes provide a very good environment for showing such things as they usually do not have too much visual clutter, you can easily add arrows, description texts, annotations, or whatever else you need to explain the interactions and possible paths the user can take from these screens.
I am not saying you shouldn’t deliver a high fidelity mockup, you probably should, so that the developers can make sure everything looks correct, and it could be that you overwrite some of the rules from the style guide to match a particular need. Yet, still the wireframes (in the form of a user flow) would be a very valuable source of information for the developers, so that you don’t need to talk about how all these screens should work together after the delivery.
Closing notes
As you might have guessed, I love my wireframes and I find them quite useful to have as a part of my design process. I hope these points can get you to at least give them another chance if you have been skipping them lately. It is tempting to jump into the UI design part with our new shiny tools, design systems and all that, but we should also consider the benefits of wireframing and try for ourselves to see if they can approve our design process.
This article was originally published on Nazli's Medium page.
