Figma: The product design team’s process
figma.com
figma.com
It still boggles my mind that the same person can:
(1) one hand be that stereotypical designer with the scarfs and the small cups of coffee and the Leica cameras, designing user interfaces and logotypes and brands (Spotify logotype, Spotify green color), designing popular fonts for the Internet ( https://rsms.me/inter/ )
(2) on the other hand be a great low level engineer, creating programming languages, virtual machines ( https://github.com/rsms/sol ), text editors, stuff like GraphQL, etc
A one man army for sure.
By sheer necessity, someone like this had to emerge.
I never quite understood why the typical tech company product organization is so obsessed with finding the perfect graphic designer, instead of the perfect engineer.
Stick with me for a sec, I feel like I’ll draw a lot of heat here.
Good designers absolutely do good design work, and that’s wonderful! It just hardly ever, or does not at all, translate to how the product is actually built. At worst it leads to implementations being ad-hoc literal translation of high fidelity screenshots (of the perfect design!) that becomes impossible to maintain.
You could say the designer and some group of engineers are supposed to work together to build a “design system” and, well it might work, if you have good leadership. Not-so-good leadership will at worst not let engineers do this because it’s “not delivering value to the user!”, and decent leadership will let this happen once but ongoing maintenance will never happen.
So. What was the point of hiring the designer again? Having worked with companies, they do try to hire this “engineer who designs” all the time, and they constantly say things like “I know they’re a unicorn but maybe we’ll get lucky” but I think they would be surprised what a group of seasoned engineers in their field would be able to do design wise. Most web content does the same thing the same way nowadays anyway, you’re actually better suited copying UX that people will be familiar with :p
If you're a heads down no-nonsense engineer, you're not going to build Fallingwater.
The only reason why I, with a design background, was able to learn frontend (as well as additional topics like design patterns, DSAs, caching, software architecture, optimization, etc.) was because I was lucky enough to find a back end engineer who needed design help and was game to let me take the reigns on that part of the project even when I had zero experience. I mean, holy shit, talk about trial by fire. He tested me with toy projects and then when I showed that I could actually walk the walk, we were off to the races with real client projects. Other companies simply put people like me to do one thing and one thing alone which is... well design.
Realistically, most companies just care about filtering candidates based on x years of experience in Language/Library. Which makes sense, but it also means that pushing the boundaries of your knowledge isn't resume-able until a company allows you to deploy, at which point you can finally say you have 0+i years of ThingYourAreLearning.
I've been mentoring a Designer and friend over the last year, and I'm also teaching coding for designers since a short while.
The benefits are quite tangible: As a programmer, you still structure the application, set up the tooling, build the abstractions and the logic, but you're now freed from fiddling with pixels, because the designer has already built his prototypes with implementation in mind, can communicate intent, compromises and solutions for edge cases, and they can also implement a lot of things by themselves, sometimes with guidance. Git is not rocket science either if you give them a clear workflow and resolve issues that are beyond what you'd expect.
I don't think that designers should have to know development well enough to be able to build the whole product, but the more you know, the better it is.
For what it's worth, a personal anecdote - I didn't work with UX people or product managers until after I spent ~12 or so years as a developer/development manager.
My first impression of UX and PdMs was "wait, that's a job? This is stuff I expect my engineers to do. I wouldn't let my engineers get away without understanding the business or not obsess about the user experience."
Ironically I am now a product manager and what I have learned is that the answer is very simple: "perfect engineers (using your definition) are FUCKING RARE." In a startup you probably can structure your org around a handful of them, but by the time you're say Google-size (and way smaller than that) if your demands for a dev is "must be great at UX/business too" you just won't hire that many people, so you allow yourself to scale by breaking out the roles instead.
I miss the days of doing it all and try to get into it as much as I can, but I can't recommend that as a company strategy.
At the edges there are not enough people for off the shelf solutions. And doing it yourself is more productive than shopping for a silver bullet.
Anyway, I’m working on a “design” tool. I’m reachable via my handle at gmail. Reach out if you’re interested. Would be nice to bounce ideas.
Reusing common elements across UIs is a good thing. People complain about the “standard” splash page layout, or the stereotypical web-app styling... but Jakob’s Law is real, and users don’t want to learn another damn UI paradigm, they want to use your product to solve their problems. Reuse simplifies learning and so is a massive positive from an end-user perspective, and making the user’s life better is the designers role.
As you’ve noted, Figma is not infinitely flexible. For graphic design this would be a drawback, as novelty is heavily rewarded. But for UX design? Novelty is less important, and correctly communicating how a design should be implemented is much more essential to a user’s experience. And if I need maximum flexibility I can always use another tool.
I’m not claiming everything is perfect in Figma or the industry - but I think the doom is overstated.
This will be long and please skip my point of view if you find it offensive in any way. This is not my goal.
In my view, created from practice in multiple roles there is clearly several types of problems.
1. Cultural Problem - Design is complex field, it requires clear distinction from art, because in the core of design process is functional need of solving real problems with added aesthetics and emotional identification/impact (respectfully to given scope, audience and case). There is no simple way to explain design profession, but in peoples minds programming is magic - design is decoration. Actually to be a good designer you have to learn marketing, psychology and business processes, if you have to solve problems you must have knowledge of all the problems. Then comes implementation and you have army of technical people who are looking on you like a child, because they think they are smarter,:) Which is a joke in 80% of the time, and actually is my emotional motivation to become one - to check how smart are they actually. With time I have seen the true - only 20% (generalisation, not actual data) of any given field are true professionals with actual drive, they are moving with them all the rest of the heard.
2. Money Problem - Designers are cheap, because they have been undervalued for years. And this is not new, before Internet boom, advertising agencies made all they possibly can designers to be second grade citizens. How? By creating public perception that design is only aesthetics and everyone can be a designer. This objectively is a lie. Everyone can be an artist, to be a designer you must have scientific mind and use data to make decision in every step of the process and then have aesthetic knowledge and broad culture to create emotional impact. I solved this problem first by creating my own Advertising Agency and when Internet come along I transformed the company to Agency for User Oriented Design and Web - based solutions. Working and solving actual business problems with real customer data I now have a clear picture what is business value of design decisions. Professional design is capable of direct Return of investment, actually in today's world of frameworks and compartmentalisation of programming and cloud services, design is directly the tool that can make a difference and generate revenue. Programming is cheaper in production than successful design.
3. Investors Problem. Investors are given the power to decide who is "the rock-star". They give tons of money to technical founders with an idea. No business experience, no proven record. You have to be programmer with idea and some form of prototype. I have seen this first hand.
Can you see where I am going with this? Example: Recently I have been approached by startup making another service over successful API with React on top. They have build horrible product UX with bad copy on top of generic landing page. I can turn this product in profitable business by UX/UI redesign and proper CX. And what is in this for me? A "competitive salary"? Are you serious? NO. No more design for pennies. Period. Yes, you can hire me to beautify your shit and implement front-end functionality but real design solutions are for my business ventures only. Actually like everyone else I am selling my time and expertise and just like everyone else I am searching "the easiest way to make money".
I will repeat my self: Figma is a product born of necessity and lack of vision from Sketch slipping on collaboration and implementation tools. But using web browser as a platform for design product has clear limitations. Figma is implementation tool - not creative tool. The best product will be something like Sketch with traditional license and multi-platform base with cloud based collaboration as a service.
I am curious about this point you’ve made. Can you help me understand this better?
I am someone who has switched from Sketch to Figma and I believe Figma is far superior for my use cases in nearly every way. Also, I believe that Figma’s free tier is excellent for casual users or those without a license from their company (between jobs). For me, Figma has been a breath of fresh air and the recent auto layout improvements have taken it to the next level. I work full time as a product designer.
I somewhat agree with preommr on this:
"Figma is an absolutely awful design tool that has great collaboration features. For a UI/UX design tool it has terrible constraints, and basically no support for state changes. There's variances now, which came out really recently. Before that, it was even worse. People would have separate designs for each possible state.
Let alone how limited the possible actions are. It's just frames, boxes, and vector elements."
Absolutely mind boggling how Adobe didn’t see value in it at the time.
Lots of ways to fill in that particular blank. Lots of squandered opportunities and questionable choices over there.
I hate reading about places that are sane.
Places where product design is dictated by product managers who act as gatekeepers to product user data & business data, and thus they are like the “holy of holies” sort of man behind the curtain allowed to pull the strings - that is total death. Those companies churn out sucky shit that drives all but the worst kind of customers away.
I've worked with some of these process gurus, and sadly most of them are describing the ideal situation rather than how it works in practice for the average joe. And if they're into publishing this kind of material, they might also make it look better than it really is.
For a UI/UX design tool it has terrible constraints, and basically no support for state changes. There's variances now, which came out really recently. Before that, it was even worse. People would have separate designs for each possible state.
Let alone how limited the possible actions are. It's just frames, boxes, and vector elements. And no, vector grids are not enough to make it special. It's almost the bare minimum in a design tool.
The only reason figma seems great is because the competition is somehow even worse. Sketch is by all accounts slower even though it's native, but I couldn't tell you because it's Mac exclusive, so it leaves me and lots of people like me in the dust. It's terrible for people like freelance designers that might want to share designs with prospective clients.
The whole react component thing didn't turn out to be the killer feature collaboration was for figma. Framer has a lot of cool stuff, their plugin system is really powerful So you can have things like 3d elements which is super cool.
I am sure people use it, but it didn't grow in popularity like Figma did. I think with any kind of product, there's often a world of stuff happening under the surface that leads to success. I don't know why Framer hasn't been as successful. One guess would be that people just don't find writing react components and tying it to their design tool to be useful. Potentially too much friction, or that the people doing the designing don't often write react code. Or maybe they didn't market it well enough.
The question of components in design is really interesting but it's a whole other issue.
I do know that along with Adobe XD, Framer has had some issues with bugs. Figma, I would expect, is a lot more stable because they have their own custom renderer that's one canvas element whereas other tools use the DOM. It's one of the reasons why Figma is so feature-poor, they have implement a lot of behavior themselves.
At a previous job, I would just get PNGs or PDFs of some design, and I had to try to implement it. Often ended up with inflexible, hard-coded shit, guessing sizes ("8px padding? I think so??"), guessing colors, whatever.
At another job, the designer I worked with just gave me a link to a Figma file, and I had everything I needed. I could shit out front-end stuff quickly, without any issues.
I used to think I was just a bad at front-end, and therefore preferred the back-end. Turns out I'm just not that good a designer, and with a tool like Figma, building the actual designer's vision was easy and joyful.
This website stores data such as cookies to enable necessary site functionality, including analytics, targeting, and personalisation. By remaining on this website you indicate your consent.
The above is shown as Banner that does not require any user interaction before you indicate your consent. This may have been OK if it was in US, but I was under the impression with GDPR, or pretty much everything else in Europe, UK or most other CommonWealth countries, active user consent are required, such as clicking an OK button, rather than passive user consent, which is just showing you a banner.
Correct me if I am wrong.
In my mind, only cookies for things like Auth and session handle are necessary.
But I am not a lawyer or expert.
...
"We each go around the room and share a quick highlight or two of what we did over the weekend"
"We take time to reflect on our weeks, and ask each other “how are you feeling?”"
These kinds of 'forced empathetic connections' are a a 'hostile workplace' to many, I think it is objectively unprofessional to, in formal settings (and weekly meetings are formal) to require people do a personal 'song and dance'. Even though some people might share 'their mother died' and surely everyone would be nice about it ... it is absolutely not the place for that.
There is no doubt everyone loves to be asked these question on some level, and it's certain fine to do between colleagues when frankly it's more sincere.
But in a 'group/managerial setting' this exercise become cultish, expectant and oddly insincere.
In particular, the more intimate, the more likely people have to 'gel' deeply on cultural issues, and if they don't, there will be problems.
These are the people to talk most of 'diversity' but they end up being the 'least diverse' groups in terms of interest and ethos.
On some level - they are designers who generally tend to be a kind of 'specific type' of person, and I'm sure many/most of them would be fine with it, but I'm also doubtful of the level of self awareness.
The alternative - abrupt but highly productive meetings might leave people feeling cold; 'dispassion' all the time can feel that way. So I don't know what the answer is, but maybe something less formal like 'shared meals' where people just naturally engage in a more classically informal setting, on their own terms, would work.
I worked at a place that had 'free lunch' with a presentation every Wednesday, it turned out to be a great way to meet and chat with random people.
'People like to be Productive'
What I've found, is that almost all professionals actually love to do their jobs, to the extent they can do them. What 'we hate' is bureaucracy and 'things in our way' - but people love to talk about (and do!) their work and are eager to 'complete' if they feel their work will be used.
What would be a great 'follow up' to this, is more on the mechanics of actual process, and how new projects and details are shepherded through the system.
Is everyone working from spreadsheets? Atlassian tools?
How do people feel about working out of a 'ticket system' all of the time.
How much time is given to learning, exploring?
What's the breakdown between panic fixes, ongoing work, new projects?
What's the team balance there?
How do they work directly with Eng., where are the hurdles?
How do they document and record stuff (because that seems to be a byzantine thing everywhere I've worked).