A tale of two tools — UX Pin and Figma
Earlier this week I had the opportunity to dive into UX Pin. The tool has made strides in enterprise domain. Started in 2010, UX Pin has come a long way to a UX prototyping tool that keeps development and design closely tied.
While Figma is a tool I’ve been using since three years, familiar with the changes, updates and features (some of which have been constantly updated throughout, such as Auto-Layout, Components, Variants).
I started out with the assumption that, all design tools are layer based, what could be drastically different between the two. Boy! Was I wrong.
The Differences
- States and Prototyping: The major difference between UX Pin and Figma is adding states to an object.
In Figma, when we define a state such as ‘hover’, ‘disabled’, ‘active’, we have two ways of doing it: Make a component and add variants or Showcase it into the design itself by use of ‘Interactions’ under ‘Prototyping’ section, using ‘On Hover’, ‘On Drag’ etc. Yet in the latter way, there is no way to show a disabled button unless built into component as a variant, or just placed as a separate design element on the requisite artboard.
In UXPin, this is done in a better way. You do not need to make a component in UXPin as you can add states by a button called “Add State” (literally). This button is located on center top of editor window and instantly adds another state, which you can name yourself and then edit its styling.
In Figma, whenever a variant such as ‘hover’ is built into component, an interaction is added by use of the ‘On Hover’ functionality under ‘Interaction’ ( I refer to this as drag and drop of arrows) and it looks like following:
Now whenever someone will use this ‘Frame 1’ component into their design, they can always expect the Button to convert to Hover state when they hover on it.
In UXPin, setting states for elements on the artboard is like writing a code snippet. The three major parts are “Action: Hover”, “Do what on that action: Set State, Set Variable, Change….”, “Change State of: Button” to “State: Base, Hover, Disabled or any other that you have already made into design”. Its so seamless, it almost feels like a game. The best part is that once you copy this button elsewhere, even if it is not a component, the same interactions and states will be carried alongwith the copy. I believe this is not possible in Figma yet, and a component is the best way to do this carry-over in Figma.
2. Expressions: Perhaps the most powerful feature in UX Pin is expressions.
I am going to illustrate ‘Expressions’ with a small example:
Consider that there is an onboarding screen, on which you have to add your name, and then you’ll be welcomed as a user.
In Figma, this is possible in a rough sort of manner using Click Through Prototype, but there can be only one name, whatever the designer writes as an example:
UXPin has revolutionised this aspect.
In the following example, lets say I want to add a number to the ‘Enter Phone Number’ box, UXPin enables me to set a condition where any ‘Change’ to ‘Enter Phone Number’ box can be reflected in ‘Content of the Element’ 000–000–000–000 and can be set to ‘Content of the Element’- ‘Enter Phone Number’ box. By adding a few more conditions, I can set all the constraints, such as the first digit shouldnt be zero, there shoudnt be more than 12 digits. Its very much like the ‘if’, ‘else’ logic, just built into design.
To understand this concept the best, I urge the readers of this article to watch the following video, as it is one of the best explainer videos on UX-Pin:
A case against Expressions: All said and done, I’ve heard a great many designers say they “hate math”, “dont like coding”, “need room for creativity”. And while I love coding and math, I also feel that expressions can potentially limit the creativity and make design process longer. When I am exploring different design possibilities, prototyping should be least of my concerns. But with that weight on the shoulders of designers, I believe this could potentially increase the turn-around time for good designs. During a user interview with another ex-Google UX Designer, I had a feedback that “not all use-cases and constraints need to be communicated to developer via design, it can be added to documentation as well during the handoff”. And I couldnt agree more.
3. Prototyping: I will cover this point briefly due to limit of reading time and technical nature of this article. In summary- there is no bird’s eye view of prototype in UX Pin as there is in Figma (where all the arrow wires can be seen going from one trigger to destination). In UXPin, there are pages, and on one page there can only be one canvas or artboard. So when linking pages, you have to add Page URLs to triggers. And neither there is a bird’s eye wire view. This is a serious limitation on part of UXPin. As the prototype (wire) view has helped me quickly change my trigger and destination without loosing the flow. And I believe this will remain a serious setback for UXPin untill resolved.
Conclusion:
I see UXPin making serious mark in future. I havnt even covered the topic of Design Library comparison in this article as I will do in the next.
UXPin is fun, I like to play around with expressions, it’s a peak for a designer into the code and conditional logic world. Logic world also limits creativity for some designers. Both UXPin and Figma continue to grow by leaps and bounds, and I am excited to explore what both have to offer. Essentially, why use one when you can use both.
