How to improve the experience of working with both tools.
If you are familiar with Figma and learning Protopie for the first time, or if you are familiar with Protopie, but must work in a Figma environment too, then this information is intended to help ease some of the pain.
Figma is the dominant tool for developing visual UI (icons, fonts, colours, screens, screen layout and navigation) and it has some tools for sharing the design as a slightly interactive prototype. Much of the way that Figma works is oriented around the way that a graphic designer might approach such tasks.
Protopie is, in many respects, the reverse tool – it is an experience prototyping tool that provides some tools for smart visual presentation, but it doesn’t even claim to have all the refinements you might need for polished visual design. However, with Protopie you can create prototypes that provide users (and others) with a fluid and dynamic experience (even across different people, places and devices). As such Protopie is oriented towards that experiential bigger picture – how is our product experienced in use? – rather than what does our product look like?
Not which, but when ...
There are many posts about the pros and cons of Protopie versus Figma and vice versa, but they almost all tackle it as a question of ‘which tool should I use?’. Given the cost of each this might be a reasonable question for some, but the real challenge is to know, not which to use, but when to use each.
Furthermore, they are each based on a quite different model of designing a user interface and programming a prototype. Some designers will find themselves drawn to Figma’s animation-based model, where others will prefer Protopie’s dynamic, programming model.
In Figma it is necessary to draw out all your visual assets first, since a prototype is constructed by linking an action in visual asset to the presentation of a different visual asset. For a designer who is used to thinking visually this is very natural and straightforward … and this is fine as long as your primary purpose is documenting all the fine graphic details of a user interface. But if you need to share the behaviour of that interface through a prototype, then there is a growing spaghetti challenge as the behaviour of your prototype gets more complex and a very substantial problem of debugging and refining the behaviour of the prototype.
In Protopie it is much more important to start from the behavior of an element and the nature and relationships between the components in your prototype. Whereas Figma requires you to draw all the visually necessary variants of your interactive piece, Protopie requires that you identify the conceptually necessary elements in your interaction – the visuals of each element will be changed dynamically in response to user interactions.
Thus, for example, a button in Figma might need a hover variant, an active variant, an inactive variant, etc and the designer has to draw what each variant looks like and specify the behaviour that transforms one into the other.
In Protopie one might think of a button as having properties (a label, a surround and a state, for example). In the Protopie model a ‘hover’ is an action which triggers a response, where the response is a change in the properties. A hover effect is achieved by changing the colour (or opacity, or shadow, or rounded corner radius, etc) of the surround. It is the properties of the single surround element that change while the mouse is over the element and not the element itself.
Because Protopie is concerned more with behaviour one can actually build a button with many different changes for hover and turn each of them on or off as needed to explore how the look and feel. In Figma one would have to generate all the variants and wire them together.