Prototype fidelity its not pretty. They let us quickly interact with the objects.
They go beyond show and tell
They encourage interaction
They reveal the bigger picture
They allow us to experience what could be
Prototypes are messy
CDE Wireframes were no longer effective for the kind of work we were doing. As good as our wireframe documentation model was, we were spending too much time explaining it. I don’t like having to explain my work. If I have to explain it, it’s broken. As the complexity of the system increases, the cost-to-benefit ratio of prototyping increases dramatically.
Universal Mart Have you ever tried to describe a reveal transition? My best description, coupled with some strategic hand waving and magic wand simulations, still results in raised eyebrows and questionable looks.
Symmetry Take a 60-page requirements document. Bring 15 people into a room. Hand it out. Let them all read it. Now ask them what you’re building. You’re going to get 15 different answers. Imagine trying the same thing with a 200-page requirements document—it gets even worse.
Verizon Prototypes, on the other hand, have a number of advantages that help reduce misinterpretation: • You experience how the system would work, rather than just read about it. Prototypes encourage play. When you get someone to play with your prototype, you increase the likelihood that they’ll understand it. “ We can’t afford to prototype. We don’t have the budget for it.” I’ve heard each of these arguments dozens of times. Frankly, they’re not without some merit. As I said earlier, prototyping isn’t free, but the benefits of prototyping far outweigh the cost of prototyping, or most importantly, not prototyping. The earlier you catch a mistake, the lower the cost to fix it will be.
Three-minute presentation per concept. A time limit of three minutes per presentation per concept means that you’ll have to focus on the strongest parts. And if you can’t explain your concept in less than two minutes, then something is probably wrong with it. Two-minute critique. Your peers get two minutes to critique your concept. During the critique, they have to provide two to three things they think are strong about it and one to two areas that need improvement or need to be worked out a bit more.
These sessions typically last 1.5–3 hours, depending on the complexity of the prototype. During these sessions, I follow the basic presentation and critique model, Testing with the end customer is a standard usability test—8–12 participants, 5–6 scenarios, audio-video capture, analysis, and reporting of results afterward
Ever been in the same room with a group of engineers and marketing people? They can’t talk to each other. Well, they can talk, but they can’t really have a conversation. But most importantly, getting designers and developers to work together to collectively flesh out the ideas builds relationships.
• Determine what you need to prototype. • Set appropriate expectations. • Determine the right level of fidelity. • Pick the right tool for the job. 70% plan prototype the rest little more little less Based on User Scenarios Setting expectations is based on a psychological technique known as priming . When you prime your audience, you guide their attention and focus. Create a playlist script David Gray of Xplane asked by a show of hands who could draw. Of the 40 plus people attending only a few raised their hands. Then Dave asked another question, “Who here could draw when they were a kid?” Everyone in the room raised their hands. His response was simple, “So, what happened between then and now that you lost your ability to draw?” Nobody really had a good response.