UXPin vs Figma: Comparing Two Great UX Design Tools
UXPin and Figma are two popular collaborative design tools seeking to revolutionize how software design gets done in a modern, cloud-first, team-based world. We’ve come a long way since the year 2000 when Visio, Omnigraffle and Illustrator ruled the roost.
In this article, I’ll compare my experiences using both tools and dive a little more deeply into how UXPin allows us to revolutionize how our small UX team works with our product colleagues while improving overall quality.
Some Context
Last year, the small three-person UX Design team in PayPal’s internal technology solutions group (“TPX”) standardized on UXPin for creating rich, high fidelity prototypes for a new high priority Developer Console project, as well as for other proprietary enterprise tools for internal use.
At the same time, our engineering colleagues standardized on Microsoft’s Fluent web library for UI controls, such as buttons, checkboxes and panels. Fortunately, it was straightforward to skin the Microsoft Fluent controls with the PayPal brand colors, and we figured out how to integrate a third-party icon library supplemented with our own proprietary fintech icons.
UXPin recently launched a new feature that they call “Merge”: the ability to import live React-based UI controls from any Github repo. The name refers to merging these two previously separate workflows: design and development. What it effectively means is that designers can now create richer, higher fidelity prototypes within UXPin with no coding. And because these are the same UI controls used for development, less design documentation is needed as the UI controls have already been engineered to be the “source of truth” with regards to styling, icons, etc.
Thanks to Merge, UXPin has dramatically accelerated our group’s product design velocity while giving product teams the power to easily create their own beautiful high fidelity prototypes consistent with our Developer Console standards.
Due Diligence
Figma is one of UXPin’s competitors and I was keen to learn more about this tool that has become so popular. So for my own personal due diligence, I decided to create the same single-page reporting prototype in both UXPin and Figma. The exercise took 60 min. in Figma — and just 8 min. in UXPin.
In addition, the quality of execution was higher and number of errors was lower for the UXPin prototype. Best of all, because the UXPin prototype was built with live Microsoft Fluent controls, the drop-downs, calendar buttons, and data table controls were interactive, and the pie chart was a live Highcharts chart. By contrast, the Figma mockup was a single rasterized image with no interactivity, and required a high degree of experience and knowledge to correctly apply the text and control sizing, colors, typography, and padding. In addition, despite my best efforts, the finished product in Figma had more design errors.
A Modern Design Approach
Both UXPin and Figma are web-based tools offering many benefits over commonly used legacy apps in the software design project lifecycle, including Balsamiq, Sketch, and even PowerPoint in addition to the aforementioned Visio, Omnigraffle and Illustrator. Still in use by many, the legacy tools are apps downloaded to a Mac or PC, optimized for use by a single designer, poorly support team collaboration if at all, and inadequately communicate the intended user interactions, such as clicking a button to see a popup dialog or different states in a workflow.
As both UXPin and Figma are browser based, both tools allow a designer to create interactive mockups for web, mobile, and desktop apps directly, alone or collaboratively in real-time with others. Both tools make it easy to share design concepts with prospective end users and stakeholders such as product managers, developers, and marketing colleagues in order to get feedback for improving the product. Further, engineering colleagues can view advanced technical specs within the design itself to help minimize development errors. These advancements alone significantly improve the design experience itself, the velocity of design, and the overall quality of the end product.
Despite their similarities, UXPin and Figma have different philosophical underpinnings which affect how their tools have developed, their capabilities, and their relative strengths.
Designing with Figma
Figma’s approach appears to be intended as a web-based evolution of familiar graphic design tools, such as Sketch. In the design editor, the user creates screens that are akin to artboards. A single “file” can have multiple screens, and it’s easy to create linkages between them so that in prototype mode, the user can easily move between them. The designer can also easily add text, images, boxes and other shapes to a canvas, style them, and use them to simulate the contents on an app screen. In addition, Figma offers a fantastic built-in tool for creating Bezier curves, useful for creating custom illustrations and animation paths.
To view a prototype, the designer presses a Play button and a new window is displayed. The user sees a realistic-looking simulated app screen, can click on graphics that look like buttons to view dialogs or move to another screen, and can even scroll down longer screens. Further, collaborators can leave comments, and engineering colleagues can view technical specs, including color Hex values, sizing, and padding.
As much as Figma is an improvement over legacy tools, it has some limitations. For example, each design appears to be rasterized, that is, converted to an image. This means that text is actually rendered as a picture of text, and is no longer selectable. “Buttons” are simple graphics that look like a button but don’t act like one, so there are no mouse hover effects.
An important limitation is that, just like legacy tools, Figma also renders input controls as rasterized graphics rather than live interactive controls. This means that a text field is a picture of a textfield, not something that a user could click in and type into. Similarly because a checkbox is a picture of a checkbox, to simulate a user checking it in the design, the designer has to duplicate the entire screen and switch between two screens on click. The only difference between the two being that one screen shows the box as checked, the other shows it as unchecked.
Ultimately, this means that the designer must think carefully about what exact path they want a user to take through a design concept and create screen variations to support key interactions like clicking on a Terms and Conditions agreement to enable a “Create Account” button, all while tediously tracking what text is on each screen so as to keep them all in sync when any wording changes occur.
In summary, while Figma offers many advantages over legacy tools, in the end it is an evolutionary step beyond tools like Sketch and Balsamiq. Figma-based designers must still create many variants of the same screen to simulate state changes of interactive controls like dropdowns, radio groups, and checkboxes, while hover and focus states for buttons and textfields are unsupported.
Designing with UXPin
By contrast, UXPin changes the game by going beyond “mockup” to “interactive prototype” with their HTML-native approach. While a skilled designer could mockup the same screen in both Figma and UXPin with pixel-perfect results, the Figma mockup would be rendered as a rasterized graphic with maybe some hotspots to switch screens, while UXPin would display it as a collection of live HTML-based objects: a textfield can be clicked in, displaying focus effects, and which the user can type into it; a checkbox can be checked and unchecked; a combobox can display a list of selectable items; and displaying actual text that can be selected and copied.
UXPin’s powerful support for states, scripting and variables create the opportunity for complex user interactions all on the same page, with minimal learning curve for the designer. For example, a simple use of scripting is to change the state of a button control on mouseover from the “enabled base” to “hovered” state. A scenario for an intermediate level of scripting would be that when the user checks the Terms and Conditions checkbox, the “Create Account” button’s state is also changed from the “disabled” to “enabled base” state. And because variables are accessible across a prototype, if the user types their name into a text field on an account creation form, such as “Jessica,” the designer can easily pull that text value out at runtime, store it in a variable, and greet her on the account home page with a “Welcome, Jessica!”
We had estimated that there would be a productivity improvement in UXPin, so I decided to do a little experiment by creating the same reporting experience in both tools with the same overall design. It took me exactly one hour to create the page in Figma, facilitated by familiarity with the PayPal color palette and typography requirements, UI control sizing estimates, and the Google Material UI icon collection. Even so, there were a few errors in text sizing, padding, and color application.
The same design took 8 minutes to design in UXPin thanks to using the live Microsoft Fluent UI controls for the prototype — less than 1/6th of the time it took in Figma. There were no errors in colors or sizing because the controls are using the current PayPal-based theme and our icon library. I made one padding error that was easily fixed. Further, the UXPin prototype had live dropdowns, calendar buttons, a sortable data table, and even an interactive Highcharts pie chart!
In Conclusion
I liked Figma a lot. It’s a huge improvement over my previous go-to design tool, Balsamiq. But now that I’ve learned how to leverage the powerful scripting capabilities of UXPin and design interactive UIs with the same live HTML UI controls that my engineering colleagues will use in the finished product, there’s no way I could go back.
