Prototyping Retail Experiences in Framer
This is the first part in a series of articles about prototyping in design and focuses primarily on how and when to apply Framer to a project. The next article in this series will focus on how to write efficient Framer code.
I’ve been working at Your Majesty Amsterdam for the better part of the last seven months. During this time, I’ve been working on a retail design project for Samsung SmartThings. Focusing on building interactive prototypes, designing interface flows, usability testing and research.
Samsung SmartThings is a tech company whose mission is to connect your home to the Internet — one smart home-appliance at a time — automating trivial tasks like turning on the lights at home when you arrive, or letting you know if you forgot to close a window before leaving.
We were tasked with designing an interactive experience that would accommodate their new retail marketing initiatives in the US and Europe. After a few days of immersion workshops, we concluded that in order to push for our desired experience, we would have to build a high-fidelity prototype that not only allowed us to communicate the look of such an experience, but the feel, complete with interactions and animation.
Brainstorming the ‘flow’
As with all things great, before anything can be digitally designed, it’s usually a good idea to sketch it out on some kind of paper format, be it a ridiculously large post-it like paper, or a tiny napkin. The best conceptual ideas begin without any type of technology standing in the way.
Guerilla testing navigation ideas
Before diving into designing all the flows, interfaces, sections, components and whatnot, there were a few free floating ideas going around about how we wanted the overall navigation of the application to work.
In the end we were split on two different concepts, calling for two quick interactive prototypes with the intention to test them out internally on co-workers, and ultimately to quickly gauge which concept was the better fit.
The important thing to test here was the navigation style, so the focus was purely on interaction for this exercise, not aesthetics.
This was especially crucial to remember during prototyping where it became immediately apparent to me how easy it is to lose sight of the overarching goal at hand. To combat any inclination to “over-design”, I kept interaction at the forefront of my mind for fear of falling into a deep, dark hole of fine tuning those nitty-gritty design details that didn’t matter all that much to the test.
In addition, over-designing a prototype might lead to biased results when you’re conducting user tests. Users may focus on the visual execution rather than the interaction itself, which was the metric we wanted to test in this case.
This is the first idea we tested. An “elevator” style navigation where the user was presented with a column based interface. They could tap a column to go directly to a specific section, scroll vertically to navigate between sections or swipe horizontally within sections to explore more thoroughly.
The second navigation idea we tested was what we liked to call “The Morpher” internally. It had smooth-morph-like transitions between the different sections of the application (hence, the name). A user would never leave the main view, but instead navigate through expanded categories, with paged views for each section.
The great thing about Framer is that it’s so versatile. It allows you to test ideas with a fairly high level of fidelity, but also low level navigation concepts, like the ones you’ve seen above. Thanks to the built in components that the Framer team created, building out navigation concepts went pretty fast, and allowed me to quickly test two separate ideas to see which was most efficient.
Based on the quick test I ran at the office, six out of eight users preferred the “morphing” navigation structure, as opposed to the “elevator” style navigation. In the end we went with “The Morpher” style navigation for the presentation.
You can see the final prototype we presented to the client here: http://final-st-preso.surge.sh/ (Note: Give it a few moments to load, it’s pretty heavy.) Version 1.0 of this experience is sadly not available online, since it’s an in-store experience and all. Although, if you’re in the U.S you can see it in pretty much any electronics store that sells smart home appliances.
We learned a lot from building this prototype and that same knowledge was readily available during our presentation with Samsung SmartThings. It simply made talking about the interface a whole lot easier. And while presenting static mockups is great, they lack the most important aspect that a real prototype can provide, which is how the product feels. When you let your stakeholders take control, click around and try things out for themselves, great understanding and conversation tend to spark up like never before.
Key takeaways
Figure out what you want to build, before you build it
If you’re going to prototype end-to-end products, make note of the level of fidelity you’re building before you begin to prototype and then figure out what approach to take based on what’s best suited for the situation. In my case, we were building a prototype to communicate the look and feel of the final product to the stakeholders, which meant end-to-end high fidelity interactions.
If you’re using Framer to communicate how interactions should work, and end up using it as a specification for your developers, it’s probably easier for both you and your team to break your sections up into smaller prototypes in order to focus on doing really high-fidelity interactions for smaller sections. This eliminates any anxiety about complexity and abstraction that comes with building high-fidelity, multi-view prototypes with all types of funk. Remember that it’s still a prototype, and not a production grade app you’re building. Fake it till you make it.
It’s really hard in the beginning
Framer is great for a lot of things, but it needs to be applied to the right situations, based on the current constraints of your project. Contextual awareness is essentially the key to harnessing the true power of Framer. As you grow to learn the tool over time, you’ll figure out how to do stuff that looks and feels really great very fast; but there is a very steep learning curve in order to get there, that’s probably going to include some major frustration, hair-pulling and confusion. But I can assure you that if you stick with it, it’ll feel very rewarding once you pass that initial learning curve.
Fortunately Framer has built a great library of resources to assist people that are new to both prototyping and programming in general. Check out the documentation, the resources page and their basic programming guide to get started.
Stay tuned for Part 2, and follow me to get notified when it’s released! In future articles, I’ll discuss more advanced Framer capabilities like Classes, Loops and Arrays, and how you can leverage object oriented programming techniques to create high fidelity prototypes, faster than you might think.
