The document discusses building low-fidelity wireframes. It recommends starting with wireframes that are lower fidelity to focus on the customer experience without visual design details. The document also recommends building wireframes from the "inside out", prioritizing the most important screens and elements first based on customer usage and critical functionality. It provides an example of wireframing the destination entry area first for a ride-hailing app since that is central to the app's purpose. The goal of wireframes is to communicate and clarify the customer journey through a product in its early stages.
12. In the previous screenshot,
each “screen” of a mobile
application is mocked up.
13. 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”
14.
15. 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?”
16.
17. 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.
18.
19. Annotations (as in the
previous example) also
describe how customers
move from one “screen” to
another.
20. 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.
23. 1. Low fidelity to start.
Fidelity = how close to the
final product the wireframe is.
24.
25. The one on the left
= Low fidelity.
The one on the right (looks like a
real product)
= High fidelity
26. 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.
30. 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
31. Step 1.
Your task: pick the
most important “screen”
first and wireframe that.
32. 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?
33. 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)
34. 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?
35. These are the screens available:
Signup
Login
Type Destination
Finding Car
Car Available
Car Not Available
Car Arrived
On Trip
Destination Reached
Fare Collection
36. 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
37. Cool, so Step 1 done.
You have identified which is
the most important
“screen”
38. Now Step 2 is to answer this
question:
within that screen, what is
the most important
element?
39. i.e. within Type Destination,
what is the
most important element
you should wireframe first?
40. To make this clear, let’s look
at a concrete real-world
example.
41. This is how the
new Uber app
approaches the
problem.
42. Let’s assume this
is the final build of
your app. Which
element would
you wireframe
first?