1. You’ve Shortlisted an Idea 2. You’ve got a clear Product Narrative
If you haven’t done both of those, please go back and complete those targets . You can’t build wireframes without having a Product Narrative.
Why is this important?
Before you build, it’s a good idea to know what is it that you are building.
A wireframe is a visual depiction of your customer UX flow.
It’s a collection of “screens”. Each “screen” is what the customer sees at a certain point in the Product Narrative.
Let’s look at some examples:
In the previous screenshot, each “screen” of a mobile application is mocked up.
Here the wireframe “screen” maps to an app screen, but it’s sometimes not like that. Like for example: when an error occurs , you might want to denote that using a different wireframe “screen”
As you can see here, you can also use wireframes to describe just one portion of customer UX . In the previous image, it’s “What happens when the user clicks the Share button?”
The purpose of a wireframe is to communicate & clarify. So, you can use annotations (the yellow circles in the previous example) to clarify intent and purpose.
Annotations (as in the previous example) also describe how customers move from one “screen” to another.
In short: somebody looking at your wireframes should be able to figure out how the user will enter your product , and how he will travel through your product.
How do you start building wireframes?
Two principles: 1. Lower-fidelity ones are better to start. 2. Build from the “inside out”.
1. Low fidelity to start. Fidelity = how close to the final product the wireframe is.
The one on the left = Low fidelity. The one on the right (looks like a real product) = High fidelity
But lower fidelity is the best when you start. Why? Because Low fidelity lets you concentrate on the Customer User Experience & not the Visual Design.
Second principle: Build from the “inside out”.
Build from the Inside Out = Build the most important UX of your product first , and then the second most important, and so on.
Let’s illustrate with an example. Let’s imagine that you are building a Uber clone.
Your Uber clone has these 10 “screens”: Signup Login Type Destination Finding Car Car Available Car Not Available Car Arrived On Trip Destination Reached Fare Collection
Step 1. Your task: pick the most important “screen” first and wireframe that.
How do you find which is most important? Answer 2 questions. 1) Which screen does the customer use the most? 2) Which is the screen if it breaks, the user will not be able to use your product at all?
One answer to question 2) above is always the Login/Signup screen. For the purposes of Alpha, ignore Login & Signup flow . (we’ll cover Onboarding flows later)
So aside from Login & Signup, which screens are important based on this criteria? 1) Which screen does the customer use the most ? 2) Which is the screen if it breaks, the user will not be able to use your product at all ?
These are the screens available: Signup Login Type Destination Finding Car Car Available Car Not Available Car Arrived On Trip Destination Reached Fare Collection
This is more art than science . But according to my judgement, the only reason anybody opens an app like Uber is to find a car. So the screen that’s most important is simple: Type Destination
Cool, so Step 1 done. You have identified which is the most important “screen”
Now Step 2 is to answer this question: within that screen, what is the most important element?
i.e. within Type Destination , what is the most important element you should wireframe first?
To make this clear, let’s look at a concrete real-world example.
This is how the new Uber app approaches the problem.
Let’s assume this is the final build of your app. Which element would you wireframe first?
Remember: this is the Type Destination “Screen”.
Is it this?
or this?
It’s pretty obvious that it’s this destination entry area.
So: wireframe that first!
Then extend that area outwards.
And outwards.
Note: you should probably leave common navigation to the last .
This is what we mean by Build from the “ inside out ”.
That’s it! :)
Let’s recap: 1. Lower-fidelity wireframes are better to start. 2. Build wireframes from the “inside out”.
Todo: Based on your Product Narrative, build a set of Low-fidelity Wireframes for your Product.
There are several online tools available to build Low-fidelity Wireframes.
There are several tools available to build Low-fidelity Wireframes. https://moqups.com is a good tool to start.