Imagine you are trying to describe an elaborate dance to someone and all you have available to you is a series of pictures. Sure you can add words to the pictures - "The dancer spins around moving her left arm in a wide arc while holding her partner by the right hand" - but you will never be able to communicate the rhythm of the dance or the subtleties of the movement. The same is true for interface design. Static mocks alone are not able to communicate dynamic designs. To truly convey a user experience you need to build a prototype. Not only does a prototype communicate a design to the team, but it can be shown to potential users for feedback. The team can experiment quickly. Problems can be discovered early and corrected before a huge investment is made in the wrong direction.
Designing for mobile presents a unique set of challenges. Mobile applications use gestural interactions and animations that were unimaginable even a few years ago. Fortunately, a number of tools are now available to help designers quickly prototype on mobile – Invision, Principle, Origami, Framerjs, Flinto, and Pixate - to name a few. Each tool has positives and negatives. The important thing for a mobile designer is to pick the tool they are most comfortable with, and then invest the time to learn it.
Regardless of the tool you choose, you should begin any design project by asking who you are designing for, and identifying the key use cases. If you are designing a news reader app targeted at Millenials who are grabbing a few minutes during their commute to catch up on the news, that is very different than designing for the insurance claims adjuster who spends the entire day using your application. You may have a great design, but if it is optimized for the wrong type of user and/or the wrong usage pattern, it will fail. Get your designs in front of potential users at every stage of the design process and iterate based on their input.
All of the prototyping tools mentioned above have an editor. Screen designs can be loaded into the editor from Sketch, Photoshop, and other graphics applications. In the editor, the designer specifies how the screens will interact with one another. The finished prototype runs natively on the mobile device and so it looks and feels just like the real application.
You can easily try out different animation parameters such as Delay, Duration, and Easing Curve. You can fine tune the interaction and get it precisely the way you want it. You can share your design with your team, and show it to potential users of your app. Below are two example prototypes that will give you and idea of what is possible.
Let's say you are designing a list
interface and want an intuitive way for users to remove items from the list. You want the experience to be
obvious, smooth and maybe have a little bit of panache :-) So you come up with the design below.
When the user positions the pointer over a row, the row highlights. When they click the X, the
row fades and then animates closed. Go ahead and try it below.
This design is typical of the type of interaction common on the web today. A pretty simple interaction, but it would not be that easy to described in words. In fact, to get the details of this interaction correct, you really need to see it in action. How else are you going to know how to balance the speed of the fade and the close animations?
We call this "rapid prototyping" because our sole purpose is to demonstrate the design. Because we are not trying to deliver production-ready code, we can work very quickly. We need to be 100% accurate in the demonstration of the design. But once we've attained that, we're done.
So how does one create a prototype like the one shown above? It’s not as difficult as you might think. Let’s start with some basic concepts.
Every medium has its own strengths and weaknesses. An artist working in oils can do things that one sketching in pencil cannot, and visa versa. If an artist tried to use pencil-sketching techniques while working in oil, chances are the results would not turn out very well. Just like an artist, the designer must understand the medium - i.e. the client technology that will be used in the product. The capabilities of Flash for example are very different from those of HTML. When a designer understands the client technology, they can exploit it. This is why it is important that prototypes be constructed using the same client technology as the product.
Here is a simple example that demonstrates some of the concepts discussed above.
Clicking "Show more..." does two things. First, it displays additional information about Massachusetts. Second, it changes the link to "Show less...". Below is the code for this example. You can copy and paste this code into a code editor, save the file with an extension of .htm or .html, and it will run in any modern browser.
The "moreInfoContent" div has a style, display:none. This hides this div by default. When the user clicks the link "Show more...", the function "showMoreClick" is called. This function does two things. First it changes the style of "moreInfoContent" to display:block, which causes the div to be displayed. Second it changes the innerHTML of the "moreInfoLink" to "Show less..." and a different function call. The other function "showLessClick" does the reverse, making this a toggle.
This is a simple example but it demonstrates some very important concepts:
· Objects on a web page can be given ids.
· Functions can manipulate objects on a page.
If you understand the concepts above you are well on your way to adding dynamic behavior to your prototype.