Build Low Fidelity Wireframes

svlabs 795 views 43 slides Jan 18, 2017
Slide 1
Slide 1 of 58
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43
Slide 44
44
Slide 45
45
Slide 46
46
Slide 47
47
Slide 48
48
Slide 49
49
Slide 50
50
Slide 51
51
Slide 52
52
Slide 53
53
Slide 54
54
Slide 55
55
Slide 56
56
Slide 57
57
Slide 58
58

About This Presentation

Build Low Fidelity Wireframes


Slide Content

Build Low-Fidelity Wireframes Vishnu Gopal

Where is your team now?

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.

See Rubric too for more info.
Tags