Prototyping with Figma and Adobe XD
May 14, 2019
I’ve been going back and forth between using Adobe XD and Figma.com for my UX layout mock-ups. The process needs to be fast, the results easy to share, and the cost of future changes needs to be cheap. It’s been a close race between the two leading options.
Long Live Adobe
I’ve been an Adobe customer for a very long time. Looking back, I remember installing it on an early Macintosh in the mid-1990s from a rubber band-bound stack of beige diskettes. Over the years, the application has seen slow improvement. I dug up a screenshot of version 4.0 — it’s amazing to see just how well those original developers nailed the application layout and functionality right out of the gate.
From Photoshop, I soon branched out into Illustrator, Premiere, After Effects, and a host of other design apps. I’ve grown up with these tools, so they’ve shaped the way that I think about design. While earlier generations had their rudimentary compasses and rulers to aid their drafts, my generation grew up with the Bezier Curve tool under the direction of the smart guide.
XD is a brand new tool out of the Adobe Creative Suite package for the next generation of software designers, with a distinctly different feel from its Photoshop/Illustrator heritage. The app is lighter and faster than anything else the company has released to date, providing a playground for the meta-design period of software development — that brief early planning phase when the archicture and organization of frontend components are still pliable. The decisions made at this stage in the game ripple throughout the entire build process, so it’s crucial to have a tool set that can translate artistic passion into incredible prototypes.
What makes XD so fast is that it seems to apply predictive pattern recognition in all the right places. When an edge is near another logical edge, suggested alignment options instantly drop onto the screen with pixel counts just where you need them to achieve pixel-accurate layout continuity. It spots repetition to hand you the tools you may require before you have to ask.
The nested item groupings seem to work better than any previous full-canvas layering implementations — you select a few items, tap the group button, and you’re looking at a shiny new modular component block. It’s a really cool way to work.
When you want to select an inner element within the component, a few clicks seems to be enough to tell the application exactly which element to bring forth. It’s smart-select, fully-evolved.
If you’ve already bought into Creative Suite, you get XD at no additional cost, so it’s almost like free software for existing subscribers.
So, why use something else?
Figma is extremely similar to XD, but it’s provided as a web app (although, you can download a desktop wrapper). While this initially turned me away, it hasn’t bugged me very much in practice. There’s no software to download up front, so sharing editable designs is a snap.
Peaking under the source code into the Figma renderer, it looks like the screen is being drawn with a canvas element, operating primarily by absolute positioning. I’m curious how things might have unfolded if we were working with the actual 1:1 CSS-driven DOM elements.
Overall, Figma seems to be better positioned for collaborative editing — although, let’s not kid ourselves… how often do we actually need multiple editors on the screen messing with our layouts all at once, adding random comments directly onto our designs? Beyond git-level document collaboration and screen-sharing, it’s rare that I find myself needing a way to host simultaneous multi-cursor document editing. When was the last time you were in Photoshop and thought “this sure would be more productive if someone else was able to draw on my screen while I’m in the middle of working”?
Since Figma is web-based, tweeting a layout to the masses is easy peasy. From a share link, you’re never more than a tab away from publishing a design. And shamelessly, that’s helped give it the upper hand in market adoption. While I can link to a cloud-hosted XD document quickly, if anyone wants to make a change, they’ve essentially got to sign up for an Adobe account, fill out a form, and install the behemoth that is Adobe Creative Suite — ain’t nobody got time for that.
Both XD and Figma have a rapid update sprint cycle, so the user experience of working within the app is under constant improvement. Just last month, the Figma team updated the vertical type alignment mechanism for the better: https://www.figma.com/blog/line-height-changes/ A couple of weeks after that, they improved the way items fill in gaps on a grid listing. Then, last week, they added new vector angle snap points. XD’s updates list is just as impressive.
Like XD, more often than not, the application seems to have a strong intuition about the relationships between objects on the screen, such that it’s able to make accurate suggestions to speed up new additions and changes. UX framing lends itself particularly well to this workflow, as the atomic design unit is just a simple box — you’re generally working with 4 sides that stretch and contract along 2 axes, with gaps inside and outside the boxes.
We hope that Figma will do the right thing more often than before and allow you to make decisions more quickly as a designer (and understand those decisions better as an engineer).
A great place to start, but a long way from the finish
Once you try to incorporate full UI responsiveness and reactive data population, however, neither of these tools seems to be quite up to the task. Seeing as this is among the most important aspects of prototyping, it’s a huge oversight to not have this functionality out in front, working as it should.
In the provided example layouts, you’ll often see something like a Desktop layout sitting beside a Tablet layout — as if we know the exact quantized sizes of the two devices that will render our content, and we want a separate sketch for each one. The text-framing is applied backwards in both applications, with the child elements listening to their parents while sibling interaction is completely ignored.
While we are able to quickly sketch the basic outlines of our layouts within these constraints, we’re not able to fully explore the adaptive qualities of their components. So, the accuracy, flexibility, and complexity of our UI prototyping with these tools is limited at this time.
Perhaps in an ideal world, we would begin our implementation with something like a highly-dynamic scaffolding with a prime focus on modular adaptability and manageable entropy. We would then “Save For Web/Native” the design and overlay our functional device-agnostic logic directly over this skeleton. Then, we would provide our apps with a beautiful UI and interchangeable themeable exterior.
For now, it doesn’t quite work like that.
Currently, the process begins with a sketch in Figma or XD. We render off a rough angle of the project, squint at it, and try to imagine what it could be. We then start a new prototype from the ground up with code and get a feel for how it might actually be constructed if we were to seriously approach the build and deploy to production. And finally, we forge a new scaffold and work our way back out again at a pace of two steps forward, one step back. It’s a messy process, but it’s the current state of prototyping, as I know it.
You can’t go wrong with XD or Figma — these are the best tools available. I’m currently using Figma, for no other reason than the ease of the Share and current popularity. There’s little doubt in my mind however, that XD could take the market lead with some additional export / responsive-design functionality. Imagine if XD played nicely with Google Flutter, and suddenly we were back in Dreamweaver and out of VS Code?
Here’s a copy of the Figma layout prototype used for this current version of the blog. Feel free to edit and remix as you please: https://www.figma.com/file/KIEcpXvvYDBpZsrEKkZ9ziPj/iRyanBell.com?node-id=0%3A1
There’s an interesting competitive balance between better tools and higher ambitions. You experience this each year with aging devices and software performance rot, as feature updates for newer compatible hardware iterations strain the existing capabilities of the previous device. Perhaps as humans, we forever have this reach from the shoulder of giants extended into the future, forever containing within it closer approximations to the world we wish to inhabit, but grasped at the cost of rust left in our wake.