Johan Ronsse

  • Home
  • Projects
  • Blog
  • 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.

  • The case for design engineers

    February 13, 2024 - Posted in design development product

    Good post from Jim Nielsen about the case for design engineers. He gives a good example of the kind of implementation detail where you might need insight from both the design and dev perspective. I find that some of my best work came from where code intersected with design.

    Lately I am on a path involving a lot of pixel perfect design with a semi-traditional handoff, combined with research.

    Sometimes I yearn for the days of yore where I did not have to direct details from a distance, only hoping that the implementation matches my dreams. Moreover, the whole problem with trying to describe something is that your description will just be incomplete; you have to feel the implementation, you have to be actually use it.

    One problem I have is the multi-platform-ness of our implementation (iOS/iPadOS/Android/Web), combined with the actual design problems and research; which does not leave me with time to also concern myself about code.

    But when I do, I get a lot of pushback when I push for prototypes, with the arguments that it’s going to lead to throwaway code; will not fit in the system; or I just seem to leave the other side of the table puzzled with what I am talking about.

    The point that my respondents in my opinion do not get, is that the point of a prototype is to get to a conclusion, to learn something. You can then go ahead and implement the actual thing in production ready code. A prototype can be throwaway code, specifically because it helps you on your path to learning where you need to be in the end. The deliverable is testable and something to iterate further on.

    In my experience, when talking about a semi-complex UI, iterating on something once is just simply not enough. I find that in practice that it happens all the time that a design goes straight to implementation.

  • Mexico (3)

    February 1, 2024 - Posted in lifelog mexico persoonlijk reflectie road-biking

    Ik las net mijn vorige posts over Mexico, die ik schreef op het moment dat ik hier 1,5 maand en 2,5 maand was. Nu ben ik hier één jaar en ongeveer twee maanden. En het ziet ernaar uit dat ik hier nog een hele tijd ga zijn.

    Werk

    Qua werk sta ik nog altijd rond 5u-6u op om de Europese middag mee te pakken. Ik werk bijna uitsluitend voor één grote Belgische/Nederlandse klant. Daarnaast werk ik aan een aantal zijprojecten en uitzonderlijk doe ik iets kleins voor een andere klant.

    De zijprojecten gaan goed, zeker Screenshot to Layout dat telkens meer gebruikers heeft. Dat zijproject ben ik volop verder aan het ontwikkelen met een klein team. Ik kan er momenteel zelf spijtig genoeg weinig tijd voor maken. Hopelijk kan ik het binnenkort een nieuwe schwung geven.

    Ik blijf het voordeel hebben dat ik in de namiddag nooit meetings heb, en dus lekker geconcentreerd kan doorwerken. Ik zie andere designers/developers online vaak klagen over een gebrek aan focustijd en te veel meetings. Dat probleem heb ik zelden.

    Fietsen

    Ik ben in mijn vrije tijd veel bezig met fietsen. Ik had eerst een stadsfiets gekocht, en heb nu ook een koersfiets. Deze week heb ik mijn eerste groepsrit gemaakt en het was heel leuk. Ik wilde eigenlijk een gravelbike kopen (oh de hype), maar ben toch voor de koersfiets gegaan, met het idee dat het wellicht makkelijker zou zijn om groepsritten te vinden voor dat soort fiets. En dat klopt wel, denk ik.

    Het is ook een fietsje dat je technisch naar een semi-gravel bike kan omtoveren, dus als ik ooit eens dat pad op wil dan kan het. Er zijn wel gravel events, maar niet zo veel en je moet om tot in de natuur te geraken je fiets op ‘n auto monteren (of in de koffer gooien), en daar ben ik nog niet. Leuk weetje: één van de bekendere gravel events heet de Belgian Waffle Ride.

    Fietsen in de stad is wel een uitdaging, waar je een beetje moet ontdekken waar je best rijdt en hoe. Ik ben een Whatsapp-groep begonnen voor andere fietsers en heb met een aantal mensen uit de groep afgesproken voor ritjes.

    Elke zondag is er een “ciclothon”. De straten van Mexico stad worden over een lengte van 40-60 km vrijgemaakt en fietsers, skaters en lopers allerhande kunnen zich van 8 tot 14u uitleven op een afgesloten weg.

    Je kunt ook gaan fietsen op het F1-circuit van Mexico-stad. Dat ben ik een jaar geleden ongeveer een keer gaan doen, met toen een geleende fiets, en wil ik binnenkort nog eens proberen – maar nu met de snellere fiets.

    Sim racing & gaming

    Ik mis mijn sim racing opstelling wel. Ik denk regelmatig aan nog eens een investering te doen in een wiel + playseat, maar (1) hoe duur zijn die setups niet geworden? en (2) mijn appartement is toch iets te klein voor een dedicated setup.

    Ondertussen speel ik wat indie games op de Switch of probeer soms een nieuw spel op de gaming PC die ik kocht via Game Pass. De PS4 is hier al even stof aan het vangen. Ik denk soms aan een PS5 maar er zijn niet genoeg goede games. Ik heb ook niet zoveel tijd om te gamen. De nieuwe fietshobby neemt nu mijn aandacht in.

    Eten en drinken

    De restaurants en koffiebars in mijn buurt zijn geweldig. Ik ga regelmatig een koffie halen in mijn vaste stekje. Er is ook een leuke bakkerij in de buurt (en zelfs een frituur!). Er is altijd wel iets nieuws te ontdekken qua eten. Ik kom net van een leuk ramen restaurant; zag weer een nieuwe koffiebar verschijnen; en we gaan regelmatig taco’s eten. De kwaliteit van de keuken hier blijft verbazen.

    De supermarkten hier vind ik nog altijd maar niks en recent vind ik niet echt mijn draai qua ingrediënten en zelf koken. Soms geraak ik wel in een goeie kooklogica met een meal plan in combinatie met iets nieuws proberen, maar we eten toch vaak exact hetzelfde.

    Er zijn hier ook de versmarkten. In het begin denk je dat je op de markten vanalles kan vinden maar het is uiteindelijk toch veel van hetzelfde, met wisselende kwaliteit van de producten. Sommigen zijn toch ook een beetje dodgy.

    Daarnaast ben ik misschien gewoon een beetje lui geworden in de keuken. Het is veel werk om tot de juiste ingredienten te komen om telkens goed te koken. Je hebt ook maar zoveel uren in een dag.

    Cultuur

    Binnenkort is het weer CDMX Art Week, dat is ook iets leuks. Dan zijn er veel feestjes, kunsttentoonstellingen en meer. Ik weet nog niet in hoeverre we iets gaan meepikken, maar zulke dingen doen de stad leven.

    Onlangs gingen we met de familie naar een expo over brutalistische architectuur. Er zijn enorm veel musea en er staat nog wel wat op de te-bezoeken lijst.

    De stadsontwikkeling is ook interessant om te volgen. De stad leeft en evolueert, en er wordt overal bijgebouwd en gewijzigd. Ik sta telkens te kijken van nieuwe gebouwen en hoe de stad blijft veranderen. Met 22,5 miljoen mensen is hier heel wat beweging.

    De taal

    Mijn Spaans wordt steeds beter. Onlangs op een lang weekend heb ik een boek in het Spaans gelezen en denk ik het meeste ervan begrepen. Ik zou wel beter terug echte lessen volgen, maar ik kan een klein gesprek voeren, vlot eten bestellen en ik voel me niet meer verloren.

    Wederom voel ik ietwat tijdsgebrek om echt een structurele taalles te volgen. Ik zou het beter doen, maar de incentive ontbreekt.

    Het weer

    Het weer is geweldig, het hele jaar door 16-28 graden buiten. Een toertje doen in de buurt is heel aangenaam. Wel één minpuntje: het is altijd vroeg donker (18u-20u), dus die lange Belgische zomeravonden heb je niet.

    Andere

    Gentrification is real en ik ben waarschijnlijk een deel van het probleem. Ik heb me ook wel gevestigd in de hippe buurt die er voor bekend staat.

    Moest ik mezelf daarin willen verdedigen kan ik stellen dat ik hier zeker niet ben omdat het hier goedkoper leven is voor een hogere levenskwaliteit. Unlike de vele Amerikanen en Canadezen hier. Ik hoor ook om de haverklap Hollands als ik door de straten loop. Grappig.

    Dat goedkoper leven hier is ook nog wel relatief. Samen betalen we hier veel meer huur dan in België voor een minder kwalitatieve woning en minder vierkante meters. Sommige dingen (zoals GSMs en fietsen) zijn duurder. Andere dingen zijn dan weer veel goedkoper (zoals elektriciteit). Ik heb niet de indruk dat ik hier enorm veel geld bespaar.

    Mexicaanse families zijn erg warm (in ieder geval de mijne). Dat heb ik al een paar keer mogen ervaren, en dat is fijn zo. Wat ook leuk is is dat sommige nieuwe neven & nichten ongeveer dezelfde leeftijd en gelijkaardige interesses hebben. Om een idee te geven: ik heb op een recent familiefeest een gesprek gehad over fietsendragers en de zettelkast methode. Dat had ik voordien nog niet meegemaakt.


    Zo. Veel verschillende topics, maar ik heb het graag over hoe ik de stad en hier wonen ervaar, om later nog eens te lezen wat ik dacht.

    En zo krijgen jullie een beeld van hoe het hier is. Ik kan het zeker aanraden om hier eens op bezoek te komen. Mexico-stad is vooral een hele boeiende stad, en ik heb de indruk dat velen het nog niet ontdekt hebben. Als je tips zoekt, laat het zeker weten!

  • Thinking through the contour feature of Screenshot to Layout

    December 9, 2023 - Posted in build-in-public figma-plugins screenshot-to-layout

    Earlier this week I thought through the contour feature for Screenshot to Layout . This is a future feature, that essentially adds a second layer of output to the plugin, with the goal of visualizing clear shapes in the processed screenshot, so that the designer can use it as a reference point for further work.

    Right now I am thinking through how this should work by doing various experiments and prototypes.

    I’ve had the comment that my Figma plugin Screenshot to Layout is essentially “image to text”, and that is true for sure at this point in time.

    Someone else asked me: is it your goal to convert a whole screenshot to its original design? The answer to that is no. The goal is to provide designers with the ultimate starting point from a screenshot that fits into their workflow.

    The output of the Screenshot to Layout plugin should be a starting to point to continue whatever work you have to do. As a designer you will likely have a file with all kinds of attached text and colour styles as well as library components. It doesn’t make sense to try and recreate the actual layout. What makes sense is to provide a starting point that enables you to put the output into your design system faster.

    So given that, let’s look at how the contour feature would ideally work. I tweeted this to ask the community what they think:

    Given a screenshot such as this, what is the ideal output?

    Text only? Form controls visible? Buttons visible?

    left: source – right: output pic.twitter.com/KH0cqVeoY8

    — Johan Ronsse (@wolfr_2) December 2, 2023

    This screenshot shows a dialog with 4 radio buttons and 3 actual buttons.

    Personally, I think what would help me most is to see the contours of shapes that are very clear and isolated to understand a processed screenshot in a better way. In this example I would want to see the text (coming from the existing OCR features), but then from the contour feature the buttons, maybe the radio circles, but not much more.

    As an another, if you have a screenshot of a contacts list, you might want to see grey circles in the place of the actual avatars. This way you know you have to replace those with your “avatar” design system component.

    With this idea I mind I did some experimentation and wrote a script to recognize shapes in images. Specifically rectangular and circular shapes.

    The current problem I have is that this is fairly fickle. You need some exact settings to not detect text (e.g. an “o” is also a circle); in UI design there’s often overlaid elements etc. So you find that it’s easy to get to a lot of unusable output like in the screenshot below (red strokes are circles and blue strokes are “rectangles”)

    Unusable output 😅

    One can wonder in general how much can the computer “see” and how much has to be determined by the designer? The “seeing” part could potentially be enhanced by a custom machine learning model.

    Another experiment I did involved testing Microsoft’s Cognitive Services for the use case of recognising shapes, but I saw fairly quickly that this probably won’t help me.

    Microsoft Cognitive Services – Foreground matting output

    Another thing I looked into was segmentation and simplification. I think there might be something there for parts of the script, but I would have to find out where exactly it would help.

    All in all there is still lots of work to determine how to move this feature forward.

    I thought I would document these early steps in the evolution of this feature. I’ve always admired game development “devlogs” as well as for example Garret‘s blog posts about the early design decisions in Sifter. If I don’t document it now, I will surely forget.

    This is complex computer science topic which is quite new for me. If anyone has their own ideas, or feel they can offer some help, feel free to reach out!

  • Planning for Screenshot to Layout 1.2

    December 1, 2023 - Posted in build-in-public figma-plugins screenshot-to-layout

    I am doing an investment in taking Screenshot to Layout to to the next level. I am working together with a few freelancers, each skilled in their own right, from making plugins for graphic design apps to advanced Javascript wizardry. Together we will improve the plugin.

    Here’s a sketch of what I am to achieve with the new marketing website. Showing the idea in a nice GIF/short video/animation will be a challenge.

    I want to write a bit of a “devlog” so I don’t forget what we are doing. Maybe it’s bad luck to talk about your plans, but OK. I am trying to build in public, and I found that that I didn’t write down enough while doing Obra Icons.

    Right now we are in a planning phase where I am setting milestones and attaching min/max budgets to these milestones.

    • First, we will lightly research alternate solutions. Is the Azure platform the perfect platform to keep building on? Should we use Tesseract? Or something else? I am pretty sure we will keep building on Azure, but it feels like the right time to assess – with the knowledge of the team at hand – what alternate solution can be found
      • A very senior programmer friend I’ve known for a looooong time will likely take a close look and use his 30+ years of programming experience to asses the above.
    • Next, we will do 2 parallel tracks: the first track is to improve the algorithm behind STL. What I call the “algo” actually consists of 2 parts.
      • The first is what output is gained from “the machine”. Microsoft has a computer vision API, which, given an image with text, gives you back the coordinates of said text and information about what it detected as lines, words or paragraphs. The output of this is sometimes pretty good and sometimes has problems, so there is code that has to work around those problems.
        • A reason to stay with Microsoft Azure is that Azure makes an update to their engine every 6 months. A quick test of the latest model (31-10-23) is promising.
      • The second part is the code that processes said text + coords information to the canvas. That code takes the raw information and tries to make sense of it. For example, if the bounding box of a line of text spans 20px between y1 and y2, and it’s only detected as a single line of text (no paragraphs), there is a likelihood that it should be rendered back to the canvas as 16px text. If it’s a paragraph, the calculation is a little bit different, because now we are also taking into account space between lines.
      • What kind of improvements can we make then? I will be the first to say that the code that I wrote myself is not very good. It works, and I am quite proud of it (its even in TypeScript!), but my hope is that a second look by a skilled development team will bring the code to a new level, also enhancing the OCR output. Right now, there are various small problems which I discuss in detail in this video. To spare you the watch, they are a) inaccurate positioning b) inaccurate text sizing of text layers that look similar in the source screenshots c) the recognition engine mistaking typical icon shapes as single characters (o, v, > etc) and d) the system not at all working with vertically oriented text (90 degree rotated text)
    • The other track is about bringing the plugin to be a full inside-Figma experience. Right now, you have to register on an external website, and the process feels a bit disjointed. Ideally, you can trial the plugin without having to register at all, and then register if you use it a lot. I still want to keep that logic to track people’s usage and so my cloud bill does not go overboard.
    • When we have combined these two tracks, we need to get the word out about the plugin to more people. The third track is a small marketing track which involves improving the visual design of the website, promoting the idea to our combined network and possibly the creation of a clear demo/marketing video.

    This is the plan for a first phase of the plugin development, which is slated for release in +-3 months. In the meantime, you can already try out the current version of the plugin for free. It will be free for at least the next full year, so make sure to give it a try. It’s here on Figma community.

  • Screenshot to layout: landing page & usage update

    November 19, 2023 - Posted in build-in-public figma-plugins screenshot-to-layout

    I whipped up a quick landing page at https://screenshottolayout.com . It contains instructions on how to get started and a quick demo. It’s pretty ugly but will do the job for now I think.

    I released the plugin for free earlier this week, hoping to get some feedback from Figma users. So far a few people seem to have tried it with no feedback coming in. I might have to wait for actual usage during the next working week.

  • Screenshot to Layout released for free

    November 17, 2023 - Posted in build-in-public figma figma-plugins

    You can use my Figma plugin Screenshot to Layout to generate editable text from a screenshot.

    Select an image in Figma, run the plugin command “Process image”, and then see a Figma layout appear with editable text. You can see how it works in this video:

    This plugin is extremely useful to quickly start working on a new design based on a screenshot.

    You will need a free Screenshot to Layout account to use this plugin. Go to figma.obra.studio to get started. Then enter your API key in the plugin itself via the menu item Plugins > Screenshot to Layout > Enter API key*.

    Pro tip: there is also a command you run called Process image so you only ever need to open the plugin once, to set your API key.

    Note: this plugin might shut down at any time if it gets popular due to the processing cost of sending your image to Microsoft Azure for processing. We are releasing it for free to test if it vibes with an audience, before overthinking the aspect that it might get popular.

    Privacy: Do note that your image gets sent to a server, and the actual image data can be retrieved from the logs. We don’t look at the image passing through this service, except for debugging reasons, but be careful with OCR’ing sensitive data.

    *Note that these instructions are for an older version of Screenshot to Layout. For the newest, refer to the website.

  • Obra Icons indie report: how I launched – how it’s going. 2 sales, but powering on.

    November 8, 2023 - Posted in bootstrap build-in-public obra-icons

    I launched an indie project called Obra Icons on October 1st. This is a report of how it’s going.

    The initial version took me about 7 days of work total + around 3 days of external freelancer’s work to work out the initial version.

    What is it? It’s a set of 750+ vector icons, both in stroke and filled variants. The icons are ideal to use in user interface designs.

    The website has all the icons downloadable for free, and there is also a free Svelte package.

    The commercial aspect is a $15 license to get the Figma source files and original vectors.

    I posted a version of this blog post on Indie Hackers which is a community for, well, indie hackers. The blog post was intended for that audience but I am putting it here to make sure it’s archived correctly.

    After launch I decided to work full-time for my client(s) because of an influx of work. Given evenings and weekend work I managed to put around 3 more days into the project after launch myself, and paid for 2 more days of freelance work to improve the project over the past month.

    For the initial iteration, I designed and developed the website, put the icon set up for sale at $20, developed the Svelte package with a freelance developer and launched it on Product Hunt (pretty poorly).

    The design of the marketing website has since received several small copy and UX tweaks but more or less stayed the same.

    For the initial iteration I dove into the setup to be able to sell the source files and quickly compared SendOwl, LemonSqueezy and Paddle with each other. In the end I chose SendOwl, which is connected to Stripe for now.

    The platform works but I don’t love it though. The checkout page is very ugly and unclear. Since I only have 2 sales so far, I am not going to spend time finding the right merchant of record – but maybe I should since the checkout does not inspire confidence.

    I released Obra Icons as Obra Icons 1.0.0 with 350 icons. I followed up over the past few weeks with 10 more releases, which goes fast since I count adding icons as a release.

    Together with the team I grew the icon count from 350 (initial release) to 750+. I personally believe the icons are always getting better and we are reaching a great quality level. Although I’ve found the overall quality to be decreasing as we add more exotic icons. Let me tell you, it’s not that easy to draw a car at 24x24px.

    I am also dogfooding my own work the whole time, using Obra icons in my design projects. When I discover flaws I go in and fix them.

    One thing that really annoyed me was the search engine on the website icons page. In a previous project I made a manual keywords file to provide better search. A design goal of Obra Icons was to be able to update the set easily, so we explored automating things.

    In the first iteration of Obra Icons we chose to generate the keywords by the OpenAI API using a custom prompt. This worked OK, but I quickly discovered that some icons have multiple meanings. For example, a typical refresh icon might as well pose as a redo icon. An icon that depicts sparkles is often used for “ai” these days.

    We then improved the search engine adding additional logic to the scripts that parses the layer name in Figma (e.g. sparkles[ai]) into a manual keywords file which should get priority in the search.

    The search is not perfect yet but it’s kind of fun how it can generate interesting results you wouldn’t think of yourself some times. We use Orama in the background.

    Now, what about the commercial aspect? The project is sold directly and via Figma’s community. It has been sold twice directly via SendOwl, and not yet via Figma community.

    What do I think after one month and “only” 2 sales? To be honest, it’s pretty thrilling to receive a sale from an indie project. I am happier with an indie sale than another billable hour on a client project.

    I don’t track stats on the website so I have no idea how much is it visited, but the npm package has 7,238 weekly downloads. Not sure where all those are coming from, but that’s nice!

    I created a discount code to give the set away to some friends. I am getting some nice and positive reactions. Since it’s a digital product, I can give it away for free to my designer friends, hoping they can help promote it – because I am sure anyone following me on X is already annoyed by my promotional tweets.

    I have lots of ideas to improve, on the planning:

    • Create a blog
    • Create a React dev package (maybe Vue? Does anyone still use that?)
    • Blog about the process
    • Keep improving the set!
    • Maybe some SEO blog posts (Christmas icons! Halloween icons!) but it’s not really my style to dirty up the internet

    Right now I don’t really know where my priorities are with this project. I might move on and only maintain it lightly. It was supposed to be a small project after all.

    I want to blog about it more and see if I can get any “design influencers” to promote the project.

    I lowered the price to $15 and I am planning a sale in December for $10 to experiment with pricing. I think it’s good to do pricing experiments with light, small projects like this.

    I am constantly thinking about how to improve things. First of all about which icons to the set and how to improve the drawings.

    Talking about drawing quality, I went as far as starting the design of a first font, to be able to support icons with letters and numbers in them in a better way. I drew the characters of a full alphabet in uppercase and lowercase in Figma. I started to learn Glyphs, too. People on the Glyphs forum say Figma is not a great vector tool, and I agree it has shortcomings, but for this project I rather like it.

    I know my way around Figma and its features such as autolayout combined with the scripting/plugin capabilities it has, I am able to work at a scale that I’ve never been able to work before.

    To support that working at scale, I created a custom Obra devtools plugin to handle all kinds of manual actions to be able to maintain the consistency of the set while scaling it up with hundred of icons. Through this I got better at creating Figma plugins, which helps with another project I have, which I might revive soon.

    It’s funny how working on this project is affecting my outside behavior. I take photos on the streets of icons I see in real-life and I’ve never looked more closely at any graphic design around me as before.

    If you’ve made it this far, all feedback is welcome, and in exchange for your feedback you can get a discount code to download the set for free. Thank you for your attention!

  • Icon requests for Obra Icons

    October 3, 2023 - Posted in obra-icons

    Yesterday I launched Obra Icons 1.0.0. We are already actively working on the next version which will mostly contain more icons. But which icons are you missing? You can see full, searchable list of icons here. Hover over an icon to copy or download the SVG, or to copy the Svelte import.

    If you have any requests, let us know, and we will consider it. Let us know at iconrequest@obra.studio or make a Github issue.

← older
newer →
  • ©2025 Johan Ronsse
  • X
  • Mastodon
  • Portfolio 2024