I would love to say that I seamlessly transitioned from ideation to producing wireframes. As I cannot, I will take the opportunity to explain how I eventually made this transition by better understanding the differences between sketches, wireframes, prototypes, and mockups (comps). Also, it’s a reminder of why hands-on practice is needed to fill in the gaps that theory often cannot bridge.
So why did I need to learn the distinctions between sketches, wireframes, prototypes, and mockups to make wireframes? The reason is that they’re all similar and really only differ in fidelity (or how much resemblance there is to an actual, polished product). As I read articles about wireframes to get tips, everyone had a slightly different approach to what a wireframe was exactly.
The difficulty is that with the exception of mock-ups, the other three– sketches, wireframes, and prototypes– can be executed with various levels of fidelity, which at each extreme makes them begin to resemble each other. A hi-fidelity sketch begins to resemble a typical wireframe. An “interactive” wireframe is a prototype, even if that means manually moving papers around in front of the user.
But if we have to rank them by the average level of fidelity they usually possess, it would go from sketches, wireframes, prototypes, to mock-ups. A tricky thing is that by testing a wireframe, they basically become prototypes even if that wasn’t the designer’s original intention. Furthermore, prototypes may be very low fidelity if the goal is just to study user’s reactions.
Why do we produce sketches?
Sketches, using a pen or mouse, are for rapidly generating and outputting ideas. Many say that designers should aim to produce a large amount of sketches and not shut down any ideas. It’s all about production, at least in the first stage.
In the second stage, ideas can be ranked, merged, or eliminated. This is where the most interesting (and feasible) ideas are fleshed out more. The level of fidelity should allow for exploring ideas. Time should only be spent on producing details only if the idea would suffer without them.
Why do we produce wireframes?
Wireframes are where the chosen ideas begin to be fleshed out. At this point, it’s important to start considering the context or environment they will be employed on, whether that be a table, a wall, or a phone.
Their purpose is to show functionality and layout. With them, teams can decide how a certain functionality can be presented and what to include within the layout. What they offer is an ability to get buy-in from users and clients. At this point, ideas can be shown to users to see if they would be interested in such a feature and if any information is excessive or missing. Wireframes are time savers.
The fidelity of a wireframe should never be too high, because they may get users to critique visual design decisions which those haven’t been made yet. When testing, any such distractions should be eliminated. Using grayscale and simple shapes are great. The level of styling should have users not want to critique visual choices yet not be turned off either.
At the same time, the use of boxes with a X or fat lines to substitute images and text respectively does not always suffice. For certain ideas, obliging your users to make such giant leaps in imagination are not worth just spending some time to get a bit more specific through a sketch or icon library.
Why do we produce prototypes?
Prototypes are interactive wireframes. While wireframes let you check for interest and utility, prototypes allow you to check that in addition to how users feel about the tools you offer and how easy it is for them to execute.
Here, from simple verbal description, to pieces of paper representing buttons, states, and interactions (dropdown, selecting an item), to slide presentations, to clickable code, prototypes allow one to see how a user would go through your program, see what they would choose, and if they would be able to get things done without too many frustrations and hopefully with lots of satisfaction at the end.
The fidelity really depends on how much time it takes you to make it. If coding is hard, don’t do it. If paper isn’t sufficient but you don’t have time to make other things, just talk. It depends on the tester’s ability and the user’s ability to imagine and interact.
A newer thing: Task flows, user flows, and wireflows
While testing, it would be useful to be able to show users and clients the different stages or screens. That’s where task flows and user flows came in handy. By figuring out what was needed at each stage of a task, and grouping those together to generate a user flow, designers could see if the flow they envisioned is simple and intuitive.
However, as telling users about the stages may not yield much information, wireflows were developed. Wireflows are basically a set of wireframes used to describe a task or user flow.
By developing them, it’s easy for the designer to figure out what parts are missing and what could be done to improve the flow. Then they can use this flow to test with users. Will users follow the same patterns and order? Will they get frustrated?
My dilemma
I was struggling to create wireframes because I was unsure about the level of fidelity to produce. Too low and they would be sketches, which I had already done, several times. Too high and I would be making prototypes/mock-ups, which risks wasting time and distracting users with other things to critique.
Once I nailed the distinction between them all, however, and determined their strengths, I could finally make my wireframes. I needed to make it just detailed enough to not waste time and provide functional elements to have critiqued.
I was also worried about the user interface and where to place everything. I wanted to spend hours learning about UI best practices and tips and tricks. However, I quickly remembered that while reading up on the subject wouldn’t hurt, it was best to just get some practice. Plus, user experience is all about letting the users help guide us in our decision making. If I spend time reading and little time producing, how would the users guide me then?