How we work

Coding Systems represents a creative endeavor, acknowledging that the outcome of coding is emergent. At its core, Coding Systems emphasizes the human element as the driving force behind the creative process, using technology as a tool. The belief is that technology should amplify thought processes rather than obscure them, with transparency in its incentives and underlying dynamics. Striving for a comprehensive understanding of the costs and consequences of our work, Coding Systems aspires to act responsibly.

Coding Systems seeks solutions beyond design software lock-ins. By crafting custom-made design tools, new, unexpected territories are unlocked. With a designer’s vision, not a technician’s, technology transforms into an enhancer of human creativity rather than a limitation.

We do not believe in hard data.
We believe in soft data.

We do not believe in automation.
We believe in the interaction between human and machine.

We do not believe in static Identities.
We believe in flexible Identity Systems, setting clients free to design their own deliverables.

Published on March 23, 2024

Last updated on November 6, 2024


This conversation is an invitation for collective sense-making. Did it spark any ideas or doubts? Do you have additional sources we should look into? Use the comment section to become part of the conversation.

5 Comments on "How we work"

  • I will add some advantages to the section about building tools for clients to allow them to work with the designed Flexible Identity System:
    – Ability to work with real data: these tools could be fed with data sources (provided to the tool as input, or retrieved from connected online resources at the moment of creating the deliverable), which opens a world of possibilities (both creative and client level).
    – As a piece of software, the tool can be updated to add new components (if the visual system evolves) or new features needed by the client. It’s not finished and closed, it can be iterated and improved.
    – Ability to track feature usage and metrics that can be useful for learning and improving the tool.

    November 22, 2024 at 6:33 am

    • Tim

      These are both very good points, thank you Ricardo! I think it makes sense at some point to publish a dedicated article about custom tool development. Speaking technically: what kind of stack would you propose for building a tool?

      November 22, 2024 at 7:09 am

      • I totally agree with you, Tim, that this topic deserves its own article if we want to go deeper into the technical stuff 🙂

        Regarding the question of which stack to use, assuming that it should be a browser based tool (so the client doesn’t have to install a third party tool), since we will be scoped to work with web technologies, the first idea that comes to mind is obviously p5.js. But look, for example, the tool developed by Supermarket, which is made in React https://fvs.supermarket.london/fvs-tool/. Working with a Javascript framework makes it easy to work with components (with their inputs and outputs, lifecycle hooks…) and take advantage of other framework features that simplify working with http requests, state management, etc.

        Moreover, it can be combined with tools like Storybook, a “component workshop” that gives you all the UI controls that you can map to the component properties to play with. I’ve recently been working in a project of a design system based on an Angular Component Library with Storybook and I’m looking forward to make an ‘experiment’ to test all this in the realm of a FVS tool.

        November 22, 2024 at 4:15 pm

        • Tim

          Very cool! I was already thinking that it would be nice to test react as a I framework. But I am still a. It hesitant since it becomes quite large at that point. I will think about it. Thank you!

          November 23, 2024 at 6:52 pm

          • Hi Tim! I completely agree –using React for a small browser-based design tool feels like overkill. I’ve started a small project using only vanilla javascript (and leveraging Vite to handle modules and streamline the tooling and build process). Initially, I worked with native web components, but the boilerplate required for each component and some of the complexities involved made it challenging. Eventually, I discovered Lit (https://lit.dev), a lightweight library built on top of web components that significantly simplifies working with them.
            I’m now feeling confident with this lightweight stack as I move forward with building my first browser-based tool. For the initial version, I plan to focus solely on DOM-based layouts to ensure responsiveness and enable flexible, adaptable designs. In future iterations, I might explore integrating p5.js to expand its capabilities.
            Hope this helps you considering stack alternatives!

            December 23, 2024 at 10:56 am

Leave a Comment

Your email address will not be published. Required fields are marked *