How to Prototype in a Design Sprint - Meetup
This is the meetup I attended and I wanted to get out a few of the key points and my take on them down.
This is the synopsys:
In a Design Sprint, prototyping day is Thursday. This is where you will create a testable prototype for Friday’s user tests.
Thursday is about illusion. You’ve got an idea for a great solution. Instead of taking weeks, months or, heck, even years building that solution, you’re going to fake it. In one day, you’ll make a prototype that appears real. And on Friday your customers will forget their surroundings and just react!
Prototypes are easier to build then you think. These days, thanks to the internet, there are a crazy amount of easy to use prototyping tools available. Most of them free! In this session, we will show you some of the tools that we use when prototyping and share our experiences of prototyping best practices.
The prototype mindset:
- You can prototype anything
- Prototypes are disposable
- Build just enough to learn, but not more
- The prototype must appear real
I’ve already listened to the audiobook, “Sprint” by John Zeratsky, Jake Knapp, Braden Kowitz, and that is what this meetup was about.
If you don’t already have an Audible account you can have the book for free:
It’s totally free and you won’t need a credit card if it is your first time accepting an Audible book from a friend.
After you accept the book, you will be prompted to download the Audible app to start listening.
The first speaker Rohan Perera @Rohan_LD, one of the organisers, gave an introduction and his main points were as follows.
At the Start
- Start with the end end mind.
- What are you trying to test with this sprint?
- Finding out you should go further is a big win
- It is much “cheaper” than building a full solution before you find out it’s not going to work for your users
- This is about creating a tangible discussion with your testers
- Getting started is better than being right in the beginning
What is prototyping about?
Think of it as a façade of the product (or a portion of the product). It is an impression of what a future reality could be like. It’s all about learning, good and bad feedback are the goal.
- Paper (including Keynote, PowerPoint, Word, PDF, etc.)
- Service (as in changing an organisation)
- Physical Space (changing how people interact with and office/shop/etc.)
- Object (using 3D printer, flyers, leaflets, etc.)
- Explainer Video
Some examples given
- Dollar Shave Club
- Dropbox (both their original video and the latter video that propelled them to a billion dollar company)
- Tablet/Mobile App
The second speaker Daniel Alb @danielalbro gave a talk entitled “10 Golden Rules for Efficient Prototyping”
1. Make it testable
If you can’t test it, there isn’t any real value. The testers need to touch it and feel like it’s a real world situation.
2. Make it believable
- It should feel like the real thing
- You need it to have a beginning, a middle, and an end
- How do they start, what is the path, and where do we have them stop
- It need consistency in content
- don’t show shoes in the shop screen and dresses in the checkout screen
- Don’t break the illusion that this isn’t the real world
- Use real content and real images not place holder details
3. Words are worth a thousand images.
Write your copy first, it matters very much. Then you can make the images fit with the rest of the prototype.
4. Focus on the flows and scenarios
- The flow and scenario is more important than making it look as pretty as possible
- User personas will help with this
- Remember every call to action is a different journey you have to build and discuss with the tester
5. Prototype only what you need
Only do what you need to do to answer the question(s) that are the focus of the sprint
6. There is no high fidelity or low fidelity only the right fidelity.
Make it as nice as it needs to be. A sprint is a fixed amount of time, so some things will have to be a trade off.
🗝 7. Don't get emotionally attached to the prototypes
These are tools for testing like a scrape of paper to guide you some elements will be kept some will be changed and some will be tossed out.
8. Kill ambiguity and get on the same page
- Documents can be misinterpreted, but experiences are shared (for the team and the testers)
9. Fail cheaply
- One of the main goals it to avoid wasting time/effort/money on something that won’t work. So if you can fail early and cheaply that is a great thing.
10. Make prototyping the cornerstone of your design process
You can prototype at each stage. Many people think of the flow as this:
Sketch -> Wireframe -> Mockup -> Prototype -> Development
Whereas it is better to think of it like this:
Sketch -> Prototype -> Wireframe -> Prototype -> Mockup -> Prototype -> Development
I hope that is as useful for you as the meeting was for me.
~ Dave<~ Jekyll is now running my live site. |