Design Lecture: On Prototyping
areas are interactive, to guide the user quickly and easily? What’s the
Hi everyone! So, for the past few weeks you’ve been working on
concept models, flow diagrams, and UI sketches as you tackle your
individual project around a “life logger” for some quantifiable pieces of
data. We are now going to “cross the threshold” — which our theme for
today — into the world of behavior and action, by way of prototyping.
Let’s delve deeper into what prototyping means, both
the mechanics and mindset involved. First, let’s break apart the whole
concept of prototyping as it pertains to the practice of design.
Why is prototyping valuable? It’s about trial and experimentation! With
an emphasis on speed, utility, iteration, validation. It’s a powerful
stimulus to solicit reactions from users and stakeholders…which leads
to…
Who is prototyping for? We all say it’s for users — to validate a
concept’s viability or desirability. Does it match user expectations and
assumptions. That’s true! Yes, of course. Also, it’s for product managers
and engineers — to help them understand and critique a draft solution,
poke holes and break apart the reasoning, to clarify the intentions and
outcomes. Executives and other stakeholders (sales, biz dev, various
clients, etc.) in the process have a keen interest in a prototype to help
rationalize decisions and visualize (or at least make sense of)
directions.
But it’s also important to note that prototyping as a practice is also
highly important for the designer! Of course, right? It’s a way for the
designer (or design team) to try things out, play out hunches and
intuitive leaps, explore potentialities of material and form, uncover the
boundaries of a problem space, suggest possible trajectories of thought,
and raise critical issues not surfaced in a 100 page requirements doc or
JIRA ticket. Prototyping in this way becomes a useful sandbox for the
designer!
So, what is prototyping exactly? If you had to explain to a skeptical PM
or doubtful engineer, armed with their faulty preconceptions, how would
you describe it? It’s basically an activity, a method, a way to clarify
understanding of the behavior, functionality, and interactivity of a
proposed solution, that’s based upon an attitude of experimentation and
learning and discovery. It’s a low investment, high impact approach to
explore a possible solution that’s part of the design process. That’s all.
It’s a vital part of the design process that benefits everyone to varying
degrees.
And it’s a crossing of the threshold, from a world of generally static, two-
dimensional representations into a world of behavior, response, states
and conditions, where things become…Alive. Functional. Real.
Let’s talk about the mechanics of prototyping, some of the key
concepts that underlie the making of a prototype. It’s not just about
what’s the latest, coolest tool to make it happen — we’ll get to that
shortly!
As you think about what to prototype — in effect a user’s pathway
through a product or service interface — you need to consider the
following facets that shape that interaction, or encounter, to a sufficient
and necessary level that helps you (and your team) understand the
problem space and make decisions forward to improve the solution to
be delivered, as well as whatever learnings to be validated by user
testing.
It’s best to ground your prototype in terms of a primary use case or
some brief, scoped out narrative or scenario — what’s the context, the
situation of use? Where, when, what’s happening around the user, etc.
Drafting a quick script or sketching out a short storyboard helps!
Then think through the following behavioral aspects:
Action and reaction: Where are the trigger points for an action to
occur? Where exactly do you intend to tap, click, double-click, etc. What
are those actions and how do they map to the interface or device, in
terms of locations. What happens after the action, how is this
communicated to the user, is it sensible given the conditions of use?
Affordance and feedback: Is there proper visual indication about what
feedback given to the user that something as changed? How will you
express that in the prototype?
States and conditions: Increasingly for complex apps (particularly for
enterprise or industrial situations) the user needs to be aware of multiple
states and qualifying conditions for certain actions and paths to be
available. How are these being expressed in the prototype easily for
user feedback?
Sequence and timing: Consider the sequence of actions and screens,
what comes up when, particularly if there’s multiple elements on the
same screen, or all in-context. There’s a careful choreography of timing
of elements involved in some cases.
Navigation and orientation: How do you move across the screens
within the app, how do you know where you are and how to get back to
“home” or whatever the landing screen is? This maps to your “happy
path” defined for the user story that you wish to illustrate in the
prototype.
Motion and transitions: Increasingly with mobile apps and beyond,
motion has become a valuable way to convey a sense of navigation and
context. Consider if and how this is useful for your app, and ways to
prototype that well to solicit positive reactions.
Edge cases: Yes, sometimes you need to consider the edge cases
(after the main use cases) to ensure users aren’t totally caught in a bad
spot. What are the blind spots, alleyways, dead-ends that might be
worth exploring and prototyping to ensure those are dealt with?
Whew! That’s a lot to keep in mind as you prototype. This is why
prototyping is an art that’s developed over time, not executed simply by
using a single powerful tool.
Speaking of tools, Cooper created this fantastic matrix of effective
prototyping tools for designers to use. Note the filters at the top which
allow you to narrow the tool choices per your needs.
Basically, you should select whichever tool serves your needs in terms
of exploration, discovery, understanding, learning/validation, and
working with devs/PMs to communicate effectively. There is no perfect
prototyping tool — sorry! — but it’s a balance of time, goals, skills, and
needs :-) Hey, that’s life as a designer! You should optimize for what is
sufficient and necessary, not something fully perfect.
A couple more key ideas around prototyping, then we’ll wrap up.
What I’ve been talking about primarily pertains to digital prototyping.
There’s in fact a whole spectrum of prototyping, as an activity moving
everyone from abstraction to reality, from sketches on paper to fully
robust interactive coded prototypes ready for production.
It’s important to realize this spectrum because you don’t always need to
jump to digital, sometimes it’s ok to stay at the more primitive levels to
gauge general conceptual feedback. I suggest, in real-world practice,
that prototyping is a powerful activity that enables the designer’s journey
from abstraction (a novel but fuzzy idea) towards reality (the engineered
product), in concert with a multi-disciplinary team.
1. Exploratory PLAY: prelim exploration and play, trying out options,
feeling out boundaries and limits, gathering early user inputs, making
sense of toolkits, etc. This takes the form of whiteboard sketches, paper
prototypes, sandboxed code tests, throwaway exercises, etc.
2. Communicative PROPOSAL: well-formed proposal for discussion,
iteration, and formal usability evaluation. This takes the form of a
concept car, sales demo, vision video, proof of concept, etc.
3. Declarative SPECIFICATION: specified solution with granular
decisions for the content, behavior, and visuals, whereby the prototype
is a functional demonstration of the real product’s features/styles. The
prototype is robust enough to serve as the design spec itself (with
minimal supporting documentation).
The end goal is achieving a prototype that effectively serves as the
spec, or “prototype-as-spec” (proto-spec, as some have called it). It is a
behavioral representation of the real product, at a highly resolved
degree of fidelity for effective communication of the intended vision to
the programmers, and QA testers. This would help get designers out of
the documentation maintenance quagmire, and foster stronger ties
between design and engineering, also provide efficient, clearer
communication of what the design should do! 200 page Word
documents with endless tables and labeled figures can only do so
much…and can actually be counter-productive! Having a robust
behavioral prototype of the real thing is much preferable for designers
and programmers alike.
As you consider creating a prototype for user studies, always consider
what exactly you wish to learn / understand / discover / validate and
what is the proper form of the stimulus (the prototype) that will get you
there. If it’s general abstract ideas about the form and layout and
concept model, then a paper prototype or something that feels “raw” is
fine if framed accordingly. If you’re looking for specific inputs on
controls, behaviors, feedback models, or something that’s very culturally
specific (like comparing TV show selection interfaces in China vs India),
then you’ll be more successful with a more hi-fidelity, pixel-accurate
prototype to get the desired feedback for decision-making. So please be
sure to map the appropriate fidelity of the prototype to the kind of
response you need to solicit. It’s generally a 1–1 relationship.
8. Market- Know, or at least attempt to predict, the size of your
target market.
9. Competition - What are the alternative solutions to the
problem you are trying to solve?
10. Business model- How are you planning to make money?
Show a schedule when you expect revenues to pour in.
11. Investing- What is your planned budget? What kind of
money are you looking for?
12. Contact - Leave your contact details and let people know
how to reach you quickly.
PITCH DECK DO’s
 Tell a story & engage people emotionally. Everyone loves
to hear stories, even the investors. So tell an exciting story
about your startup.
 Limit each slide to expressing one idea. You want to keep
your entire audience on the same page
 Prepare to make a great first impression. First
impressions are powerful. Believe it. The first 2‑3 minutes
are the most important
 Show the people behind your idea. Focus on a significant,
relevant accomplishment for each person in a team that
identifies that person as a winner
 Keep a consistent look in presentation. Use the same
font, size, color and capitalization format across all slides of
your investment pitch deck.
 Know your metrics better than anyone. Traction speaks
louder than words.
PITCH DECK DON’T’s

Raw, coarse-grained prototypes solicit abstract, high-level feedback,
while something more polished and accurate with high resolution
graphics will spark very detailed, specific feedback. Depending on your
stage of the design discovery and evolution process, and the kind of
feedback that’s valuable, you’ll need to adjust your prototype fidelity
accordingly. This will save you time and effort, so please plan this out
properly in real-world situations!
One final thing before you dive into your project assignments.
Think of your prototyping “workflow” like this:
1 — Sketch out paper drawings of what the interface and path/actions
are. What’s the scope of what you’re prototyping? Always sketch it out
first, based upon some primary user story.
 Don't use too many bullet Points. Limit the bullets. Too
many bullet points will kill a presentation.
 Don't make it too long. Average entrepreneur pitch: 38
slides. Average VC attention span/cranial capacity: 10
slides. Do the math.
 Don't read word by word from your script. You will sound
like a robot and miss the all‑important eye contact with the
audience.
 Don't create a text-rich, picture-poor presentation.
People cannot read and listen at the same time. Great visual
inspire and engage people emotionally.
 Don't Come unprepared. Try to anticipate the kinds of
questions they might have and be prepared with answers.
 Don't use small fonts. Always use a font large enough to
be seen by all audience members. Use 32- to 44-point for
titles and no smaller than 28-point for the text or bulleted
items.

2 — Create the pixel based comps using a tool like Sketch, Fireworks,
Photoshop, etc. for constructing the screens to stitch together into a
viable digital prototype.

3 — Build the prototype accordingly per the tool of your choice (InVision,
Axure, web/css/js, etc.)

4 — Iterate :-)

PITCH DECK

A pitch deck is a brief presentation, often created using PowerPoint,

Keynote or Prezi, used to provide your audience with a quick overview
of your business plan. You will usually use your pitch deck during face-
to-face or online meetings with potential investors, customers,
partners, and co-founders.

12 Slides of Pitch Deck

1. Introduction - Who are you and why you're here? Keep it

short and sweet.
2. Team- Show the people behind the idea and briefly describe
their role.
3. Problem - What problem are you trying to solve? Is it really
a problem?
4. Advantages - What makes your solution special? How are
you different from others?
5. Solution - Describe how are you planning to solve the
problem.
6. Product - How does your product or service actually work?
Show some examples.
7. Traction - Traction means having a measurable set of
customers that serves to prove a potential.