Blog – Page 8 – Johan Ronsse

Config 2024

July 5, 2024 - Posted in conference figma figma-plugins

Last week, after Config, I started writing this huge blog post, with all the different subjects that were going through my head. Too many to name, really. If I had over word for the conference, for me personally, it would be overwhelming.

To make it more managable to publish my thoughts, a friend suggested to split up those topics and talk about them one by one. I always like to have shorter blog posts that are about one topic only, so this seems like the way to go.

First impressions

Let’s start with talking about Config itself.

Last week I enjoyed two days in San Francisco, albeit with some thoughts about SF. I was happy to visit the legendary Moscone convention center for the first time — where Apple used to hold their keynotes. I was very impressed by the scale. It’s huuuuuuge. Later someone told me if I was impressed by Moscone, I should see the Las Vegas convention centers that are able to host 40k+ people, but hey, I still very impressed.

The first day thousands of designers were queuing for their badges. When I entered the conference, I felt an almost festival-like atmosphere. Walking into the main stage room it almost looked like I was entering a Soulwax concert, complete with gigantic screens across the back wall and neon lights.

Entering for the keynote. There were a lot of people.

Last year, I couldn’t join, and read some complaints on Twitter: people were saying they couldn’t join certain talks, they had to queue to enter certain stages for hours etc. As an attendee this year, I didn’t notice any of that. Everything was extremely well organised, with over a hundred crew workers leading people in the right direction. What seemingly greatly helped with the crowds was that you had to plan the talk you wanted to attend beforehand on the Config website

When I entered I got a nice tote bag with some Figma swag — a nice cap, a water botle — and thanks to my plugin work also VIP access. Thanks for that Figma!

The best part about having the VIP access was the ability to sit in a reserved seating area on the front at every talk. I saw the keynote from the second row, straight in front of the stage and it was really nice to have such a good spot.

In the crowd at the front I met many people who were also a bit more involved with Figma than the usual attendee, from other plugin makers to organisers of Friends of Figma events in various cities. Personally I want to do more community building in Mexico City.

There is an FoF section, and I went to a nice event they organised in March hosted by the inimitable Pablo Stanley & team.

Dylan Field presenting the new UI

Diagram team, with coordinated outfits

I’m going to talk about some actual talks in a next blog post, so if you are interested, make sure to follow on X or Mastodon. Or more old school: follow the feed.

Promo time

On the second conference day I decided to skip some talks in the morning and use my post-coffee energy to promote Screenshot to Layout. I figured all the talks would end up on YouTube, so I could always watch them later, but I would not have another opportunity to do some real-life promoting to such a receptive audience.

There was a section on the show floor with several TVs dedicated to a single plugin, and one TV showing different videos of plugins and resources supported by the Figma Creator Fund.

Plugin with dedicated TV – the fantastic Curve Text plugin by Lichin Lin (community link)

Promo time!

This TV included a video of the plugin in action, which I embedded below.

But, because it was only shown every once in a while, I decided to show conference goers — when they were hovering around the area and were clearly interested in plugins — my plugin on an iPad in person.

This got me some nice impromptu feedback from people seeing the plugin for the first time. The looping five second video I have on the website and the simple concept behind the plugin greatly helped to not take people’s time for too long.

Most people liked the overall functionality and recognized the use case. As a designer you sometimes get assets in all kinds of formats, and it’s sometime handy to screenshot something and just get the text.

People asked if it can generate more than just text. I responded with my ideas around the contour feature but honestly, working on the initial research of going further than text recognition made me realize that “recognizing” UI elements from a screenshot is a computer science problem that’s insanely hard by itself. If anybody has creative ideas to bring this to the next level, I am very interested.

I was not allowed to distribute flyers, but I learned that next time, I want to at least bring some more promotional material next time that I can give to people individually.

Closing thoughts

Besides the conference part, Config was a good opportunity to have dinner with some designers, have a beer with old acquaintances and also have a direct conversation with some people who work at Figma.

But it was mainly the conference itself that left a big impression – and a slight identity crisis. I hope to post more on different topics in the next few days.
San Francisco

July 4, 2024 - Posted in conference san-francisco

Ik wil iets kwijt over San Francisco. Ik was er recent voor de Config conferentie van Figma.

Het is op sommige vlakken zo’n mooie stad als je het puur visueel bekijkt.

Maar het valt me altijd op hoeveel daklozen daar niet zijn. En je moet weten dat ik in Mexico-Stad woon, niet meteen de meest rijke stad van de wereld.

Het hielp misschien niet dat mijn hotel op een boogscheut van de Tenderloin buurt was, maar de crack rokende, soms rare dingen roepende daklozen stonden in schril contrast met het kraaknette conventiecentrum en hotel. Toen ik aankwam ‘s nachts voelde ik me echt niet op mijn gemak.

Op een ander moment stond ik aan een stoplicht en viel er een sportbijl uit iemand zijn rugzak.

Iemand die er al niet zo fris uitzag. Die zei me dat hij naar een game ging. Axe throwing is een sport zeker… maar in combinatie met de vibe van de buurt begin je dan dingen te denken. SF things, zeker?

Soms denk ik van: ik wil wel eens in de VS wonen. En als ik er dan naartoe ga, dan weet ik het toch zo niet. Maar misschien is het antwoord wel dat je gewoon niet in het centrum van SF rond Market/Powell wil wonen :-).
Conference season

June 15, 2024 - Posted in conference figma

I like June. There is always a lot of tech news: this week it was WWDC. Google I/O has been over for a few weeks and many videos were posted online. CSS day has passed, they put their videos on YouTube every week. And at the end of the month it is time for the Config conference of Figma, which I am attending in person.

Time to learn, network, and reflect.
Join the Doccle design team as a UI/UX designer

May 4, 2024 - Posted in doccle hiring jobs

At Doccle, we are seeking a talented UI/UX designer with a passion for creating intuitive and engaging user interfaces.

Who we are looking for exactly is listed on this job listing. In short, we are looking for a candidate with 2-5 years of experience, that is ready to join a product team focussed on quality.

I want to give a bit of backstory for those considering applying.

At Doccle, I’ve been building up the design team to improve the product. After 2,5 years of work we now have two great design systems in place for both our web and mobile apps. The Doccle team grew from approximately 20 people when I joined to 50 people.

We have great workflows for making sure that the design work is correctly tied to the software roadmap and any ticketing.

Lately there is a big emphasis on user research and validating the proposed solutions with a real user base. Both qualitative and quantitative research contribute to studying subject matter before starting to develop it. We have over 3 million users. There is a wealth of information to draw from.

Sometimes it’s hard to “UX research” the thing before it gets developed (you know: the old “if I asked people what they wanted…”) – for this we have data-based experiments, complete with analytics tracking, across all touchpoints. All of the above informs our software development roadmap.

The design team works mostly on the product side, where you will work together with analysts and product managers to get to a great end result. Examples of work include payment flows, document management flows and exploring exciting new features such as data sharing.

I don’t know about you but I have this special obsession for great administrative workflows, and it’s quite fun to work on optimizing the way a small independent would do their quarterly return in Doccle.

When I was working on Mono we had a big emphasis on how, when a designer joined the team, we would let them grow in their careers. We would help them with missing gaps in their skillset and finding the golden combination between what the company needed, what the person wanted to grow in, and what they were already good at. I want to apply the management techniques I learned at Mono in the Doccle context. What this means for you, as a candidate, is that I will take special care in mentoring you as a designer.

The team also has a great link with the marketing and front-end dev teams. There is a website that documents the brand, and the overall assets used have a cross-over between design and marketing. With the web front-end devs we discuss new design components and how they relate to the overall front-end pattern library. With the native mobile devs, we discuss the correct usage of iOS/Android patterns as we translate features to be available on every platform with respect for the design language of each platform.

I truly believe this is a great and unique position, and there are few product positions like this in Belgium. You would have to look abroad to find the kinds of companies with so many users, where the actual digital product is the primary focal point.

Next to a full-time designer, we are also looking into an internship/apprenticeship in school year 2024-2025. We are mostly looking at people who are studying Digital Experience Design at IMD or Devine.

If you are interested, we would love you to to apply using the instructions in the post.

I will be in Belgium the next few weeks, just phone me during office hours: +32 479 29 86 81 or e-mail my Doccle mail: johan.ronsse@doccle.be.
How to build zero to one inside a company

April 27, 2024 - Posted in figma product

This video really spoke to me. Mihika’s product management style reminds me of how I work, a lot! I was nodding in agreement all the way. Must-watch if you are involved in product decisions in any way.
Feedback 🤝 Feedback

April 23, 2024 - Posted in development figma figma-plugins screenshot-to-layout

I am looking for people who want to test drive the new Screenshot to Layout plugin for Figma.

I am specifically looking for people who want to jump on a short call, share their screen and share their experience. It would be awesome to do some usability testing after all these months of work.

If you are more of a no-meeting person, but still want to give feedback, feel free to check out the new version here. I won’t say too much so you can figure it out. Feel free to send me the feedback.

Interested? Get in touch: e-mail me at stl@johanronsse.be . If you want, I can do a test drive of your product or give a quick design crit. Feedback for feedback, as it were!
Type variables in Figma – variable font workaround

April 20, 2024 - Posted in figma typography

Having been released this week, type variables are the new hotness in Figma. If you want to know the details I recommend this excellent post by Joey Banks.

While his post is a general overview, this blog post is more about solving a specific niche issue: the design system I work on uses variable fonts, which are not supported yet in Figma’s variable logic.

Variable fonts have the concept of axises, for example width, grad, slant etc.; you can customize the variable font along an axis. For example you can set the value of “width” to be a value between 25 and 151 in Roboto Flex. You can this for yourself online here.

Now, Figma allows you to target the font family using string variables, letter spacing using number variables, font size using numbers variables… but not the specific axises for variable fonts. It’s unfortunate this did not make the release but to be fair, this is also extremely difficult to implement, since there are an infinite number of axises possible and there is no standardization across fonts.

But, since you name target a font family by name, and there is a likelihood that you only need a very specific “setting” of a variable font, a temporary workaround that might help you is to “slice” a variable font so it essentially only contains only the axis settings you will use.

Using the amazing Slice tool you can export a version of a font with the specific settings you choose “baked in”. What I did for my own needs was to export 3 variations of Roboto Flex with the axis of width set to 110, 115 and 120. I needed this to simulate the look of Proxima Nova on Android, while still retaining that Android feel.

And lo and behold, it worked.

Notice the “Roboto Flex Custom 120” style for Android.

Make sure to give it a unique name (postscript and others) so when you import it in your system fonts, it doesn’t conflict with the existing font.

Now all that is left for you is to distribute the font files with your colleagues, make sure you are OK when it comes to licensing, and enjoy your new variable type system.

I really hope this tip helps someone move their design system along using this awesome new Figma feature.
Overindexing on the system

March 26, 2024 - Posted in product - 1 comment

Have you ever seen the LEGO documentary on Disney+? It talks about the history of LEGO and if you’ve seen it, you might be familiar with a phrase that’s said many times in this documentary: new Lego products should be part of the system.

The original LEGO designers envisioned a system, mostly based around the grid pattern and being able to snap pieces into each other. Bricks that follow this system are the classic 2×4 Lego brick, a 2×2 brick and others (like half height bricks). They envisioned that with this system, you could basically create anything you wanted.

However, as the documentary progresses, it talks about how new people came in with new ideas, and these new ideas were not necessarily part of the system. The new pieces did not fit the original system, used another system altogether or were difficult to mass-produce. They were very set-specific and didn’t play well with other sets. Consequently, they did not fit the system.

Naturally, this caused a lot of discussions within LEGO.

As a designer that is both responsible for envisioning designs that work across hundreds of screens and with a fair bit of experience in design systems, I find myself on the side of the discussion of the original LEGO designers sometimes: the new component/icon/code etc. has to fit the system.

But then, sometimes I am envisioning something entirely new; and at this point, in an early design stage, it’s not very helpful – not even to me – to see how it would fit the system. However, as you get closer to the implementation reality (also see: the three types of product designs); you inevitably have to check how whatever you are designing fits the system.

Another case could be that the implementation is not a real implementation but demoware, in which case, you might have to deal with the fact that you are implementing something in the system, which is not actually part of the system, but it might be after it’s validated. Or you might have to deal with people who now think it’s part of the system, when to you, it’s not.

As a product designer you are expected to be able navigate around all these realities, depending on which conversation you are having. This can lead to very schizophrenic conversations where on one hand, something exists in a given system (e.g. design library), yet it is not implemented in another system (e.g. front-end library) yet an expectation exists from stakeholders that it’s there. The work to bring the system together is typically undervalued by stakeholders since it’s not considered “real work” (which seems really weird to me); but if you skip that kind of work, my experience is that the end result suffers tremendously.

A weird thing that happened the past years is that, because design systems demanded so much attention, and front-end developers screamed a bit much to put attention towards these systems – something making the system the actual work, instead of the end result – design systems kind of got a bad rap by managers. I believe some people burned design systems by forgetting the reason behind them – implementing actual user and business value.

I am the first to say there is too much design systems & component talk in general, and people should focus on results, but I seem to have internalized the design system approach enough in a way that it’s obvious to me how to move things across from Figma to a front-end library.

Depending on who you are talking to it is not that obvious and it’s up to you as the designer to find a way to make the actual very explicit (in order to do A, we need B, C and D).

Then from another standpoint, as a product stakeholder, it might be worthwhile to think ahead, that if you want your idea to make it into reality, maybe it’s better if it… fits the system? But here I diverge, and I am not really talking about front-end components here, but about fitting into the universal vision of the product. But that’s maybe a topic to revisit later.

If you enjoy these product posts or something stood out to you, let me know, because I am not sure if I am rambling or making sense. In any case I enjoyed the writing of these myself.
Three types of product designs

March 25, 2024 - Posted in design product
In the previous post, I wrote:

Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, but once you are in the implementation zone, that space changes to more of an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table.

If you are in a semi-waterfall logic, the quality of your initial ideas becomes more important. And let’s be honest, when you’re designing software, most of us are in a waterfall process at some level.

Surely there is some leeway in influencing the idea while it’s in development, but the space you move in severely limited by whatever analysis and design work was done before you, typically already limiting the possibility space. And it’s not just limited by your design; the limit might also come from an analysis, prior design, or legacy part of your software.

Not every type of design work follows the above order of going from idea to implementation. Some designs stay in the possibility space, and are specifically meant to be an output to help further business discussions; or are meant to gauge product/market fit.

I’ve had to learn to navigate the space of having hundreds of active designs, where some of them are closer to an implementation and some are merely an idea.

I’ve identified three types of designs in product and categorize them as A, B and C designs:
- A-type designs: The scope is more or less defined, there is an analysis, this design is going to development soon. Detailed questions about edge cases should have answers, and the design better be in a ready-to-implement state.
- B-type designs: The scope is probably to be developed in 4-8 months but might also be cut. You are exploring solutions with much more possibility for divergence than in A-type designs. You are working towards a solution, but it’s OK if not everything has been thought through.
- C-type designs: this design is not meant to be implemented at all, and does not have to take into account the reality of development. This design is meant to evolve a stakeholder discussion, to drive a client conversation, to simply document an idea, or to provide a vision and blueprint for the future that can inform B-type designs.
So, that’s it for today. My next post I would like to focus on some oddities that are going on in product regarding design systems.

If you like my writing about product, let me know, because I don’t know if these ramblings resonate with other designers/devs/product people!
2 years of in-house product design

March 20, 2024 - Posted in blijvend-leren career design

A few days ago marked the day I’ve been working in-house for 2 years. I think overall I am very happy with my decision to go in-house as a product designer. I gained a new perspective by working on a product full-time for a longer time. The depth in which you can go as an in-house designer when compared to agency work is incredible.

The other day I was investigating the voiceover implementation in our native iOS and Android apps.

Sometimes there is work that forms itself over many months. For example over the past two years I’ve tried to hold a tight guard on improved branding of Doccle overall, with some successes and some ways to go. Another ongoing project is moving Doccle to be a primary example of a great native-looking iOS and Android app, that embraces Apple and Google’s respective design languages. I’m happy with the steps that have been taken and that we are taking.

Now, it’s only logical that your work goes deeper because you have many months to work on similar problems. I keep remembering is this tweet by someone from Github that you better document your work in product, because it’s going to come back anyway. My CEO tells me he sometimes feels like the living memory of Doccle.

Some activities of the past two years included working on user interface designs, doing user research, tackling brand and visual design, writing front-end code, work on product strategy, improve and write new copy (in 4 languages), … and so much more.

As a designer, I am and always looking for opportunities to improve what we have.

Sometimes this is perceived as a kind of permanent unhappiness, and it can really get on the nerves of colleagues. Navigating stakeholders and decisions when you are sometimes basically stepping on someone’s work is its own challenge. I’ve learned to be more polite and more considerate of past work.

I’ve also learned that you can’t simply change something because you want to change it. The change has to be an improvement. Moreso, the change needs to have all blocking questions answered and depending on what it is, need to be thought through end-to-end. This is not always the case, but for things shipping to millions of users, it is.

The desire for change causes issues for others in the company. Change can mean disruption.

Arriving with my agency perspective I quickly started work on improved designs, only to find out that the company didn’t move as fast as my designs did. I made designs that I knew best – category interactions – filterable datagrids. Tidied up design systems. Then, it took a while to get implemented.

At first I attributed it to the company, but I believe it’s a reality of product. I came in with the naive expectation that if I would design it, it would get implemented. Boy, was I wrong.

When I was designing in an agency context, I rarely saw the actual implementation side; we consulted and came up with designs, but we often didn’t see how long it would take to get to an implementation. Or, we would specifically be hired for a redesign track, so the redesign was already decided within the company we were working for.

At Mono, we knew in the back of our heads that we finished up a project 6 or 12 months ago. Sometimes we got updates, but sometimes we didn’t hear about it anymore. Then, two years after a design we’d suddenly see a public implementation of our work pop up. Not every project would follow this pattern but it happened more than I liked.

I’ve now internalized the reality of a product moving much slower than the designs. Basically you are there during the whole timeframe of the implementation. But the detail you go into is so much deeper. From lokalisation in four languages, to designing the same feature across three platforms with multiple form factors, to overseeing the final implementation details.

I learned that as a product designer, you are moving across different types of design. This was not as apparent in agency work. I feel like we often got hired for execution, and not for research or problem definition. When we got hired, we already knew what the problem was. This is not always the case now, and thus I’ve been improving my research skills.

Designing gives you the chance to evaluate solutions before they have to be implemented. You diverge to converge. There is still a possibility space, where once you are in the implementation zone, that space changes more to an impossibility space. Scope gets locked down and in order to achieve a timing, you can not add more ideas to the table. In a next post I want to elaborate more on the three types of product designs I’ve identified.

First impressions

Promo time

Closing thoughts