Figma Config Europe 2020 Report
On Thursday 17 September 2020, a few of us from HENNGE attended Figma’s Config Europe online conference. One of our colleagues, Toshiya Doi, instigated the creation of a new experimental educational support to encourage members of our development division to attend online conferences despite the current pandemic situation. This was the first conference that put this program to use and seemed to be a perfect testing ground. The event was free, not too long, and despite being held in Europe, we didn’t have to stay up too late past our bedtimes.
For those of you who aren’t familiar, Figma is a collaborative design tool that was initially released in 2016 and has rocketed in popularity since. We use Figma within the company now to collaborate on designs and prototypes. I was especially interested in this conference as I first tried the application out in 2018 and quickly fell in love with it.
The conference started with an opening keynote, highlighting some of the improvements and features recently added to Figma alongside a preview of things to come. The Auto Layout feature added within the last year looked like a pretty magical time saver, and the new announcements promise to bridge the gap between code and design a bit more.
The presentations were then split over 4 stages, each with a general theme. One stage was labelled Inside Figma, with presentations from Figma employees. The others discussed topics such as teamwork, collaboration, fostering an inclusive culture, and design systems.
Instead of us all writing independently on the same presentations and duplicating our work, we decided to each write about some that especially impressed us.
Henry
For me, the talk that left the biggest impression was Intentful Contrast by Henrique Gusso. Looking at the title alone, I expected a talk that guides us on ways to pick colors with good contrast among them. What we actually got was a recounting of his journey researching different color spaces that fit best for his Figma plugin, aptly called Palettes, with juicy science to back the decision up!
When speaking about color spaces, most people will be familiar with the RGB color space, which is an additive color space made up of different lightness values of Red, Green, and Blue colors. While this color space is widely used in the digital world due to the way displays are built to emit color, he found that the color palette based on RGB does not provide an even lightness across colors when perceived by human eye, e.g. yellow colors always look brighter to humans compared to blues with the same intensity.
After some research, Henrique found that this is because the RGB color space is not meant to represent the colors with the same intensity with the same luminance level. A more suitable color space for this task would be HSL, which is an abbreviation of Hue, Saturation, and Lightness. Since we are able to specify lightness here, the problem should be solved, right?
Not so simple, it turns out. While HSL does take lightness as one of the main factors in generating colors, it still does not provide even luminance when viewed by human eyes. After some more research, he found that people have researched this issue and it turns out that human eyes perceive color lightness differently for each color. W3C defines this human-perceived lightness as relative luminance, and provides a formula to calculate relative luminance of colors. Sure enough, when we calculate the relative luminance for each color in a HSL color palette, we can see a constant upward curve from red all the way to blue colors across the same lightness values.
OK, are there any other color spaces more suitable for this task? There are some efforts to incorporate relative luminance to color space such as HSLuv and HPLuv.
- With HSLuv, there is still some perceptible variance in perceived lightness across the same intensity. It’s not as jarring as the one made with HSL, but still fairly noticeable in some colors at certain lightness levels. As it turns out, the formula used to calculate relative luminance is useful, but it’s not perfect.
- The color palette generated by HPLuv tends to look like pastel colors (paler) in comparison to the one generated with other color spaces, which does not look as appealing and limits the amount of colors that we can use.
Back to researching it is. After looking around some more, Henrique found another color space called CubeHelix, which he likes a lot and is the one he uses in the final version of his Palettes plugin. The powerful thing about this color space is that even though by default it also provides pastel colors similar to HPLuv, we can dial up the saturation level to generate a more vibrant color palette at the expense of some variance in relative luminance across the board. Since the user can adjust saturation at will (up to 300%), everyone can choose the value they like, and subsequently, choose which compromise they’d like to make. Finally, it’s done!
The talk left a great impression on me, especially because I’ve tried generating random color palettes with uniform saturation and lightness for a personal project in the past, and finally ended up giving up on randomized colors due to the difficulty of making sure they look good alongside each other. Henrique’s talk really opened up my eyes to what I had been missing at that time. Equipped with this new knowledge, I am now confident I would be able to come up with a better implementation for the random color generator I wanted to make at the time.
Kelvin
The talk which had the biggest impact on me was A look into Figma product thinking by Sho Kuwamoto. The entire talk was about how Figma comes up with ideas for features and Sho reverse-engineering the process to make it explainable. It was a very lighthearted and casual talk but it gave some interesting insight into how startups like Figma think about their product features and how they decide on what to work on, one of the fundamental problems when running a company.
As with anything briefly mentioned on a medium article — and originally from an online conference in this case — the following is not a formal system; please take all advice with a grain of salt.
The following is the journey that the team goes on when thinking about what features to add to their product.
He mentions in the first step, Users -> Problems, that the wrong question to ask yourself would be “How do we develop user empathy to build a better product?”. Sho then goes on about how when Figma was in its alpha phase, whenever the users had a problem, the team had to drive down to the user’s office to personally fix the problem. The frame of thinking should be “how can we help you do your job?”.
Once you do that, you should have a list of solutions to whatever problems that the user may face. The next hard thing is choosing which feature to work on. At Figma, they divide the features into 2 categories, tactical and strategic.
Tactical features are small features that have no real order and the best way to deal with them is to ship them quickly. At Figma, something like “a better style picker” might be a tactical feature.
Strategic features are much more complicated as they will affect each other. Thinking about them requires more steps.
- Plan lots of features at once. To ensure you have the full picture.
- Make a map of how each feature will fit with each other.
- At the start, it’s not going to fit together nicely.
3. Map looks like a document
- By writing everything out, they can identify user needs and group them in a way that makes sense
4. Figure out how they all stack together
- By being able to group things together, they can then see which features make sense to be developed in a certain order, like lining things up on the same street.
Last but not least, the most important part of the entire process is to develop a set of principles when arranging the strategic feature map.
This set of principles will drive future solutions and guide how the product develops. One example of a principle coming up from strategic features in Figma is the principle of “Allowing users to structure their design to match code”. This came about after grouping two popular features, States and Auto Layout, and seems like a great overarching principle in retrospect.
Michelle
Figma stands out among other design tools by its emphasis on improving collaboration between designers and other stakeholders in the entire product cycle. In her talk, When Localisation and Design Talk to Each Other, Anne-Sophie Delafosse showed how some common problems that arise during localisation can be solved with a Figma plugin. Anne-Sophie shared with us her experience, which led me to compare it to my experience at HENNGE. I chose to write about her talk because I have experienced a lot of the pains that she mentioned at HENNGE. Obviously, a plugin is just a tool. It can only be useful if all team members adopt it and use it effectively. I wonder if we can also change our process and remove some of the impediments in our localisation process.
Anne-Sophie started her talk with a little fun exercise with the audience. She showed us two screenshots of the same app in two different locales and asked us to spot the errors. The errors included untranslated strings, strings translated to a wrong language, sub-optimal UI, and broken UI, e.g. cutoff strings. I have experienced all of the above. Then, she moved on to talk about how localisation is typically handled in most companies. The three common observations are:
- Localisation is typically introduced very late in the development process.
- Designers do not have or are not given enough resources to take the differences of different languages into consideration early on.
- There are no platforms to effectively communicate the context of the translation task.
I can totally relate to all of these, and I would like to explain why they are problematic.
We use tools to compile translated strings into a json file which will later be read by the web application itself. It is part of my job as a developer to do the compilation, and we only consider a feature done when all the translations are in-place. Sometimes, the release of a feature can be blocked for days just because people cannot agree on the translations or they are not available. One of the causes is that developers send requests for translation too late in the cycle. On top of that, there are no standard ways of communicating the context, so it becomes very difficult and confusing for developers to send all these screenshots and follow what the translators are referring to on Slack (or any other communication tool.) What is even worse is when we find out that the UI design does not quite fit with a different language. For example, Japanese kanji usually need to have a bigger font than English to be readable, and a string in English usually becomes longer in Japanese. UI might break as a result. In most minors cases, frontend developers can take the liberty to fix the design, but in some cases, we need to reiterate the design process for something that we could have considered earlier.
Anne-Sophie introduced a Figma plugin their company uses to improve the whole localization process. It completely changes the workflow. Figma becomes the platform where designers, developers, and translators collaborate. Translators still upload their translations to a localisation management platform, then Figma will be able to automatically pull the strings from it. On the Figma console, all collaborators can see immediately how the design looks in different languages. As a result, designers are forced to think about localisation early on. Figma acts as the single source of truth and presents the contexts of where the texts reside. It also removes some burden from the developers.
The exact plugin that Annie-Sophie’s company uses is Phrase. A quick research gives me other options, such as Lokalise and Crowdin. However, as I mentioned in the beginning, these tools can only serve as an incentive for change. Although I believe designers, translators, developers, and other members in my company will all agree that adopting a new tool will be helpful, I do not think that it will be an instant switch. There are two main obstacles that we need to overcome. First, these plugins require the project to be using an agile localisation management tool like Crowdin. Unfortunately, many of the projects in HENNGE do not. Second, although our projects are English-first, many team members are not necessarily fluent in English, so doing localisation early on when the base strings are not finalized can hinder the design process as well. Nevertheless, I will try to use this plugin in my new project in HENNGE and hopefully can get some inspiration on how to improve our localisation process to other projects.
Overall I am really excited about the new features and plugins that Figma offers. I believe it will make collaboration smoother and even more fun!
Sean
The talk that impressed me the most as part of the main conference was from Amanda Pinsker, who has been working as a product designer on GitHub CLI. Her presentation ‘Designing for the command line’ covered her experiences in designing the tool, which brings the features of the GitHub workflow — such as issues and pull requests — to the terminal.
She began by talking about the UNIX shell that provides a command line user interface for UNIX operating systems.These interfaces were designed for computers with very little screen space and thus had to economise on their output. For example, Unix works on a principle of ‘no news is good news’, where successfully run commands give no feedback. On top of this, commands have obscure names that basically need to be memorised. For example, grep is essentially a search function, but it is named as such to mean ‘globally search for a regular expression and print matching lines’. UNIX commands are clearly dated and were not developed for the greatest user experience, but the commands have survived into the shells of Linux and MacOS pretty much in the same form as when they were first created decades ago.
In designing for a new, modern CLI tool like GitHub CLI, the team didn’t need to follow the UNIX command patterns. They have more screen real estate to work with, and the whole experience could just be made more user friendly. CLI tools have historically been quite arcane, hard to understand and unforgiving. The team could focus on making a tool that subverts these notions using better UX principles.
One of their tools was to look at the visual arrangement. Even though the command line is graphically limited, it doesn’t mean that positioning and spacing is not important. Additionally, even if images cannot be used in the command line, there are some icons that can be used, such as ticks ✓ and crosses ✗. Although different font sizes couldn’t be used, font styles such as bold, underline, and italic could be utilised to create emphasis alongside colour. To reduce context switching and keep familiarity, the colour scheme was kept in line with the GitHub web graphical user interface.
Design in terms of language choice was another critical area — on the command-line tool, words are basically all you get! Deliberation was taken to come up with a selection of commands to reduce ambiguity and complexity. Wordings could be made less esoteric and cryptic than UNIX commands. Speaking of, we are a little less constrained by space on modern displays than before and the team decided that it would be helpful to show success messages. To improve the experience even further, commands are made more discoverable by essentially showing a page of options that serves as a jumping-off point whenever a command is typed. For example, typing gh will show the top-level menu for the tool, giving options such as issue and release. If gh issue is typed in, it will show you the sub-commands and some examples of how to use them. This is a far cry from looking up the manual pages on some UNIX commands.
The presentation really struck home for me, emphasizing how design is not just about visual design and graphics. It was inspiring to see the design process in a medium with constraints. I have seen some people mention that ‘restrictions breed creativity’ and it was apparent. There was some inventive use of a document in Google Docs set to a black background and a monospace font to prototype designs collaboratively. For this specific project, it seemed like Google Docs was a more suitable tool than Figma!
The talk was well-paced and impressed me so much that I installed the GitHub CLI tool the next day! Definitely, one that I would recommend watching once the videos are up.
The closing speech, Function, and Feeling, also surprised me. I didn’t have any expectations going into the talk and the title felt a little vague. I’m glad I stayed for it though. The talk was given by Haraldur Thorleifsson, the founder of an Icelandic design agency called Ueno. Living in Tokyo, my mind first jumped to the station on the Yamanote line with the zoo and the park, but he introduced it as being bueno without the ‘b’.
Haraldur told us a personal story. He recounted how his mother died in an accident when he was a young boy. This deeply affected him, naturally. He became withdrawn and to cope, he would play games and became obsessed with making websites and apps that connected niche pockets of people online. Later in life, he ended up working with Google on their Santa Tracker, and poured his heart and soul into it. It was used by millions within days of its release and it made him happy to know that something he had created was making other people happy.
Back to him and his mother. He hadn’t really dealt with his emotions and feelings relating to that tragic incident. At some point recently, he put out a post on social media about his mother and got many comments from people who had known her, including some people he had never met before. They sent pictures and videos of her, many that he had never seen before. All of this had a massive effect on him and has helped him in processing his trauma.
The main message he wanted to convey was that technology can really help us connect and facilitate great moments. It can make our lives richer, more beautiful, help us process grief, and make us more human. In this day and age, a lot of technology is very function-focused but it doesn’t have to be. ‘Why’ we build things is just as important, if not more important, than ‘what’ we build.
Social media gets a lot of flak, but strangers reaching out to him and sending him video footage that deeply moved him wouldn’t have happened without these platforms existing. Bringing the topic back to the Google Santa Tracker — this is an application that could be easily dismissed as being a useless toy. But he’s had many people tell him about their personal experiences with the application — something that has helped them through difficult times. Games can be more than ‘just a game’ — they can be a lifeline, a vital coping mechanism.
This is an application that could be described as useless or easily dismissed. Something without a critical function, but something that definitely creates a lot of feelings. But he’s had many people tell them about their personal experiences with applications like Santa Tracker that has helped them through. Games can be more than ‘just a game’ — they can be a really important coping mechanism, a lifeline.
Master your craft, but don’t forget mastering your humanity.
Technology can help us build meaningful connections, create lifelong memories, and remind us what makes us human. In the end, isn’t that what’s really important?
It was admirable to see him bare his soul and talk so openly about his personal struggles in life. The message is one that I have been mulling over since and I thought the presentation was a great closer to the event.
Some final thoughts from each of us
Overall, I’m really glad I joined Figma Config Europe 2020. Some of the talks contain delightful surprises and topics that I really didn’t expect to encounter in a design-focused conference, like Designing for the command line and how code can inspire design in Figma components in sync with code components.
- Henry
I thought the conference was professional and of a high standard. I’m glad I attended the conference and it gave me an insight into how other companies and teams work. I look forward to all of the talks being uploaded in October and being able to check out the ones I missed.
- Sean
I really enjoyed the conference and despite being a Figma conference, there was a wide range of topics to learn from. I especially enjoyed the insights to how Figma grew and managed their product and how design as a whole was being considered, not just the visual aspect of it. There were some presentations that were more iffy than others but it really showcased the inclusivity of the figma community as a whole.
- Kelvin
New design tools like Figma blur the line that we traditionally have between designers and developers. If used right, they can boost the efficacy of collaboration between the two parties greatly. I really look forward to a new style of product design workflow.
- Michelle
