It’s common for designers to create prototypes to put their designs in front of other team members, stakeholders, and hopefully their users as well. Those purposes are excellent uses of prototypes in the deign process, but I also wanted to touch on the notion of prototyping for yourself.
Why create a prototype for yourself?
Right now, you might be saying, “I’ve been designing for years and I know what I’m designing is the right direction. I’m using design patterns and adhering to guidelines, it will work.”
Well, there are plenty of times where taking that approach will actually yield good or great results, but there are also many times where you don’t know, what you don’t know. Staying inside the box may prevent you from exploring a new or more innovative solution, or worse yet, the right solution.
When you design, you may have multiple art boards laid out adjacently, possibly vertically and or horizontally in your project file. You may have separate files for your designs as well (I highly advise against that approach, personally).
A designer can get a pretty good idea of what is going on in all of the views and states while designing in art boards or files and based on your guiding direction. You can usually see the distinctions between one view or state to another within the source files as well. Even with context within your design file, I still find it extremely valuable to put your designs into even the most basic prototype tool and really start to get a better “context” of how your designs work in the actual environment and with the actual interactions.
This is a video representing a basic interactive prototype created in Invision in a few minutes of the above screens. This presentation demonstrates some of the transitions between views, thus better communicating the type of view and interaction experience compared to static screens.
Context of the Experience
This “context,” goes way beyond just displaying your designs in the frame of the desktop, mobile phone or tablet device. The context that I am emphasizing is the actual “context of the experience”. When you actually get a chance to go through your designs (wireframes or design comps) and gain a more acute awareness of the layout, the placement of content and components, transitions from one view to the next, variations between states, presentation format, feedback mechanisms, etc. that is when you, the designer, will be able to really understand the “experience.” It is essentially a usability test for you.
You don’t need a high-fidelity prototype with animations and full color screens to accomplish this. You can simply use black & white wireframes and add them to a basic clickable prototype tool like Invision, Marvel, or simply create it in a more dynamic wireframe tool like Axure. The tool(s) of choice does not matter. What does matter is the ability for you, the designer, to be able to go through your designs as your users would. This is where you really start to become aware of how your design actually “feels” when things are in motion and in action, and there is intent or a user-scenario in question. A simulation with basic hot spots and static screens can reveal user experience details not conveyed in static adjacent art boards.
I’m still surprised at how many times some of my design concepts felt so right in the source design file/tool, because I only saw them as the adjacent static art boards that they were. Even with my years of expertise, experience, adhering to patterns and guidelines, referencing site and experience maps, sometimes those designs just did not “feel” right once I experienced them in context. This is something that I not only practice myself and have seen dramatic results in usability, but I have also had fellow team members be awaken once they saw their designs in more context. We all realized that although the ideas “looked good on paper,” sometimes they were not the correct direction for the actual desired user experience.