ProtoPie: the gap between prototype and final product is narrowing
A year ago I came across an atypical tool: ProtoPie. Since then, I’ve kept it in the back of my mind without actually taking action. It took me an email announcing a business model pivot (single purchase to monthly subscription) to decide to buy a license. As soon as I put my hands on the tool, I gave myself half an hour each day to play with it and I shared what I learned in daily posts on Linkedin. During weekends, I sometimes used what I had learned during the week to make a prototype to show a concrete use case. During this beautiful discovery, I took a few notes, made an opinion on what was good, what could be improved and I decided to share all this with you in the article you are currently reading. Without further ado, let’s get started!
A PROTOTYPE
What is a Prototype?
So that we have a common reference, let’s define the word “prototype”. According to Wikipedia, here is the definition of the word prototype:
an original model that has all the technical qualities and all the operating characteristics of a new product. (…), but it is also sometimes an incomplete (and not final) copy of what a product could be (possibly of software type, or of “service”.
Note: this definition has been taken from the French version and translated to English.
In this definition, we can identify 2 types of prototypes: high fidelity prototypes (those which emulate all the characteristics of a product) and low fidelity prototypes (those which are an incomplete example of what a product could be). The difference between ProtoPie and the most widely used tools today lies precisely there.
Strengths of the most popular tools
If you are interested in ProtoPie, there is a good chance you have already made one (or more) prototypes using one of the well-known tools on the market (Sketch, Figma, Adobe XD, Invision Studio, Principle, Axure, …). These tools have the considerable advantage of being relatively simple to use, being more widespread (therefore more practical for collaborating), and of even having a free version for some of them.
Now that we’ve acknowledged their most important benefits, let’s move on to what sets ProtoPie apart from these tools.
PROTO WHAT?
Yeah I know, funny name. “Proto” as in prototype and “Pie” as in apple pie. Let’s stay focus here
A paragraph earlier we differentiated the low fidelity prototypes from those with high fidelity. Now, in the category of high fidelity prototypes, I introduce the concept of dynamism, because Protopie is a tool which makes it possible to create high fidelity prototypes, but which are also dynamic. But what do I mean by “dynamic”? If what differentiates Protopie are dynamic prototypes, the other tools make “static” prototypes then? What is a static prototype anyway? Well, let me explain.
What is a Static prototype?
By static, I want to describe any prototype which is scripted to the millisecond and which doesn’t leave the possibility to the person testing it to influence this script. Even if its owner creates a script with several branches, these branches will be isolated from each other. The result will remain the same: a prototype with a predictable end down to the pixel and the word. What is possible to emulate with this type of prototype is more limited.
What is a Dynamic prototype?
A dynamic prototype is a prototype which certainly has a script (in order to tell a story), but which lets the person testing it influence this script in different ways. This type of prototype has the potential to emulate with great fidelity what a finished product would feel like both visually and functionally.
How can ProtoPie create dynamic prototypes?
ProtoPie makes it possible to create dynamic prototypes using:
- Text Input: it’s possible to use text fields with which the user can really interact and fill using the native keyboard of their smartphone or computer.
- Formulas: instead of giving a fixed value to the x position of an object, you can use a formula. Example: position x of my square = position x of my status bar +100. Each time the status bar moves, the square will move to always be 100 pixels away from the latter.
- Variables: a variable can be associated with a field to change its value over time. Example: when the user clicks on “add to cart”, add 100 to my variable (and therefore to my named field) “Total”
- Conditions: it can trigger consequences when certain prerequisites are met. Example: When/If opacity of the layer named “square” = 0, then change the color of my status bar.
- Smartphone sensors: with ProtoPie, you can use your smartphone’s sensors: proximity sensor, vibrator, gyroscope, camera, microphone, 3D touch, … in your prototypes.
When you combine all these possibilities, you quickly end up with something that comes close to an application that actually runs on your smartphone or computer.
EXAMPLES
Better show than tell, so I will show you examples of dynamic prototypes that I made with ProtoPie by taking advantage of these features. This article is not a tutorial, I will not dwell on how I made those prototypes. The purpose of this article is just to show you what you can do with ProtoPie so you can judge whether the tool would be useful in your workflow or not.
So here are some examples of things I could do with it:
1. Upload
Concept: This prototype is a concept of a file upload page.
Feature tested: This prototype tests the conditional trigger of ProtoPie.
Video :
How: If the word file is pulled beyond a certain distance (25Opx), launch upload, and offset the other files to fill the void created. If the user drops the file when the position of the word file is lower than this value, the file returns to its initial position.
Note: Even if I only planned the case where the word file would be uploaded, you will note that the prototype is still running even if the user decides to interact with another file, regardless of the order.
Link: You can play with the prototype by following this link -> https://cloud.protopie.io/p/qj1Co3ZZU1/2?ui=true&mockup=true&touchHint=true&scaleToFit=true&cursorType=touch
2. Netflix Assistant
Concept: This prototype is a concept of an app I called “Netflix Assistant”. This app would suggest series and movies to undecided Netflix users, by taking into account their tastes (based on their likes in the Netflix app), and the free time they have ( by logging into their calendar).
Feature tested: This prototype tests the “text input” and the variables.
Video:
How: The text layer displaying the user’s first name is associated with a variable that will look for the content the user has previously entered in the text input which asked for his first name.
No matter what the user enters as their first name, not only will these characters be displayed in the text layer immediately after, but it will be possible at any time during the journey, to recall this variable and to display the first name of the user on any screen.
Note: Again, we notice here that each element is independent and has its own timeline per se. Regardless of when the user interacts with the text input, the image that moves in the background (from right to left) is not affected.
Link: You can play with the prototype by following this link -> https://cloud.protopie.io/p/88BFEy93ege/1?ui=true&mockup=true&touchHint=true&scaleToFit=true&cursorType=touch
3. Chili’s Restaurant
Concept: This prototype is a concept of a restaurant’s order funnel. The user chooses dishes, delivery time and his order is confirmed.
Feature tested: This prototype tests variables and formulas
Video:
Comment: This prototype can appear to be complex because a few things happening at the same time, but let’s observe one thing at a time, and we will quickly see that it’s not so complex:
- The layer of text displaying the total is associated with a variable named “total”
- Each time the user adds or removes a dish from the basket, this action sequence is triggered:
- a formula makes it possible to add or remove the price of the dish from/to the “total” variable
- the “add to cart” button disappears to make way for the “remove from cart” button or vice versa
Note: You can have fun adding and removing dishes from the cart in a completely random order, the prototype is still running well. This is something that cannot be done in the most popular prototyping tools. And this not only because of the total which is calculated dynamically, but also because of the freedom of the user to add and remove the dishes in any order he/she wants to.
Link: You can play with the prototype by following this link -> https://cloud.protopie.io/p/VyP4F4agiih/2?ui=true&mockup=true&touchHint=true&scaleToFit=true&cursorType=touch
PROTOPIE IS ALSO…
All I have just listed is only an outline of what it is possible to do with ProtoPie. The software also allows you to do:
- Cross-Devices prototypes: to emulate an interaction between 2 devices. Examples: a messaging app, an email reception on a desktop following a purchase on a mobile app, …
- Components: to avoid recreating all of your interactions. What is interesting to know here is that unlike Principle, for example, the information contained in the component is indeed the interaction (a chain of states triggered by an action on the part of the user) and not just a state. So when you drag your Tab component for example on a screen, you will only have to change the name of the tabs, you will not have to redo the functional side of the tabs (move the bar when the user touches one of the tabs).
- Etc …
WHO SHOULD BE INTERESTED?
First of all, the curious ones who like to play with everything, push the limits, have fun because they are passionate, and because why not.
Then there are those who feel that the software they currently have access to doesn’t allow them to give life to some of their ideas in the most faithful or realistic way possible, but don’t want to learn to code.
Finally, I would say all those who don’t see themselves in the first 2 groups. For the simple reason that ProtoPie allows you to do everything you can do with the most popular software, but it allows you to do it faster and more simply.
Example: To give life to a 3-item tab in a software like Principle or XD, you need to create 3 screens (1 screen per item) and move the indicator (the bar that shows which item in the tab bar the user selected) on each screen. If you want to add a 4th item to this tab, you will have to go back to all the screens to update them.
In Protopie, it would suffice to use a formula telling the indicator to place himself in the same “x” position as the item touched by the user.
I am part of the first 2 groups, and I think it will be very useful for me in creating prototypes to conduct my user tests. Who says prototype resembling and reacting like a finished product, says: more guarantee that the user won’t be disturbed by a limitation of the prototype during a user test and therefore that his behavior will be as “natural” as possible. I’ve already paired it with Lookback and done some quick tests, and it looks like it’s going well, even when my prototype contained heavy animations.
SUMMARY AND PROJECTION
Today
I am not saying the software is perfect, of course it is perfectible, like everything made by humans.
For example, before, when we shared a desktop prototype with a user, he/she couldn’t see the prototype in full screen. He/She was exposed to information that he/she didn’t need to see and that could distract him/her. This is something that the team fixed few months ago now.
Today, the components that we create are limited to the document in which they are created. But the team’s roadmap shows that they are working on a component library feature. The team is attentive and so reactive, I hope this product will have a future that meets its potential.
Imagine tomorrow …
Using ProtoPie, I saw a bright future … close your eyes for a moment … no, actually don’t close your eyes, you won’t be able to read this article otherwise, but close an eye and imagine …
A future where we could connect a Design System (housed in Figma, Sketch, …) to ProtoPie, to create an interactive library of components present in this Design System. Thus far, when we prototyped we had to choose or find a compromise between speed (time needed to create a prototype) and fidelity (the point to which we want the prototype to approach the original idea). In such a future, we would have two advantages: speed and fidelity. We would make high-fidelity prototypes, faster and more simply than today.
Now that I have you dreaming too, imagine that in your Design System, you change any property (color, style, …) of a certain component and that this component is updated directly in your ProtoPie library without impacting the interaction that you have already created …
I hope that like me, your face lit up and you smiled.
I did my best to reduce this article but it is still a bit long. Thank you for sticking to the end.
If you liked it, chances are that someone in your network might like it. Don’t hesitate to leave me feedback (applause or comment) and share it with your co-workers and friends.
Looking forward,
Colbys Dovi
