- [Instructor] Wireframes and illustrations helps in the overall design and layout, but they don't really show interaction. Let's look at some of the alternatives for doing that. For applications where you have rich interaction you can extend wireframing or illustration to do a paper mock-up. To do that create several related pages, views or partial sections, as wireframes or illustrations. Print them out. You can cut out partial sections to allow them to represent how a section of the screen changes with an action.
Then you run through the interactions with the user while showing what happens when various options are selected or buttons are pressed by overlaying what the application would then look like. That might mean swiping down a whole new screen or it might mean overlaying one of those partial screens, to just change a part of the screen. Paper mock-ups have a very high cost benefit ratio for evaluation of interactions. They're a let cheaper to create than an interactive prototype. But sometimes you will want to do a prototype.
Especially, when your design is a real departure from what users have seen before. In that case, you need a prototype to make it real for them. Some people have trouble imagining working software from sketches, or even paper mock-ups. They need to see something much more like what the end product will be. But the danger then is trying to make the prototype too much like the real thing. Don't do that. Just go far enough to capture the layout and major interactions.
A typical prototype will have a lot of buttons and options that don't work or that put up not implemented messages. You should normally be the one showing it to the user, so that you can focus on the important parts where you need feedback and avoid the parts that don't work. Your philosophy should be that you're going to throw away the prototype when you start production development. You'll be tempted or your manager might be tempted to think that you will save time by turning the prototype into production software.
I have never, ever seen a case where that was true. Start over, really, start over. Here's a screenshot from a full app prototype. It's for that same fuel management app that you saw early in the course. During prototyping, we don't worry much about colors, or precise layout. We put in colors where it's meaningful, such as the fuel tanks, but otherwise, we go with a fairly neutral color scheme. We're just trying to get a general idea of how the application will feel to the user.
Let's compare to a screenshot of the finished application. As you can see a production app has a lot more attention to detail. And it's common to refine the layout based on user feedback. This application, being a commercial package has had a lot of visual theming work. Don't do that work in the prototype. It's much easier to change styles and things during development than it is to change an app's interactions. Here's another example of a prototype. This time for a single screen, that is designed to take payments.
You might be wondering about the graphics in these prototype, by the way. When I wrote them, I used a program named Metro Studio, which has thousands of vector graphics. For example, the graphics for a check and for a credit card came from there. Metro Studio is a free package but you have to request an activation code. It will let you search for a graphic and then copy it in common output formats. You can get an image, or an SVG which means scalable vector graphic, or if you work on desktop applications in Windows, you can get a graphic in their XAML markup language.
In rare cases where you have large user populations or other special circumstances, you may want to make a prototype that looks and acts quite a lot like the real app. Then you can have the user operate it instead of you demonstrating a prototype. You should be aware though, that type of prototype takes time to create. At least three times longer than a hacked up prototype. And it could take as much as 10 times. You will need simulated data that is close enough to the real thing that the user doesn't get hung up on it.
And you'll need to implement almost anything that the user can do. What you're looking for with this prototype, is how easily users figure out how to use it, and where they get hung up. You typically post tasks for them, and just watch them try to accomplish the tasks. You can even time people to see how long it takes for them to figure things out. But in my experience, it's usually overkill. I still don't recommend using one of these prototypes as the start for a production app, however.
- What a well-designed app looks like
- Leveraging cognitive design principles
- Decluttering crowded screens
- Understanding your users' needs
- Recording and analyzing user observations
- Storyboarding your ideas
- Helpful techniques for the design process
- Dealing with conflict in design evaluation