Agile Prototyping Best
Practices
Nate Ginesi

About Me
Nate Ginesi
Senior Information Architect
Background is in visual design and marketing.
Started in design and SEO and moved to
Information Architecture and User Experience
because the problem solving aspect and
psychology of design is always what intrigued me.
I love that I still get to use my design problems
solving skills while solving complex business
problems for users.
ME

About LookThink
LookThink is a full service user experience agency focusing
on B2B enterprise product design.
LookThink.com

Our Clients

$
COMPLEXITY
TIMEFRAME
Days YearsLessComplexMoreComplex
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
Our Projects
Vary widely …
• in scope.
• in timeframe.
• as to when we enter the project.
• in client involvement.
• in the number of people working
on them.

What I hope you get out of this
• Help you move to a more Agile design process.
• Obtain faster approvals from product owners.
• Create natural collaboration with design team, development team,
and clients.
• Provide smoother handoffs to developers.
• Make your lives easier.

So let’s talk about how we got here ...
PROTOTYPINGSTATIC WIREFRAMES

Shown to clients for approval:

Note the versioning, and reference to the 187 page
requirement document.
Easy to follow, right?
Given to developers for development:

I kid you not …
this happened

OUR UX SOLUTIONS

How they looked:

What the client saw:
Is this going to be open all the time?
Can I click this image?
What does this show
when clicked?
Why is this turned off?
What happens when I
click the map?
Where will this go?
What page is this?
What happens when I
click the video?
Can I click
on these?
So, can users
click these?
Why is this
turned off?
What happens when there are
more than 20 results?

We put an image here to
build trust in the brand.
The results page can only
support one search category at
a time.
We reduced the number of
links here to two to increase
focus.
Users are now enticed to
search first and can find
what they are looking for
easily.
Confused users can
now easily access the
video explaining who
you are.
The table is more well spaced to
provide easy scanning.
Suppressing the button will clue users
into the selection access.
Users will care
about the location
of their results, so a
map is critical to
them finding usable
results.
Users can now easily
access a particular
facility.
What we wanted the client to see:

We realized we were losing the fight,
not to our work, but to the static
wireframe as a deliverable

We committed to codeless
prototyping as our method of Agile
delivery

Committed to the switch in one month
1
2015
START USING PROTOTYPES!

STYLE TILES
PROTOTYPING
WIREFRAMES
Now, EVERYTHING we deliver prior to development
gets delivered in UXPin
AaDESIGNS

WHY?

Clarity …

Acceptance criteria

If you’re going to make the move to prototyping,
here are a few things to consider:
1. There WILL be a learning curve with the technology.
Practice makes perfect.
2. Don’t panic when you feel like you’re spending WAY more time up front.
What you lose in time you’ll save in frustration.
3. Timelines for deliverables will be different throughout the project.
But you’ll get more out of each deliverable.
4. Accept that there will be things you can’t demonstrate.
Look for other examples online to help.

How do we incorporate these prototypes into our process?

Why am I here talking to you?
What have we learned?
What has been successful?

Best Practice #1
Prototype in Chunks: Depth vs. Breadth
vs.

… EVERYTHING FOR ME
STARTS ON PAPER

… THEY AREN’T PRETTY
… THEY’RE BARELY LEGIBLE

… BUT THEY WORK

Simple boxes
Links to pages
Light interactions
Content if possible

Are we done here?
How do I retrieve my tasks?
How do I see what I sent?
How do I know when tasks are complete?
What do the permissions look like?
What defines a complete task?
Can I put deadlines on tasks?
Nope: This is too much
for this sprint.

Option 1 Option 2 Option 3 Option 4
For dropdown example, see navigation at www.theopen.com
www.theopen.com
Link to references online to save time.

Best Practice #2
Prioritize your use cases
for prototyping

When deciding what to prototype first
focus on targets that will
ease approvals and create clarity

Keep your ears open for statements like:
“I’m just not sure about this.”
“I don’t think people will get it.”
“I don’t understand what’s happening here.”
“Can you explain to me why we have to do this?”
“Do you think people are going to see that?”
Priority #1
Has the client expressed confusion or concern over a particular piece of functionality?
Having a client or stakeholder
hung up on a piece of
functionality is a sure fire way to
add hours to a project.
Recognize confusion and address it quickly!

Priority #2
What are the highest value targets?
Target the critical
pieces first.
If there are critical spots in the application,
e.g. posting a photo in a photo sharing app,
focus on getting those interactions in front
of people and vetted before building out
things like the settings.
Do this
before
this

Priority #3
What are the most complex interactions?
You may not have to build it out. If it’s doing something similar to another site, save time and reference that.
Option 1 Option 2 Option 3 Option 4
For dropdown example, see navigation at www.theopen.com
www.theopen.com

Priority #4
What pieces are using commonly accepted UI patterns?
If you’re not doing
anything novel, it can
probably wait.
If you’re dealing with a known entity, you
can usually wait to prototype the details,
reference another instance, or avoid it
altogether, e.g. a standard login.

Priority #5
What parts of the product have we not figured out yet?
You can’t prototype what
you don’t know.
Create the page so you don’t interrupt flow, but
leave it blank if you don’t know what it is yet.
?

Best Practice #3
Pace Your Fidelity

Two types of fidelity:
INTERACTIVE (FUNCTIONAL) FIDELITY
How complete are the links, interactions, of the prototype?
DESIGN (VISUAL) FIDELITY
How complete is the design with regards to colors, shapes, hierarchy,
layout, content etc.?

Fidelity over time
A quick landscape of prototyping fidelities. (Image credit:
Fred Beecher, Boxes & Arrows)(View large version)

Benefits of your lo-fi version
• Acts as sitemap, a 10,000-foot view
• Just the basic interactions to get through the app
• Low investment
• Helps find holes in your requirements

If you don’t have content, write it!*
• The more you write for web products, the better you
get at it.
• You get a much deeper understanding of the product.
• The best way to get the right content from the client, is
to put in wrong content.
*obviously there are instances when budget and timeline don’t allow for this, but if you’re having a
hard time getting content from a client, this is an effective way to get them to act.

The more realistic the content, the better
both designers and devs can
understand the full scope of the system

Visual fidelity over time
A quick landscape of prototyping fidelities. (Image credit:
Fred Beecher, Boxes & Arrows)(View large version)
Designs get a separate prototype.
• We lower the functional fidelity, but raise the
visual fidelity to a production level design.
• These are often done in Sketch and
exported back into UXPin.
• Since stakeholders have already seen the
functionality in the functional prototype, we
don’t have to spend time recreating it in the
visual prototype.
• Allows design and IA to work in parallel.
Designs

Don’t recreate the
prototype in design.
• Focus on a few key interactions
and states.
• Use simple toggle and hide
functions and leave out any
complex logic.
• If you’re building for user
testing, focus only on the things
you’re testing.

Best Practice #4
Annotate Your User Flows
and

Your prototype becomes the documentation
Developers follow on screen
annotations to understand
what the app DOES, and not
just follow the documentation
and acceptance criteria.
Your
documentation
here

Highlight functionality on a user journey
E.g. “A user arrives on a page
with a table of data. A search bar
is available for the user to find a
specific data element. When the
user hits search, the table will
narrow the results. Upon clicking
a result, the user will go to the
individual record.”
And then the underlines would
show the focus state, the search
results table, and link to the
individual record respectively.

Reduce confusion by including states
Ensure you have all the different states the page could be in and ensure developers can find them easily
instead of having to click around.
Provide triggers on the
side of the page and
use documentation to
supplement by
providing the story.
Side of your prototype Native UXPin documentation

Reuse elements
(links, triggers, toggles, etc.)
When it makes sense, you can repeat elements in your off screen documentation.
Best used to reinforce functionality for elements that UXPin doesn’t let you clearly pin.
Modals MultistatesHidden elements

Benefits of the documentation?
- Ensures that devs see all the interactions.
- Devs get a better sense of the product as a whole.
- It allows the devs to plan ahead before their spring begins.
- Gives QA folks more contextual acceptance criteria.
- Creates a common language between devs and designers.
- It bakes in a level of user testing.

Best Practice #5
Re-use Your Components

Reusable elements for all team members

Expand upon what is already provided
Input and search fields
that clear on click
Simulated “Spotify” style search
Custom examples we’ve created with UXPin library as a start:
Tooltips that stay active
on hover

Expand upon what is already provided
Custom examples we’ve created with UXPin library as a start:
Easily editable sliders Self contained modals that can be dropped anywhere

Why use a UI kit?
- Very quickly creates visual clarity and “value” to clients.
- Translates easily into a design language.
- Anyone on the team can use it regardless of skill level.
- No lost momentum worrying about the HOW it works.
- Enormous time savings.

Best Practice #6
Validate Small Builds Often

The more you validate,
and the more you communicate,
the more agile you can be

Early validation increases agility
• Finds small mistakes before they’re big ones.
• Finds holes in the product.
• Prevents over-architecting.
• Increases communication.

Validate small, complete pieces
• If demoing incomplete thoughts, do so in person.
• Focus on flows first.
• Move to smaller interactions next.
• Demo only once you’ve added clarity.
• Don’t abandon the user.
• Reference earlier reviews to validate decisions for better
buy in.

WHAT HAVE THE RESULTS BEEN LIKE?

Things just run smoother
We’re able to spend more time on real business
solutions and user experiences, and spend less time
dealing with … the crap.
(for lack of a better term)

Benefits of agile prototyping
- There’s no risk of someone opening the wrong PDF from the email last
week instead of the most recent version
- There’s a common language between client, developers, and designers.
- When we work in UXPin, everything is viewed at the correct size in a
browser.
- No zooming issues.
- We can easily set breakpoints.
- We know it will display reliably on the client’s devices.
- THIS is why we put designs back into UXPin

Benefits of agile prototyping (cont.)
- We’ve seen faster approval from clients.
- Clients aren’t caught up in the deliverable.
- They can focus more on business solutions and UX work we did for them.
- They can interact with the deliverable instead of guessing.
- Higher quality and consistency of our work.

Benefits of agile prototyping (cont.)
- Less cycles are being wasted on petty stuff.
- Better conversations and relationships with developers.
- Comments and feedback are more easily managed.
- No more crazy email threads.
- Feedback cycles are much faster.
- Better questions during reviews.

Overall, life is just easier with prototyping
CLIENT
IA
DEV
DESIGN

Best practices for agile prototyping (summary)
1. Prototype in Chunks: Depth vs. Breadth
2. Prioritize Your Use Cases for Prototyping
3. Pace Your Fidelity
4. Annotate Your User Flows
5. Re-use Your Components
6. Validate Small Builds Often

THANK YOU!
If you’re interested in seeing more of what we do
www.lookthink.com
www.lookthink.com/blog
Thank you for your time!
Questions?
and