Sketch Before You Etch: How to Prototype Like a Boss

Post on 13-Jan-2015

214 views 0 download

Tags:

description

Time. Money. You know that story. But there's an answer: Start with the prototype. Crazy? No. Prototyping at the beginning of a project, feature, or interaction lets you explore new and different ideas that the traditional "requirements > design > develop" process doesn’t always uncover. You and your team will start the project with a better understanding of your users’ needs, you'll lessen the risk of overspending on development and ultimately, you'll end up with a better design much faster. In this workshop, we’ll focus on prototype methodologies all the way from sketches to functional code and how to determine the appropriate fidelity, both visual and functional. You’ll learn how to test your ideas, elicit useful feedback from customers and explore tools that can help you prototype like a boss. *No development skills are required, but you should be able to draw a square. Not even a perfect one, really.

transcript

Sketch before you Etch:How to Prototype like a Boss

Hello.

Let’s get down to business.

Who is prototyping at their job today?

Agenda.

• Part One: Sketching

• Part Two: Feedback

• Part Three: Iterate

• Tools & Frameworks

• Manager Buy In

Part One: Sketching.

What happened?

Part Two: Getting Feedback.

A few tips:

• Don’t give a guided tour

• Shut up

• Ask open ended questions

• Follow up

• Let the user fail

• Observe the user

Part Two [ish]: Writing the questions.

Part Not Quite Three: Asking the questions.

What happened?

Improvising & the value of failing fast.

Part Three: Iterating.

Part [still] Three: Working together.

Some things to remember:

• Don’t forget to include the business!

• Observe as much as you possibly can.

• Some ideas just don’t work [that’s okay!].

Paper is great and all, but...

Medium-fidelity prototypes.

High-fidelity prototypes.

Incorporating prototypes into your project.

When is it appropriate?

• Whenever you have a new feature you aren’t 100% sure about

• When you’re demonstrating a new process

• When you have vague requirements

• When the day ends in y

Manager buy in.

The arguments.

• “It will take too much time away from development, pushing our deadline back.”

• “We need documentation!”

What else?

Thanks.