I championed the rollout of Figma at my company and what this article mentions is true: this is a tool for design, not just for designers.
We initially thought we'd need to provision the same number of licenses as we did for Sketch/InVision/Abstract. Turns out way more people started to get involved in the design process and we now have a more inclusive design practice. Content strategists, UX developers, researchers, can all participate early and often. (From a revenue perspective that's a pretty convenient thing for Figma, as each editor costs $45/mo — not only are they eating market shares from the existing pie, but they are also making that pie bigger)
This post encapsulates why Figma is winning, because there are thousands of teams doing this work dealing with the headaches of having design spread across multiple expensive tools. Figma just does it better.
Meh. Everybody knew that "design is not just for designers" for quite a while, Adobe made several failed attempts at "collaboration" workflows trying to solve exactly those kinds of problems. This is just post-hoc justification... and also, let's not jump ahead of ourselves, "Figma wins" is not a foregone conclusion. A few years ago it would've been "why Sketch wins".
I wish Figma would add page formatting and links so that it could be used as a wiki also. Figma is on a much better track to make a good product than Notion.
I think many people don't get why Axure is still popular is because they don't design for enterprise software. Sometimes it is just much easier to create table as a table and not as a bunch of vertical and horizontal lines like you will have to do in most of design software.
Figma is a great piece of engineering, but I'm sticking with Sketch for personal use since it checks all of my boxes.
I've been watching it though, because I'm curious to see if they'll ever switch away from Electron for their desktop app. As far as I can tell, it doesn't need much from the browser other than a canvas. A lightweight standalone webassembly+canvas runtime would probably be enough to run it with some tweaks and could net significant performance/efficiency improvements (especially if said runtime leveraged Vulkan, Metal, etc). If they do that, it'll grab my attention and may kick off a new way to build cross-platform high-performance desktop apps.
Just curious to know what those boxes are that Sketch checks for you.
Right now, Sketch seems to be the prevailing product in the overall design community. But in my opinion it's only because it was the first to really get such a strong hold on its niche, and a new product will take its place at the top soon.
What turns me off to it as a person who missed its initial spread is that the vanilla Sketch experience leaves a lot to be desired. It's cool that it supports plugins to extend its functionality, but I don't like how it's expected that you just have to get a bunch of plugins to reach parity with the vanilla features of its competitors. (The Mac only support is also a negative too, but it's not that big of a deal for me.)
I don't use many plugins. I mostly just need a reasonably capable, digital-first vector canvas to work on, and Sketch does that very well.
It also helps that it's pretty easy on resources — when I first picked it up, my daily driver was a Core 2 Duo MacBook with 4GB of RAM, so back then efficiency was very important. These days I have access to much more powerful machines, but it's still nice that it can sit in the background with large projects open without impacting a browser with dozens of open tabs and mammoth apps like Xcode and Android studio.
So for now, there's just not enough to gain from investing time and effort into moving over to Figma.
Figma can be shared with a link and has no version control. Multiple designers can work in the canvass without having to worry if everyone is working form the same version. To me, these were the advantages that got us to switch from Sketch to Figma.
Figma can be shared with a link and has no version control.
This is great for quick, informal design work, like prototyping with participants who aren't specialists.
It's a double-edged sword, though. There are good reasons that professional creative workflows often include revision control and sign-off processes attached to distributing specific revisions outside of the internal team.
Exactly this, since designs are part of requirements, if they can be changed without the knowledge of all involved parties they can become a moving goal post and source of misunderstandings
Comparing pricing directly, looks like Sketch is cheaper, if company already uses Macs. But how does it compare in reality? Do developers need additional Figma licences, or can designers just share designs with them to inspect?
Pure “viewer” licenses are free on figma. You only pay per editor.
And IMHO the price delta between sketch and figma is basically a rounding error on the wage cost of your designers, so it’s barely even worth thinking about.
Figma sounds like a great tool, but it feels overhyped to me - especially in this article.
This reads like a long-winded pitch to a Figma investor more than an honest review.
I’ve been wanting to try it out but this article was a little bit of a turn off because it is so enthusiastic. Every tool has strengths and weaknesses so an article like this makes me wonder, what are the trade offs?
I'm a developer who has to dip into design files every now and then, so maybe my opinion isn't the most reliable. But I just don't really see a huge difference between Sketch and Figma. The major difference is that you can design online (which is admittedly a very big diff). But the UI itself doesn't really seem to set itself apart that much.
Can anyone here lay out a few major differences that I might be missing?
At a high level, that's about it, and it is huge. Sketch is macOS only. Hell, this page comes up when you google "sketch for <not macos>": https://www.figma.com/sketch-alternative/
I recently came across a Windows-only app called Lunacy which offers Sketch file import and editing for Windows users (I haven't tried the app).
The published Sketch file specification [1] is what allows Figma and Adobe XD (and Lunacy) to import Sketch files. Ironically, neither Figma or Adobe XD publish their file formats.
I think where Figma is pulling ahead of Sketch (in terms of usage behaviour) is that it is being used by more than just designers. In fact, Figma is beginning to encroach (possibly unintentionally) on digital whiteboard tools like Miro and Mural.
Figma approaches design from an engineer's perspective. They have features like auto layout [0], swapping elements in a list, scaling multiple elements at once while preserving each aspect ratio, and so on.
Can you imagine that if designers before this wanted to move an element in a list, they would have to move every single one instead of having some drag and drop swap functionality? That if they wanted to dynamically change a button size for the text inside it, like we can do easily on the web, they simply couldn't?
Basically, Figma is turning design more into something like front-end development, doing things in a design program that engineers could do normally with code. This is because the developers of Figma are themselves coders rather than designers, so they know what real ease of use should look like (ironically). This is the fundamental corporate culture shift that is the difference between Figma and others like Sketch.
Of course, you could go all the way and simply turn the design software into a web/mobile development framework, which is what software like Framer [1] does, which is literally a design software built on React, and it can spit out React code for you once you're done designing.
adobe, microsoft, et al. also faked the fix and incorrectly fixed it by exporting into other formats in a broken way. locking in makes sense from a VC point of view.
from my point of view the only way to guarantee is to use software that provides open file formats and develops their features around those open formats. inkscape and sketch seem to be doing this
That's not going to work. People will take features over unknown future uncertainty. Users just have to realize the past mistakes of other companies and pressure the developers to open the format.
"design online" is the key but not so much that the software runs in the browser, more that it allows for a different workflow.
Multiple people can be working on the same thing at the same time and anyone can view the in progress work. This changes the traditional file based workflow where designers pass a file back and forth if they want to keep the work together - often working in a separate file then "merging" the work into a master file one at a time.
Because all the files are online it's possible to see who is working on what including at the very moment. Its really easy for me to get a sense of what other designers are working on and whats been updated recently.
A huge bonus beyond designer collaboration is the way Figma breaks the previous separation of working file and final export. Non-designers can check in on an in-progress file at any time without needing a designer to export some static version of it. This allows designers to work on related things in the same file but each "thing" can be in at various stages of completion without having a negative impact on delivering final work. This is also great for transparency.
Ya but you're probably taking certain things for granted that the author is not. The author thinks Figma really is amazing because it enables what they called "loop stacking" in the article. For programmers this is no big deal, programmers work with dynamic workflows and loops all the time. So if you're a programmer then I can see why you'd think it's overhyped but for most people it really is an amazing tool because it's an improvement over what they're used to.
I'm not a designer so I don't know how good it is and I only skimmed the article but the high level concepts in the article around managing design workflows make sense, e.g.
> Figma solved this problem. Designs in Figma are not just stored in the cloud; they are edited in the cloud, too. This means that Figma users are always working on the same design. With Dropbox, this isn’t true. The files may be stored in the cloud, but the editing happens locally—imagine the difference between sharing Word files in Dropbox vs. editing in Google Docs.
It sounds like Figma reduces friction in the collaboration process by clever use of cloud based and browser coordination. It's not innovative but it's a good application of existing technology to the design space.
> It sounds like Figma reduces friction in the collaboration process by clever use of cloud based and browser coordination. It's not innovative but it's a good application of existing technology to the design space.
Out of curiosity, what do you consider innovative?
Good question. Do you have a definition we can work with? I tend to focus on theoretical innovations like mathematical theories so my definition is often at odds with what most people think is innovative.
Often innovation is in the eye of the beholder, for a clerk that's been manually entering data for years it might be innovative that it can be replaced with digitalization but for most researchers that's just "implementation" of existing tech.
I don't hold opinions on what the word should mean, just curious to find all the different meanings of it
Yeah I’m a programmer, so I think you could be right. I’d like to work with our designer using figma and get her thoughts / opinions to get a better understanding.
Also, because I’m a programmer, I’ve lived through many tech hype cycles (with mostly open source and developer tools). So over time I’ve become sensitive to this kind of rhetoric. That’s why my initial reaction was skepticism.
Definitely, I'm not affiliated to Sketch but there are a few things on the article that are outdated. Through Sketch Cloud you can actually handle commenting, clickable prototypes and assets for the front-end team (avoiding using Zeplin and Invision). The plugin ecosystem is really strong on Sketch as well, and they are also rolling out collaborative editing this year.
My main issue with Adobe XD and I believe this is an issue with Figma as well is the fact that there is no versioning on shared designs. We found ourselves in this situation with Adobe XD a few times where the designs were delivered to the developer and after part of the implementation was done the designer pushed changes which made the implementation look as if it was no longer following the approved UI. I looked at Figma as an alternative but it seems to have the same issue unless this has changed. Can anyone confirm?
Not a comment about Figma really, but it has unfortunately become a trigger word for me. These are my observations from working with tech startup companies as a software engineer.
Software solutions will never fix problems that are caused by people.
Sketch, Figma, whatever the next design tool is. Google Docs, Quip, Notion. Trello, Pivotal Tracker, GitHub/ZenHub, Jira. I've gone through tool-switching fatigue with all of the above. Sometimes it doesn't matter much, other times it bogs us down with metawork for months as you figure out which features you gained, and more importantly, lost.
Back to design. I have seen design die the same way every time. Product misuses design resources, effectively making them contractors that hammer out one-off pieces of work. Those pieces of work get nitpicked by some vocal minority holding a lot of clout, until the end result violates the framework that the designer created.
This frustrates everyone over time.
Designers are frustrated because the systems they built are ignored.
Engineers are frustrated because they are adding new debt with every designed feature that has to rebuild parts of the world to make exceptions to systems work.
Product is frustrated because they just don't get why things are slow after they delivered a clear design to the engineers.
Let it all build up and people will start leaving your company.
So yes, use Figma if it suites your company well. If you're reaching for it because your team is frustrated, maybe consider digging into that more before you swap out yet another piece of software for all the wrong reasons.
I have my own "perfect world" solution that I can shed some light on, sure. It's built to address the concerns that I myself have observed, so it might not apply to all. Never just blindly follow the advice of a stranger on the internet :)
Stop wasting time with high fidelity mocks. Engineers shouldn't need a picture perfect rendering of what product wants in order to implement it. The end result almost never ends up being an exact replication anyway for "reasons".
Start doing both of these in parallel:
1. Free up design to build systems that can be used to solve problems. Have them work closely with engineering to ensure the vision will carry ALL the way through to implementation
2. Lean very heavily on low fidelity mocks to hash out the SHAPE of changes to product (inspired by Basecamp https://basecamp.com/shapeup/1.1-chapter-02)
To use object oriented programming as an example, a design system is used in the concrete implementation of the abstract shape of the product requirement. When something doesn't fit into an existing abstraction, you refactor instead of fork.
Amen. I have similar experiences working with designers and PMs and this is my ideal as well.
Designers don’t know the software architectural constraints and what is easy to code up and what is not. Engineers do. PMs know what trade offs they want to make in fidelity for the product, but designers and engineers don’t. What you often end up with is designers spending a lot of time creating designs they think solve the problem, but miss out on a lot of edge cases. They and PM discuss the product design and hand it over to engineers as if their work is done. When the engineer goes to implement it, they find all those edge cases that were missed and the designer has to go and redo a bunch of stuff while engineering is blocked on some of those decisions and PM is concerned why it’s so hard to implement as is.
> Designers are frustrated because the systems they built are ignored.
Designer here. My experience has been that Figma has done the opposite. It's created a lot of consistency with shared component libraries and standardized type / color styles. Also, the fact that engineers can jump into Figma and inspect CSS has been immensely helpful.
In the design world, Figma is like the equivalent of getting a robust IDE with syntax highlighting, code completion, compilation, and debugging. It's replaced multiple tools and connected people in a way that's never been possible.
In your experience, do you know if engineers implement the shared component libraries as such in the actual applications? This would be as opposed to engineers directly implementing the end result of work in Figma (Sketch, etc.) that utilizes said components. There is a big difference there, and I'm always curious to have more data points about how this actually happens at other organizations.
Yeah that is the exact result I have observed before as well. I'm really curious to hear more examples about how this actually works out well in the end from others.
I recognize that my view of this is from the bottom up in terms of only really having worked for SV startups, but I want to learn more and see if I can't make it work a bit differently this time.
Ditto, we have a quite a few designers and they mostly seem to struggle with thinking in components. They use design system like a color guide, and we keep reimplementing patterns on many pages.
Some do, sometimes relying on things like Storybook.js to do QA in the middle. There's more and more things to maintain consistency between Figma design and e.g. React components being built.
From the developer perspective I never felt the inspect CSS gets me much over the design documents that I got in the past, that included the systems definitions and rules to follow. To be honest, I prefer the latter and find a lot of the "modern", interactive tools fiddly and ineffective to use (e.g the generated css giving me a html code instead of a variable name even if its a defined design color).
That said, I never felt implementing a design once is the hard part, but keeping them maintained and in sync. What are things that worked for you in that regard?
E.g. as an engineer, how do I quicky figure out what I need to adapt when a design has changed? I quickly looked at Figma, and while there is a version history, it just seems to switch completly between versions without anymore detail. So I'm bound to miss changes and completly am reliant on the designer annotating manually.
I love getting figma files as mocks for things i need to implement. I love grabbing CSS from the figma, and I love that the design system allows the designer to not only export CSS, but export it in a way that has annotations (all the colors I get from my designers are annotated with "brand red 300 weight" as a comment, so I can use the right mixin.
Furthermore, I can also, when I'm building out the first-form HTML implementation of the mock, right-click and copy-as-svg the whole component, which makes for a nice stand in while I work on the rest of the code. It is great.
My uncle had a successful career in advertising. He would always say to me, "don't be just a wrist." He meant participate in guiding the concept and strategy instead of just being an execution person.
I've been in the design industry for 15 years now. When I was starting out, there was a flurry of philosophizing about design. There was a belief that designers should focus on solving problems instead of just making slick UIs. I don't see that discussion anymore. I see a bunch of "wrists" arguing over which pencil is best.
I was going to say my experience is kind of the opposite — everyone seems to be waxing poetical about "design thinking" but UI work is more and more cut and paste. That being said, the "wrists" may just have moved one abstraction level higher, and they're parroting design thinking tropes (design sprints, etc.) instead of lower level ones.
Good execution compliment good strategy. I think you can also be the valuable wrist that hard to replace.
I've seen people who knows about the theory and have creative idea, but the end result they made is just...lacking?, because they focus just about the strategy part and kinda look down on the importance of good execution. They may know that it is not good, not what they envisioned, but they don't know how to make it better because they don't know how the production process works, and usually have to accept what the vendor gives you.
But well yeah, there are certainly people that just want to be a wrist and not thinking too much about anything.
The best case I ever found was insisting that designers and developers sit together without much PM interference. The unplanned communication and collaboration ended up producing gold.
That's awesome to hear! Was that something that you had to fight for, and if so, what did that process look like?
My observation with SV startup organizations is that it is very difficult to get that buy-in from product on something like this. These product teams are groups of people trained to believe that "if we deliver X we get $Y", which prioritizes building as many of X in as little time as possible. And I completely agree on that merit, a company SHOULD strive deliver as many revenue generating changes as possible, that's how you avoid death.
If, as an engineer, you challenge that with a push to make better reusable systems and actually stick to them, you will always be met by opposition. "What's the ROI?" they will ask. It's hard to give one because it's not really quantitative, but everyone in the room (generally, product included) KNOWS it's the right move. What do you do?
I thought the Waterfall process was primarily an Agency/Marketing thing, with Tech Startups focusing more on a level playing field where most have input and touch the final product.
This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work, and the better they can show what the final product (and processes) will be like, the better.
Edit: Yes the Waterfall sucks, especially if you're at the bottom.
> This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work
Agreed that it makes sense for contractual work like this, where you just get sign-off, do the work, maybe iterate a little at the end, and then move on to something completely different. In fact, I would say it's the right tool for the job here, despite how much of a charged term "waterfall" has become.
It can easily fall apart when a single company does this enough though, because it usually comes with the lie that it delivers reusable work. You're not, and it manifests itself through your slow, confusingly inconsistent product. Maybe your customers don't care, but nobody will be proud of their work, and you'll start to gain the reputation of "it's buggy and confusing but it works"
I've had some success in agile-style places pushing for separate story pointing of special-snowflake bullshit design. Like:
"This feature's a 3 if we just do it with native elements or and/or existing UI guidelines, but it's another 5 story on top of that if you really need this ugly crap you're insisting on that'll bloat our bundle by a ton, likely be fragile in a variety of ways, and, realistically, probably have some a11y and cross-platform issues even with a "5" of effort put in."
Suddenly they don't really need it that much, and if they do, well, they have only themselves to blame when "not much" gets done this sprint. Congrats, you just saved them money and (probably) improved the UX and maintainability of the project. Every now and then they'll really insist, which is fine, but if you've got someone who's picking their (let's face it, usually terrible) glittery UI ideas over features & bugfixes more than very occasionally then the project's probably doomed, so at least that becomes clear really fast and you've got numbers to point to if shit gets toxic and the blame-game starts (you did document it, right?)
Our design team has churned off of all prior products and now uses Figma. I've consistently been impressed by the degree to which Figma appears to be completely trouncing InVision / Sketch / others with a superlative product.
The standard trend in enterprise software is towards oligopoly, with a few strong incumbents that struggle to actually kill one another as their products converge over time. Most enterprise businesses focus primarily on sales/marketing as they grow, rather than doubling down on a product that can kill incumbents. The fact that Figma has done both is really impressive and as an enterprise product head definitely something that I admire.
Our designers use Figma but the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts. Additionally the UX has tons of hidden features making it hard for non experts to discover how to do simple things like export mockups.
As a result the designers have a backlog of small busy work changes instead of focusing on the key design questions. No one else has licenses to make updates or knows how to use the tool.
The product team has started using Whimsical which is easier to use and is more reasonably priced for people who only use it occasionally or need to quickly illustrate low fidelity concepts. Now we have two design tools to essentially get around UX and pricing problems.
I love Whimsical. It's just so damn smooth and reliable.
All that being said, I think wanting one tool to serve not just designers but also product teams is probably too high of an expectation. We don't blame developer tooling if designers have a hard time making small updates to demonstrate design concepts. They're different domains, so different tooling is expected.
> […] the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts
I completely agree.
I don't see the Figma files as an output that designers produce. I see it as a product on its own that people should be able to collaborate on.
I'm not going to stop a designer from sending me pull requests. In fact, for small mundane updates I'd LOVE it, since it would take this burden away from me. In fact, our inhouse designers all have GitHub accounts, so in theory they are able to.
But when I want to tweak a little thing in a Figma file, like adjust naming of the symbols, clean up icons, add more diverse examples of the content to document edge cases, or to have grounds for my next discussion with a designer or engineer, I'm not allowed to. Also quite often the thing that I want to do is not necessarily meant for designers, but for my fellow developers. Things like technical notes for implementation.
> the licenses are so expensive that people on the product team can’t even make small changes or illustrate concepts
Licensing models that don’t scale can cause tremendous problems. Early on, design can become a bottleneck. Later, simple changes might be rejected because the cost of redesign is too high. In the worst cases, developers will work ahead of design to meet deadlines (since not every team can afford an expert in the design tool) and the resulting variances will be challenging to reconcile/resolve.
Expensive, high learning curve tools can introduce silos and bottlenecks into an organization.
We use Figma at work, and while it’s a nice tool I think it’s easy to fall (or maybe we just fell) into a kind of uncanny valley. The designs we get are close to realistic mockups of our actual UI, but are often not 100% there, and it’s the little deviations that can be quite distracting.
Engineer: So are we changing the nav icons as part of this story, too?
Designer: Oh, no, ignore that. I didn’t have our real icon set so I just grabbed some others
Engineer: This modal doesn’t look like our normal modal, are we supposed to be building a new one?
Designer: Oh, no, ignore that - I’m working on a design for a new modal and I just used that here
Engineer: Ok, do you know our current modal doesn’t support X, so this part of the interaction won’t work?
Designer: Oh, okay, I’ll go update the design I guess
Etc... sometimes makes me wish for the days of Balsamiq / sketch style designs where the idea was to not try to make it photorealistic.
Having said that I guess if you could get Figma completely in sync with your actual UI it’d be pretty nice.
EDIT: I will add that the clickable mockups seem really helpful for our Design team when they're doing user testing, which is happening before the designs get to us. But this is not unique to Figma, InVision can do it, too.
Of course it’s leaky, but obviously the cases where engineers built the right thing on the first try because of the clear design are harder to measure.
Ah yep of course, I’m just pointing out that those kinds of back-and-forths, Figma derived or not, are a sign of a healthy org. A lack of grumbling around miscommunication often means that no communication is happening, not that it’s going swimmingly.
I think it helps enormously if the designer responsible for the designs understands about the tech used in building it. I don't think that every UX designer needs to be a full stack developer as well, but when you have the ability to actually talk about the tech, you can also translate the design into something that non-design folks might understand.
I often ended up sitting next to one of the developers, working along-side with him, helping him on the technical issues (reading Stackoverflow and github issues on various repos for example) while he helped me with the designs by challenging and testing as we were wireframing ideas. Kinda like aöpair programming, but for designers and less siloed.
We really do love to pump ourselves up, don't we? My grandpa was an engineer who built bridges. I wouldn't dare call myself an "engineer" for slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two.
Because software development in the real world is hard. Hard computer science is hard. We're still in the infancy of the profession and have a long ways to go. I could honestly see it comparable to bridge building or rocket science.
Then reading again and seeing "javascript build pipeline" just made me LOL. Cause that's rocket science too.
Computer engineering is a science that shares common habilites and tasks with those your grandfather had. Maybe a website is more similar to build a garage than a bridge. And maybe building an operative system is like building a skyscraper...
You're being downvoted, but you're spot on. I can't quite put my finger on when the term "software developer" when out of vogue, but I suspect it has to do with titles at FAANG companies more than anything.
At Google in Canada we are no longer supposed to refer to ourselves externally as software engineers, for legal reasons. We're software developers again. Which is how I have always thought of myself.
Well, back in the 90s I called myself a "programmer." I miss that, too.
I guess there are levels. Computer engineering is a proper science, much much more deep and broad than mocking up a web page. And people study the science for years, the same as civil or aerospace engineers do, and get a label for that, called 'engineer'.
Same with a doctor. You study for that, get the label. You cannot/should call yourself a doctor if you just read some Wikipedia articles and listen to grandma tips and go applying band-aids and aspirins.
> Well, back in the 90s I called myself a "programmer." I miss that, too.
Oh man, so true. I miss it so much. Developer is such a vague term.. but in my little heart I still consider myself a programmer.
I guess what it comes down to, is software a machine/engine? Also, the person who does the "slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two" is or should be the designer, not the developer.
I've encountered this as well. I am a proponent of just using low fidelity shapes for mocks instead of high fidelity renderings of what it should actually look like.
If you put enough work into the design system, and implemented it well for use in code, all you should NEED is a low fidelity shape telling you where to put existing components, and how to string them together. Everyone already knows what a modal looks like, behaves like, etc. they don't need it designed for them every time it comes up. That just wastes everyone's time.
I second this. The most efficient frontier in communication between engineers and designers is about striving for simplicity by stripping visualization to stick figure like representation.
I'll check it out, thanks for sharing! Looks promising from one one minute scan.
In a similar vein (also have zero affiliation) I discovered https://whimsical.com today, which also has a few other promising looking tools like flow diagrams, post-its etc.
It makes it really easy to first building a design system (like Bootstrap, Material Designs, Antd,etc). Which are a bunch of components, from basics like headers, list, to modal, message, cards, etc.
Then just place those components into the wireframe.
If anything need to update, it will be updated from the design system, then sync to the project
Design is about how it works. That’s more important than how it looks. Low fidelity focuses designers on the app workflow, lets more of the team get involved in design, promotes UI component reuse, and avoids confusing managers about what’s actually finished.
Yea, we've had the same problem. I've started to ask our designer just show the thing that should be changed, with 0 other context.
An idea for Figma to mitigate this problem: make a browser extension that can export pages to figma documents. That would make it much easier to have up-to-date designs when doing web development.
This is a failure mode I've seen before in other distributed collaboration situations: there is a giant artifact that either clueless participants or homeless tools force everyone to carefully reexamine every time a change is made. If Figma really were all that I guess it would accommodate the futuristic technology called "diffs". Even if your excellent extension idea weren't available, ISTM designers should just maintain a current representation of production in Figma if only to themselves have some idea what's going on.
Seriously that interaction gives ma a headache.
Hand-drawn mockups on papers is where I'm at baby.
Know HTML, CSS and SVG as the back of your hand.
Code 10 modals and dropdowns and you won't even thing about it anymore.
We use a shared Figma component library, which gets implemented as a shared Storybook library for front end developers.
In theory, this means the designers are designing with components which are already represented in code, and as long as they update the library with any new or modified components, it should be straightforward: a change in the Figma library represents a change that needs to be reflected in Storybook.
But that's just the theory. In reality, designers often need to work quickly, and the idea of design debt is just as real as tech debt. Indeed, it's probably more of a problem, since there's no such thing as pull requests or automated regression testing for design, so it's harder to spot problems.
Figma already has a way to at least partially address this issue: they provide analytics that show you which of your components are getting detached, as well as a lot of other useful stuff. Unfortunately, the tier that allows this feature costs about 4x as much as the normal pay tier most people use.
There actually is proper version control for design! Abstract being the most fully featured, although only Sketch was supported the last time I checked. But yeah, in my case design debt is usually mainly born during exploration or when designs have a tight deadline and I don't take the time to organise my files and creating reusable components. I often end up with duplicates that I have to manually fix from there on out.
I’ve recently started using it with my team and the impact has been positive. Component sandboxing seems to encourage developers to encapsulate CSS within web components. Sandboxing also seems to encourage thinking about web component APIs and designing them for reuse.
How well is Storybook.js catching on as an emerging standard in UI development?
We like Storybook a lot. It's made communication between Design and FE a lot smoother. I wouldn't say it clears up all ambiguity, or eliminates all redundancy, but it's a noticeable improvement over relying on institutional knowledge alone!
When I joined about six months ago, the team was already using it, and keeping it up to date had become ingrained in the culture. I had nothing to do with it, so I can say it's been a good decision.
I have no idea if it's catching on in the wider world! Anecdotally, of the five places I interviewed at last year, two of them claimed to be using it.
That’s not figma’s fault, that’s a team communication and workflow issue. We have that at work too and the solution is to communicate. Have a big red box with text saying the modal is not ready, or simply don’t have a modal until it’s ready. Better stick, create placeholder components and use those. Replace when ready.
Agreed. In my company, your responsibility as a developer is to implement the design as shown on figma, pixel perfect. If something is incorrect on the design, someone will usually have noticed it and fixed it before I get the chance, because there are 4 sets of eyes on it (CTO, PM, Designers, Developer)
It depends on what is being built. Pixel perfect on the first iteration is not a great idea. Because on the first iteration we are usually trying to figure out “does this even solve the problem” and show that to users. After many iterations you have a rough plan. Then you build a quirky mock with existing components you have. Then you let users play with it and find existing rough edges and smooth them out.
Then you build a much nicer version (perhaps pixel perfect) and then have a lot of users play with it, and then your analytics funnels tell you where the bottlenecks are. So you make even more iterations until you make something that solves the problem in a delightful manner and users are going bonkers about it.
The TLDR is, there is no point getting pixel perfect in the first iteration. Good software requires tons of iterations and the entire pm-design-eng-user workflow should be optimized for faster iterations and learning.
Have a plugin which could turn the unfinished modal for example into a wireframe look & feel and then when you have the right icon, turn it off again.
I remember back in the days Expression Blend had some functionality to apply sketchy lines style (based on Bill Buxton's book - Sketching User Experiences).
Also, the prototyping functionality is still rather basic. Axure is much more powerful and ideal for the early sketching and testing phase.
But I'm sure Figma will have more sophisticated prototyping features in the future.
What does RP exactly do that you can't do in Figma? With the right plugins and component libraries, I dare say that Figma is definitely more powerful than Axure's offering.
I use Axure to prototype enterprise apps, i.e. lots of forms and data grids.
Last time I checked, Figma didn’t support interactive form elements or prototyping conditional branching based on what you type in a form field.
Being able to prototype business logic without having to get developers having to develop something, saves a lot time at early stages when you explore new features with business users and you can also iterate faster and it’s better for user testing as well, as it’s more than just clickable hotmapped images.
I know you could achieve the same with Framer, since you get access to the code, so that’s useful for designers who can code.
Axure is great for designers or product folks who can’t code.
Are there powerful prototyping plugins for Figma? I'd love it if the answer is yes.
Axure is horrible for wireframing and a non-starter for visual design, but it has the most powerful prototyping features I've seen by a long shot. Framer is straight up writing React code, so I don't count that as an option for the vast majority of designers.
I tried to switch to Adobe XD, but sooner or later you can't do some sort of thing that is simple in Axure and you are stuck. Simple example. You have a settings page like this:
Setting 1 name [toggle]
Setting 2 name [toggle]
Setting 3 name [toggle]
You want to turn any toggle on and panel with subsettings should appear underneath clicked setting name, shifting down all other settings below. In Axure it is just a checkmark "push widgets below".
Here's the thing: higher ups, more often than not, have no imagination. If your mock-up is not explicit and realistic, you'll get complaints and worries that it's not polished or that not a lot of work went into it.
Yeah, this is very real to me. Even after explaining what a wireframe is, I’ve had execs very confused why I’m proposing the UI look like black lines on white background. And not just just execs - I’ve had devs try to implement wireframes as-is as well!
You're mixing up wireframes and mockups. Wireframes should be used for exploration of ideas and generally laying down different ideas in their simplest form and mockups (high fidelity, in this case) would then be built based on the existing components or displays new features and views.
If the modal in your case doesn't support a feature, it would be caught during the wireframing, before anyone has invested too heavily into any particular design.
Also, if the mockup resembled the actual UI but still differs ever so slightly, it's a sign of an inexperienced designer. Either they haven't properly made the actual functionality clear and the visuals are confusing (should it differ from the current features or not) OR the team is in need of a design system which would be used as a basis for all design visualisations and implementations.
Our designers have solved this by making anything that’s still in the mock up phase completely black/white.
Anything that’s actually ready uses the primary/actual colors. It’s actually pretty great apart from 80% of the design being grey at any point in time.
Eh, that line of questioning should be handled by designers at the very beginning or even before sharing designs and can be addressed more generally for all of their designs before sharing any specific one.
Ha! If you think Figma is bad for, check out Axure at some point.
I got sucked into using Axure a few years ago and had a blast making interactive, data driven mockups that utilized custom JavaScript to build components.
It was awesome to get some key concepts across but then one day I realized I spent more time fighting the mockup software than if I had just coded it up.
Agreed. And I think there's a certain personality of people who are employed in UX that lean more towards the design than the conceptual side that often get lost in the weeds with this stuff, too, and you'll end up with a series of mocks that look great, smell great, and gosh darn it people like them... but are missing all error screens, corner cases, more complicated states, and leave developers in the dark on the bigger picture.
Back when I was doing iOS development for a bit I had one designer forcing us to go through every single screen and manually override the default vertical font spacing and kerning settings away from the (company wide) framework we were using -- a change that was fairly trivial on Android but a pain on our iOS stack -- and this ended up taking hours that could have been spent on functionality. And made the app harder to maintain, on top of that. But this was really important to this person that the font spacing match their preference, and also be identical to Android's.
I miss simple wire frames. Some of the more productive projects I was on when doing front end work were done like this: product manager / designer gives a rough idea of layout and flow; developer works with them to throw together the simple flow as just raw HTML, really. Iterate, change, modify based on what does or doesn't work. Then the lipstick came later, once that's all nailed down. Less time wasted.
For my own sanity I've avoided front end work at all now, and have been doing systems level work instead.
I think the reality is that most people who originally got into design did so not because they were passionate about user experience, but because they had some artistic sensibility, and design was a field that would let them utilise that sensitivity for aesthetics while also paying them a salary.
Over the past five years or so, the landscape has changed considerably, and many designers have been forced to make a decision to either head down a more UX-oriented path or do something else entirely. The result of this is that we now have a lot of UX designers who never really wanted to do UX, but were forced to adapt and take on a new role due to a changing industry.
It's not just Figma; a project that I'm on has been having basically the same challenges with Sketch/Sympli, and Axure before that. Breaking it into two separate "wireframe" and "mockup" steps has helped, but folks are still rushing to the "mockup" step too soon IMO; lots of things that could have been caught in the wireframe stage are still having to be corrected in the mockup stage instead, pretty much as described by parent. It's a fairly recent change for us, though, so I am hoping that things will get better with practice.
Personally, I'd rather just implement the wireframe (or something like it) and try to iron out the interaction wrinkles there where it's much easier to update the design and you don't have to worry about fonts and spacing nearly as much; once the interaction implementation is nailed down, then I think it's a better time to move on to the mockup. Hopefully we'll get an opportunity to try this at some point, but it was enough of a struggle to do a separate wireframe at all that I'm guessing it'll take awhile ;-)
had a 200 screen mockup in invision handed to me. it was obvious that a few different teams at the design agency had worked on it:
screens 1-25 had a certain nav bar
26-39 had the same nav bar, but everything a few pixels off with a slightly smaller font in off-white, vs white.
screens 40-70 alternated between the first to nav bars, and introduced pull down select boxes with multiple checkboxes in them. the multiple checkboxes represented - in some cases mutually exclusive combinations of things which contrasted with other nav options.
... and so on. Things had to look pixel-perfect - "look, it's a design agency, they put a lot of work in to thinking about how this is supposed to look and work". So.. you'd make the screens exactly the same ('just export all the CSS for each page', etc). But then, when using the app in development, if you went between various screens, and saw the discrepancies - font sizes changes in nav, for example - that caused more negative feedback - "this is broken!".
I tried to demonstrate the design screens were the problem themselves by just paginating between the invision slides - you could see the font sizes jump/change immediately. "now you're just being negative".
Figma is a solid design tool for basic web/mobile apps, however I think that this post reads like a sales pitch more than an honest assessment of the product.
The market for design tools is highly competitive, and the 'wins/winner take all' framework does not really apply here. Someone once remarked that every design tool is Photoshop and to a certain degree this is true. Consequently is is easy to clone/transpose the basic functionality/interactions and get teams to switch to a new product. (Think about the recent transition from Sketch to Figma). Companies like Adobe have done well by bundling a suite of complementary products to gain an edge however this is not trivial from a business perspective. Even with bundling the business is not winner take all.
Figma is in many ways worse than Sketch, but collaboration is really helpful. That said, it is not that hard to spin up a competitor with React + Firebase in short order.
As much as Figma is in vogue right now, I would rather put money on Notion in the long term. Internal documentation has much higher switching costs than design tools. Notion already has excellent support for Management/Teamwork. They could easily roll out support for prototyping Mobile/Web apps and start eating into Figma's market share.
Interesting opinions. But mostly opinions, not backed by any data. Those features that the author considers to be "winning bets", might not be winners at all. Actually some of them may be considered Figma's downsides and maybe it would grow faster having had done things differently..
It all may be down to being relatively reliable (not that common among design & prototyping tools) and keeping the right balance between adding some slightly advanced prototyping features and still keeping it overall rather simple. Obviously I don't know the truth. Just saying it might be just that, and people are happy with it despite being browser based and without anybody really needing collaborative designing..
I invested a lot of time a few years back learning to use Sketch and did really like it however half of our office are Windows so on a recent project where I took the lead on design (I'm a software engineer but it's a small team) I decided to use Figma and I was blown away, it was much easier to use than Sketch and I had to do very little Googling on how to achieve what I wanted. I then created the animations, shared it with the head of the team who would be using it, he gave me a few bits of feedback and I then shared it with the rest of my team with no OS related problems at all.
Since I've been on furlough for the last 3 months and working on a new app for myself I jumped back over to Sketch (since I have a licence and have invested in some plugins) and I have to say I do not like it anywhere near as much as Figma, at this point I've only stuck with Sketch because of the extras I have purchased for it, once I feel got my money's worth from them I'll be over to Figma for everything.
Figma approaches design from an engineer's perspective. They have features like auto layout [0], swapping elements in a list, scaling multiple elements at once while preserving each aspect ratio, and so on.
Can you imagine that if designers before this wanted to move an element in a list, they would have to move every single one instead of having some drag and drop swap functionality? That if they wanted to dynamically change a button size for the text inside it, like we can do easily on the web, they simply couldn't?
Basically, Figma is turning design more into something like front-end development, doing things in a design program that engineers could do normally with code. This is because the developers of Figma are themselves coders rather than designers, so they know what real ease of use should look like (ironically). This is the fundamental corporate culture shift that is the difference between Figma and others like Sketch.
Of course, you could go all the way and simply turn the design software into a web/mobile development framework, which is what software like Framer [1] does, which is literally a design software built on React, and it can spit out React code for you once you're done designing.
Figma approaches design from an investors point of view.
Like most other web-SaaS tools, they aren't browser based because its better for the user. They sacrifice speed, native functionality, and usability for owning via server-side control over your wallet on a subscription plan.
The startup market in no-longer customer driven. It is investor thesis driven.
That is an odd way to put it if you had read the article. It notes that precisely because Figma was on the web that it was able to have collaboration features, have linkability to specific Figma files, and other such features, and thus serve the customer. As well, I am not sure how they sacrifice speed or usability exactly, when they even use Rust compiled to WASM in order to create the entire UI.
I can concede that SaaS can be, in many cases, be merely investor driven, but I cannot concede that Figma is one of those. Even being investor driven, such as having a subscription business plan, is not bad for the customer per se, as a sustainable business is better than a dead one. Software costs money to make, and more importantly, to upkeep and add features too. I am not sure how you can expect one time fees, especially for enterprise software like Figma is (personal plans are free), in this day and age.
Framer doesn't spit out React code once you're done. Code used in prototyping is hugely different and unusable in production. And Framer makers know this and openly talk about this, they're not trying to be a code generator.
Well, I've found it pretty useful to hand animation in js as-is for specific patterns (as we actually handle the specific bezier curve animation, timings, etc...)
Sure you may not use the components wholesale but you can still pick out specific parts, such as full CSS code or bezier curves as the sibling poster put it.
Figma users: can it export CSS grid? Would love to start using autogenerated HTML/CSS but don't want to go back to 'display: block' and the hacks that invariably come with it.
I think the terminal output is the figma viewer. I have a hard time seeing the point of the role and software if a front end developer has to hand translate the design to actual code or styling.
I know and use both Sketch and Figma on a decent level, and I prefer Sketch over Figma. My only complaint to it is that it doesn't have Ubuntu version (I understand why, but still).
To me, is main advantage of Sketch was how many tiny things they got right (before Sketch, I was using Fireworks), and this combined volume of tiny improvements resulted a huge advancement of user experience.
Figma, on the other hand, innovated just one thing: made design online and collaborative. All other tiny niceties are mostly copied. So I prefer to support the guys who crack their heads and innovate.
I also think that Sketch team knows about their main disadvantage, so a web editor for it looks to be in the works.
You know why it won for me? It had a Windows version from the start, so our team (Mac/Win) could actually get work done, since most other tools are Mac only.
Everything in this article makes sense to me. But sadly, I don’t know how useful it is to the aspiring founders who are trying to build a product right now. It’s relatively straightforward to see Figma’s success depended on these reasons but what will drive the success of the products that are getting built from scratch right now? I would love to see someone point out technical decision like “browser-first experience” but in 2020 version that’s fundamentally different from what everyone else is doing but will make sense in 2025 in retrospect.
I don’t think Figma winning is all that complicated. Designing for the web and mobile is more dynamic now. Designers are expected to show their ideas and produce interactive prototypes. No other design tool has the level of prototype control that Figma does.
Figma is very bad for illustration, but as the industry has killed off any semblance of art or technique this doesn’t matter. What does matter is producing something clickable and animated.
So Figma wins because it’s designed to solve the problem designers have now. Not 10 years ago like Sketch.
As a programmer I used to take the ability to manage my workflows as I saw fit for granted. It is amazing how much value there is in providing some level of programming capabilities to the average user. This post is essentially describing a workflow management system for designers. It's amazing Figma has unlocked so much value.
190 comments
[ 3.1 ms ] story [ 239 ms ] threadWe initially thought we'd need to provision the same number of licenses as we did for Sketch/InVision/Abstract. Turns out way more people started to get involved in the design process and we now have a more inclusive design practice. Content strategists, UX developers, researchers, can all participate early and often. (From a revenue perspective that's a pretty convenient thing for Figma, as each editor costs $45/mo — not only are they eating market shares from the existing pie, but they are also making that pie bigger)
I'm not dissing Figma, I'm disagreeing with the article about what makes it great.
I totally agree and have been moving my spec work from Notion to Figma too!
Building enterprise apps means dealing with a lot of forms and grids and making these fully interactive is easier in Axure.
I've been watching it though, because I'm curious to see if they'll ever switch away from Electron for their desktop app. As far as I can tell, it doesn't need much from the browser other than a canvas. A lightweight standalone webassembly+canvas runtime would probably be enough to run it with some tweaks and could net significant performance/efficiency improvements (especially if said runtime leveraged Vulkan, Metal, etc). If they do that, it'll grab my attention and may kick off a new way to build cross-platform high-performance desktop apps.
Right now, Sketch seems to be the prevailing product in the overall design community. But in my opinion it's only because it was the first to really get such a strong hold on its niche, and a new product will take its place at the top soon.
What turns me off to it as a person who missed its initial spread is that the vanilla Sketch experience leaves a lot to be desired. It's cool that it supports plugins to extend its functionality, but I don't like how it's expected that you just have to get a bunch of plugins to reach parity with the vanilla features of its competitors. (The Mac only support is also a negative too, but it's not that big of a deal for me.)
It also helps that it's pretty easy on resources — when I first picked it up, my daily driver was a Core 2 Duo MacBook with 4GB of RAM, so back then efficiency was very important. These days I have access to much more powerful machines, but it's still nice that it can sit in the background with large projects open without impacting a browser with dozens of open tabs and mammoth apps like Xcode and Android studio.
So for now, there's just not enough to gain from investing time and effort into moving over to Figma.
This is great for quick, informal design work, like prototyping with participants who aren't specialists.
It's a double-edged sword, though. There are good reasons that professional creative workflows often include revision control and sign-off processes attached to distributing specific revisions outside of the internal team.
And IMHO the price delta between sketch and figma is basically a rounding error on the wage cost of your designers, so it’s barely even worth thinking about.
This reads like a long-winded pitch to a Figma investor more than an honest review.
I’ve been wanting to try it out but this article was a little bit of a turn off because it is so enthusiastic. Every tool has strengths and weaknesses so an article like this makes me wonder, what are the trade offs?
It is really easy to get up to speed to a workable draft sketch so I suggest you just try it out and see.
Can anyone here lay out a few major differences that I might be missing?
I recently came across a Windows-only app called Lunacy which offers Sketch file import and editing for Windows users (I haven't tried the app).
The published Sketch file specification [1] is what allows Figma and Adobe XD (and Lunacy) to import Sketch files. Ironically, neither Figma or Adobe XD publish their file formats.
I think where Figma is pulling ahead of Sketch (in terms of usage behaviour) is that it is being used by more than just designers. In fact, Figma is beginning to encroach (possibly unintentionally) on digital whiteboard tools like Miro and Mural.
[1] https://developer.sketch.com/file-format/
Can you imagine that if designers before this wanted to move an element in a list, they would have to move every single one instead of having some drag and drop swap functionality? That if they wanted to dynamically change a button size for the text inside it, like we can do easily on the web, they simply couldn't?
Basically, Figma is turning design more into something like front-end development, doing things in a design program that engineers could do normally with code. This is because the developers of Figma are themselves coders rather than designers, so they know what real ease of use should look like (ironically). This is the fundamental corporate culture shift that is the difference between Figma and others like Sketch.
Of course, you could go all the way and simply turn the design software into a web/mobile development framework, which is what software like Framer [1] does, which is literally a design software built on React, and it can spit out React code for you once you're done designing.
[0] https://www.figma.com/blog/announcing-auto-layout/
[1] https://www.framer.com/
https://help.figma.com/hc/en-us/articles/360038006274-Files-...
that is why it is so easy to migrate into figma from sketch, and impossible to migrate away from figma into anything else...
[0] https://github.com/sketch-hq/sketch-file-format
It better be fixed before they become big enough not to care.
from my point of view the only way to guarantee is to use software that provides open file formats and develops their features around those open formats. inkscape and sketch seem to be doing this
Multiple people can be working on the same thing at the same time and anyone can view the in progress work. This changes the traditional file based workflow where designers pass a file back and forth if they want to keep the work together - often working in a separate file then "merging" the work into a master file one at a time.
Because all the files are online it's possible to see who is working on what including at the very moment. Its really easy for me to get a sense of what other designers are working on and whats been updated recently.
A huge bonus beyond designer collaboration is the way Figma breaks the previous separation of working file and final export. Non-designers can check in on an in-progress file at any time without needing a designer to export some static version of it. This allows designers to work on related things in the same file but each "thing" can be in at various stages of completion without having a negative impact on delivering final work. This is also great for transparency.
I'm not a designer so I don't know how good it is and I only skimmed the article but the high level concepts in the article around managing design workflows make sense, e.g.
> Figma solved this problem. Designs in Figma are not just stored in the cloud; they are edited in the cloud, too. This means that Figma users are always working on the same design. With Dropbox, this isn’t true. The files may be stored in the cloud, but the editing happens locally—imagine the difference between sharing Word files in Dropbox vs. editing in Google Docs.
It sounds like Figma reduces friction in the collaboration process by clever use of cloud based and browser coordination. It's not innovative but it's a good application of existing technology to the design space.
Out of curiosity, what do you consider innovative?
I don't hold opinions on what the word should mean, just curious to find all the different meanings of it
Also, because I’m a programmer, I’ve lived through many tech hype cycles (with mostly open source and developer tools). So over time I’ve become sensitive to this kind of rhetoric. That’s why my initial reaction was skepticism.
hopefully, I would assume there will be additional documentation that refers to a certain version that is approved
---
> That leaves versioning on designers side
how was versioning the designs prior to Figma? whose responsibility was it?
Software solutions will never fix problems that are caused by people.
Sketch, Figma, whatever the next design tool is. Google Docs, Quip, Notion. Trello, Pivotal Tracker, GitHub/ZenHub, Jira. I've gone through tool-switching fatigue with all of the above. Sometimes it doesn't matter much, other times it bogs us down with metawork for months as you figure out which features you gained, and more importantly, lost.
Back to design. I have seen design die the same way every time. Product misuses design resources, effectively making them contractors that hammer out one-off pieces of work. Those pieces of work get nitpicked by some vocal minority holding a lot of clout, until the end result violates the framework that the designer created.
This frustrates everyone over time.
Designers are frustrated because the systems they built are ignored.
Engineers are frustrated because they are adding new debt with every designed feature that has to rebuild parts of the world to make exceptions to systems work.
Product is frustrated because they just don't get why things are slow after they delivered a clear design to the engineers.
Let it all build up and people will start leaving your company.
So yes, use Figma if it suites your company well. If you're reaching for it because your team is frustrated, maybe consider digging into that more before you swap out yet another piece of software for all the wrong reasons.
Stop wasting time with high fidelity mocks. Engineers shouldn't need a picture perfect rendering of what product wants in order to implement it. The end result almost never ends up being an exact replication anyway for "reasons".
Start doing both of these in parallel: 1. Free up design to build systems that can be used to solve problems. Have them work closely with engineering to ensure the vision will carry ALL the way through to implementation 2. Lean very heavily on low fidelity mocks to hash out the SHAPE of changes to product (inspired by Basecamp https://basecamp.com/shapeup/1.1-chapter-02)
To use object oriented programming as an example, a design system is used in the concrete implementation of the abstract shape of the product requirement. When something doesn't fit into an existing abstraction, you refactor instead of fork.
Designers don’t know the software architectural constraints and what is easy to code up and what is not. Engineers do. PMs know what trade offs they want to make in fidelity for the product, but designers and engineers don’t. What you often end up with is designers spending a lot of time creating designs they think solve the problem, but miss out on a lot of edge cases. They and PM discuss the product design and hand it over to engineers as if their work is done. When the engineer goes to implement it, they find all those edge cases that were missed and the designer has to go and redo a bunch of stuff while engineering is blocked on some of those decisions and PM is concerned why it’s so hard to implement as is.
Designer here. My experience has been that Figma has done the opposite. It's created a lot of consistency with shared component libraries and standardized type / color styles. Also, the fact that engineers can jump into Figma and inspect CSS has been immensely helpful.
In the design world, Figma is like the equivalent of getting a robust IDE with syntax highlighting, code completion, compilation, and debugging. It's replaced multiple tools and connected people in a way that's never been possible.
In reality Design doesn't use components and most pages end up being composed of a bunch of one-off components and we waste a ton of time.
As a side effect of this, the app design isn't consistent across pages because we aren't sharing components.
I recognize that my view of this is from the bottom up in terms of only really having worked for SV startups, but I want to learn more and see if I can't make it work a bit differently this time.
That said, I never felt implementing a design once is the hard part, but keeping them maintained and in sync. What are things that worked for you in that regard? E.g. as an engineer, how do I quicky figure out what I need to adapt when a design has changed? I quickly looked at Figma, and while there is a version history, it just seems to switch completly between versions without anymore detail. So I'm bound to miss changes and completly am reliant on the designer annotating manually.
Furthermore, I can also, when I'm building out the first-form HTML implementation of the mock, right-click and copy-as-svg the whole component, which makes for a nice stand in while I work on the rest of the code. It is great.
I've been in the design industry for 15 years now. When I was starting out, there was a flurry of philosophizing about design. There was a belief that designers should focus on solving problems instead of just making slick UIs. I don't see that discussion anymore. I see a bunch of "wrists" arguing over which pencil is best.
Maybe I'm just an aging curmudgeon...
I've seen people who knows about the theory and have creative idea, but the end result they made is just...lacking?, because they focus just about the strategy part and kinda look down on the importance of good execution. They may know that it is not good, not what they envisioned, but they don't know how to make it better because they don't know how the production process works, and usually have to accept what the vendor gives you.
But well yeah, there are certainly people that just want to be a wrist and not thinking too much about anything.
My observation with SV startup organizations is that it is very difficult to get that buy-in from product on something like this. These product teams are groups of people trained to believe that "if we deliver X we get $Y", which prioritizes building as many of X in as little time as possible. And I completely agree on that merit, a company SHOULD strive deliver as many revenue generating changes as possible, that's how you avoid death.
If, as an engineer, you challenge that with a push to make better reusable systems and actually stick to them, you will always be met by opposition. "What's the ROI?" they will ask. It's hard to give one because it's not really quantitative, but everyone in the room (generally, product included) KNOWS it's the right move. What do you do?
This is where I believe these products are focused on, essentially agencies try to get sign-off from clients before they begin work, and the better they can show what the final product (and processes) will be like, the better.
Edit: Yes the Waterfall sucks, especially if you're at the bottom.
Agreed that it makes sense for contractual work like this, where you just get sign-off, do the work, maybe iterate a little at the end, and then move on to something completely different. In fact, I would say it's the right tool for the job here, despite how much of a charged term "waterfall" has become.
It can easily fall apart when a single company does this enough though, because it usually comes with the lie that it delivers reusable work. You're not, and it manifests itself through your slow, confusingly inconsistent product. Maybe your customers don't care, but nobody will be proud of their work, and you'll start to gain the reputation of "it's buggy and confusing but it works"
"This feature's a 3 if we just do it with native elements or and/or existing UI guidelines, but it's another 5 story on top of that if you really need this ugly crap you're insisting on that'll bloat our bundle by a ton, likely be fragile in a variety of ways, and, realistically, probably have some a11y and cross-platform issues even with a "5" of effort put in."
Suddenly they don't really need it that much, and if they do, well, they have only themselves to blame when "not much" gets done this sprint. Congrats, you just saved them money and (probably) improved the UX and maintainability of the project. Every now and then they'll really insist, which is fine, but if you've got someone who's picking their (let's face it, usually terrible) glittery UI ideas over features & bugfixes more than very occasionally then the project's probably doomed, so at least that becomes clear really fast and you've got numbers to point to if shit gets toxic and the blame-game starts (you did document it, right?)
The standard trend in enterprise software is towards oligopoly, with a few strong incumbents that struggle to actually kill one another as their products converge over time. Most enterprise businesses focus primarily on sales/marketing as they grow, rather than doubling down on a product that can kill incumbents. The fact that Figma has done both is really impressive and as an enterprise product head definitely something that I admire.
As a result the designers have a backlog of small busy work changes instead of focusing on the key design questions. No one else has licenses to make updates or knows how to use the tool.
The product team has started using Whimsical which is easier to use and is more reasonably priced for people who only use it occasionally or need to quickly illustrate low fidelity concepts. Now we have two design tools to essentially get around UX and pricing problems.
All that being said, I think wanting one tool to serve not just designers but also product teams is probably too high of an expectation. We don't blame developer tooling if designers have a hard time making small updates to demonstrate design concepts. They're different domains, so different tooling is expected.
I completely agree.
I don't see the Figma files as an output that designers produce. I see it as a product on its own that people should be able to collaborate on.
I'm not going to stop a designer from sending me pull requests. In fact, for small mundane updates I'd LOVE it, since it would take this burden away from me. In fact, our inhouse designers all have GitHub accounts, so in theory they are able to.
But when I want to tweak a little thing in a Figma file, like adjust naming of the symbols, clean up icons, add more diverse examples of the content to document edge cases, or to have grounds for my next discussion with a designer or engineer, I'm not allowed to. Also quite often the thing that I want to do is not necessarily meant for designers, but for my fellow developers. Things like technical notes for implementation.
Licensing models that don’t scale can cause tremendous problems. Early on, design can become a bottleneck. Later, simple changes might be rejected because the cost of redesign is too high. In the worst cases, developers will work ahead of design to meet deadlines (since not every team can afford an expert in the design tool) and the resulting variances will be challenging to reconcile/resolve.
Expensive, high learning curve tools can introduce silos and bottlenecks into an organization.
Engineer: So are we changing the nav icons as part of this story, too?
Designer: Oh, no, ignore that. I didn’t have our real icon set so I just grabbed some others
Engineer: This modal doesn’t look like our normal modal, are we supposed to be building a new one?
Designer: Oh, no, ignore that - I’m working on a design for a new modal and I just used that here
Engineer: Ok, do you know our current modal doesn’t support X, so this part of the interaction won’t work?
Designer: Oh, okay, I’ll go update the design I guess
Etc... sometimes makes me wish for the days of Balsamiq / sketch style designs where the idea was to not try to make it photorealistic.
Having said that I guess if you could get Figma completely in sync with your actual UI it’d be pretty nice.
EDIT: I will add that the clickable mockups seem really helpful for our Design team when they're doing user testing, which is happening before the designs get to us. But this is not unique to Figma, InVision can do it, too.
Also, look! Engineers are talking to designers.
That's a fair comment.
> Also, look! Engineers are talking to designers.
I think most good teams have had engineers talking to designers since well before Figma :)
I often ended up sitting next to one of the developers, working along-side with him, helping him on the technical issues (reading Stackoverflow and github issues on various repos for example) while he helped me with the designs by challenging and testing as we were wireframing ideas. Kinda like aöpair programming, but for designers and less siloed.
We really do love to pump ourselves up, don't we? My grandpa was an engineer who built bridges. I wouldn't dare call myself an "engineer" for slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two.
Because software development in the real world is hard. Hard computer science is hard. We're still in the infancy of the profession and have a long ways to go. I could honestly see it comparable to bridge building or rocket science.
Then reading again and seeing "javascript build pipeline" just made me LOL. Cause that's rocket science too.
At Google in Canada we are no longer supposed to refer to ourselves externally as software engineers, for legal reasons. We're software developers again. Which is how I have always thought of myself.
Well, back in the 90s I called myself a "programmer." I miss that, too.
Same with a doctor. You study for that, get the label. You cannot/should call yourself a doctor if you just read some Wikipedia articles and listen to grandma tips and go applying band-aids and aspirins.
> Well, back in the 90s I called myself a "programmer." I miss that, too.
Oh man, so true. I miss it so much. Developer is such a vague term.. but in my little heart I still consider myself a programmer.
I guess what it comes down to, is software a machine/engine? Also, the person who does the "slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two" is or should be the designer, not the developer.
If you put enough work into the design system, and implemented it well for use in code, all you should NEED is a low fidelity shape telling you where to put existing components, and how to string them together. Everyone already knows what a modal looks like, behaves like, etc. they don't need it designed for them every time it comes up. That just wastes everyone's time.
I have no affiliation with them.
In a similar vein (also have zero affiliation) I discovered https://whimsical.com today, which also has a few other promising looking tools like flow diagrams, post-its etc.
App Cooker on iPad is really nice too, though no longer maintained. It exports the storyboard of all the UI screens connected by transition arrows.
It makes it really easy to first building a design system (like Bootstrap, Material Designs, Antd,etc). Which are a bunch of components, from basics like headers, list, to modal, message, cards, etc.
Then just place those components into the wireframe.
If anything need to update, it will be updated from the design system, then sync to the project
Design is about how it works. That’s more important than how it looks. Low fidelity focuses designers on the app workflow, lets more of the team get involved in design, promotes UI component reuse, and avoids confusing managers about what’s actually finished.
An idea for Figma to mitigate this problem: make a browser extension that can export pages to figma documents. That would make it much easier to have up-to-date designs when doing web development.
In theory, this means the designers are designing with components which are already represented in code, and as long as they update the library with any new or modified components, it should be straightforward: a change in the Figma library represents a change that needs to be reflected in Storybook.
But that's just the theory. In reality, designers often need to work quickly, and the idea of design debt is just as real as tech debt. Indeed, it's probably more of a problem, since there's no such thing as pull requests or automated regression testing for design, so it's harder to spot problems.
Figma already has a way to at least partially address this issue: they provide analytics that show you which of your components are getting detached, as well as a lot of other useful stuff. Unfortunately, the tier that allows this feature costs about 4x as much as the normal pay tier most people use.
I’ve recently started using it with my team and the impact has been positive. Component sandboxing seems to encourage developers to encapsulate CSS within web components. Sandboxing also seems to encourage thinking about web component APIs and designing them for reuse.
How well is Storybook.js catching on as an emerging standard in UI development?
When I joined about six months ago, the team was already using it, and keeping it up to date had become ingrained in the culture. I had nothing to do with it, so I can say it's been a good decision.
I have no idea if it's catching on in the wider world! Anecdotally, of the five places I interviewed at last year, two of them claimed to be using it.
If it’s a rough wireframe it can be just that, rough.
If it’s a pixel perfect mockup then it’s a contract for final product IMO.
Of course whether there are that many sets of eyes on it depends how big a co you’re working for!
Maybe if the pixel perfect design is diff'd against the final product...
Then you build a much nicer version (perhaps pixel perfect) and then have a lot of users play with it, and then your analytics funnels tell you where the bottlenecks are. So you make even more iterations until you make something that solves the problem in a delightful manner and users are going bonkers about it.
The TLDR is, there is no point getting pixel perfect in the first iteration. Good software requires tons of iterations and the entire pm-design-eng-user workflow should be optimized for faster iterations and learning.
A good design system + mockups get your that.
Have a plugin which could turn the unfinished modal for example into a wireframe look & feel and then when you have the right icon, turn it off again.
I remember back in the days Expression Blend had some functionality to apply sketchy lines style (based on Bill Buxton's book - Sketching User Experiences).
Also, the prototyping functionality is still rather basic. Axure is much more powerful and ideal for the early sketching and testing phase.
But I'm sure Figma will have more sophisticated prototyping features in the future.
Last time I checked, Figma didn’t support interactive form elements or prototyping conditional branching based on what you type in a form field.
Being able to prototype business logic without having to get developers having to develop something, saves a lot time at early stages when you explore new features with business users and you can also iterate faster and it’s better for user testing as well, as it’s more than just clickable hotmapped images.
I know you could achieve the same with Framer, since you get access to the code, so that’s useful for designers who can code.
Axure is great for designers or product folks who can’t code.
Is the above possible in Figma now?
Axure is horrible for wireframing and a non-starter for visual design, but it has the most powerful prototyping features I've seen by a long shot. Framer is straight up writing React code, so I don't count that as an option for the vast majority of designers.
Setting 1 name [toggle]
Setting 2 name [toggle]
Setting 3 name [toggle]
You want to turn any toggle on and panel with subsettings should appear underneath clicked setting name, shifting down all other settings below. In Axure it is just a checkmark "push widgets below".
Their imagination is running wild that the mockup being used in the presentation to them means its an unknown time until its ready to ship..
They are imagining that is past whatever deadline they have in mind for it lol
If the modal in your case doesn't support a feature, it would be caught during the wireframing, before anyone has invested too heavily into any particular design.
Also, if the mockup resembled the actual UI but still differs ever so slightly, it's a sign of an inexperienced designer. Either they haven't properly made the actual functionality clear and the visuals are confusing (should it differ from the current features or not) OR the team is in need of a design system which would be used as a basis for all design visualisations and implementations.
Anything that’s actually ready uses the primary/actual colors. It’s actually pretty great apart from 80% of the design being grey at any point in time.
I got sucked into using Axure a few years ago and had a blast making interactive, data driven mockups that utilized custom JavaScript to build components.
It was awesome to get some key concepts across but then one day I realized I spent more time fighting the mockup software than if I had just coded it up.
Oops!
Back when I was doing iOS development for a bit I had one designer forcing us to go through every single screen and manually override the default vertical font spacing and kerning settings away from the (company wide) framework we were using -- a change that was fairly trivial on Android but a pain on our iOS stack -- and this ended up taking hours that could have been spent on functionality. And made the app harder to maintain, on top of that. But this was really important to this person that the font spacing match their preference, and also be identical to Android's.
I miss simple wire frames. Some of the more productive projects I was on when doing front end work were done like this: product manager / designer gives a rough idea of layout and flow; developer works with them to throw together the simple flow as just raw HTML, really. Iterate, change, modify based on what does or doesn't work. Then the lipstick came later, once that's all nailed down. Less time wasted.
For my own sanity I've avoided front end work at all now, and have been doing systems level work instead.
Over the past five years or so, the landscape has changed considerably, and many designers have been forced to make a decision to either head down a more UX-oriented path or do something else entirely. The result of this is that we now have a lot of UX designers who never really wanted to do UX, but were forced to adapt and take on a new role due to a changing industry.
Personally, I'd rather just implement the wireframe (or something like it) and try to iron out the interaction wrinkles there where it's much easier to update the design and you don't have to worry about fonts and spacing nearly as much; once the interaction implementation is nailed down, then I think it's a better time to move on to the mockup. Hopefully we'll get an opportunity to try this at some point, but it was enough of a struggle to do a separate wireframe at all that I'm guessing it'll take awhile ;-)
screens 1-25 had a certain nav bar
26-39 had the same nav bar, but everything a few pixels off with a slightly smaller font in off-white, vs white.
screens 40-70 alternated between the first to nav bars, and introduced pull down select boxes with multiple checkboxes in them. the multiple checkboxes represented - in some cases mutually exclusive combinations of things which contrasted with other nav options.
... and so on. Things had to look pixel-perfect - "look, it's a design agency, they put a lot of work in to thinking about how this is supposed to look and work". So.. you'd make the screens exactly the same ('just export all the CSS for each page', etc). But then, when using the app in development, if you went between various screens, and saw the discrepancies - font sizes changes in nav, for example - that caused more negative feedback - "this is broken!".
I tried to demonstrate the design screens were the problem themselves by just paginating between the invision slides - you could see the font sizes jump/change immediately. "now you're just being negative".
I didn't last very long on that project...
As much as Figma is in vogue right now, I would rather put money on Notion in the long term. Internal documentation has much higher switching costs than design tools. Notion already has excellent support for Management/Teamwork. They could easily roll out support for prototyping Mobile/Web apps and start eating into Figma's market share.
It all may be down to being relatively reliable (not that common among design & prototyping tools) and keeping the right balance between adding some slightly advanced prototyping features and still keeping it overall rather simple. Obviously I don't know the truth. Just saying it might be just that, and people are happy with it despite being browser based and without anybody really needing collaborative designing..
Since I've been on furlough for the last 3 months and working on a new app for myself I jumped back over to Sketch (since I have a licence and have invested in some plugins) and I have to say I do not like it anywhere near as much as Figma, at this point I've only stuck with Sketch because of the extras I have purchased for it, once I feel got my money's worth from them I'll be over to Figma for everything.
Can you imagine that if designers before this wanted to move an element in a list, they would have to move every single one instead of having some drag and drop swap functionality? That if they wanted to dynamically change a button size for the text inside it, like we can do easily on the web, they simply couldn't?
Basically, Figma is turning design more into something like front-end development, doing things in a design program that engineers could do normally with code. This is because the developers of Figma are themselves coders rather than designers, so they know what real ease of use should look like (ironically). This is the fundamental corporate culture shift that is the difference between Figma and others like Sketch.
Of course, you could go all the way and simply turn the design software into a web/mobile development framework, which is what software like Framer [1] does, which is literally a design software built on React, and it can spit out React code for you once you're done designing.
[0] https://www.figma.com/blog/announcing-auto-layout/
[1] https://www.framer.com/
Just like what happened to HTML and CSS.
Like most other web-SaaS tools, they aren't browser based because its better for the user. They sacrifice speed, native functionality, and usability for owning via server-side control over your wallet on a subscription plan.
The startup market in no-longer customer driven. It is investor thesis driven.
I can concede that SaaS can be, in many cases, be merely investor driven, but I cannot concede that Figma is one of those. Even being investor driven, such as having a subscription business plan, is not bad for the customer per se, as a sustainable business is better than a dead one. Software costs money to make, and more importantly, to upkeep and add features too. I am not sure how you can expect one time fees, especially for enterprise software like Figma is (personal plans are free), in this day and age.
To me, is main advantage of Sketch was how many tiny things they got right (before Sketch, I was using Fireworks), and this combined volume of tiny improvements resulted a huge advancement of user experience.
Figma, on the other hand, innovated just one thing: made design online and collaborative. All other tiny niceties are mostly copied. So I prefer to support the guys who crack their heads and innovate.
I also think that Sketch team knows about their main disadvantage, so a web editor for it looks to be in the works.
Figma is very bad for illustration, but as the industry has killed off any semblance of art or technique this doesn’t matter. What does matter is producing something clickable and animated.
So Figma wins because it’s designed to solve the problem designers have now. Not 10 years ago like Sketch.
- https://github.com/treeform/fidget
- https://www.youtube.com/watch?v=IB8Yt2dqZbo&list=PLxLdEZg8DR...
- https://news.ycombinator.com/item?id=23585006